Extended Validation Certificates Are Dead | Hacker News Reader

Extended Validation Certificates Are Dead

troyhunt.com

186 pointsjcurbo104 comments

I'm seeing a lot of discussions about financial and specifically banking sites here. For the average user, there's no reason or need to phish a particular financial site.

One of our engagements sent users to a site we just made up, and asked for user credentials for a site they had never heard of in order to access cat videos. In most cases, we were given valid domain credentials. I'd bet money a high percentage of those were also banking credentials. What good would an EV cert at the bank do for this?

It wouldn't do anything, because users don't check it. I used to be involved in phishing campaigns against internal employees at a fintech company. Despite these employees being highly technical people, I can't recall incorrect or missing extended validation certificates ever stopping them from submitting credentials.

As another commenter has said, I can't personally tell you the name of any specific website with an EV certificate. I don't know any friends or family who actually check for the presence of correct EV certificates. It's a cool idea and it's made CAs plenty of money, but it's just too subtle of a cue.

I think many people are resistant to the idea that extended validation certificates aren't effective for one or both of two reasons. First, they probably want to actually do something instead of being hopeless, so they consider doing something better than nothing even if it's not ideal. Second, they are reviewing the technical specification and finding it sound, but not grounding it in the reality of how users work.

Part of the argument against them is not just that they're ineffective, but also expensive. It's not unreasonable to simply call it snake oil. The visual cue would need to be significantly more prominent - up to par with the red versus green icons of HTTP and HTTPS, respectively - in order to have a real impact. Users would need to have better training and education to come to expect the extended validation instead of merely feeling more assurance when it's present. The system has insufficient penalty for sites which should have extended validation but only present domain validation, and browser-buyin to the concept is fading.

> First, they probably want to actually do something instead of being hopeless, so they consider doing something better than nothing even if it's not ideal.

Right, once OV and EV certificates are effectively removed from browsers, users such as myself will no longer have any tool to help ensure we are interacting with the entity intend to be interacting with. It is kind of like getting a cold call from your credit card company saying their has been suspicious activity and they want me to authenticate my account with personal details. I always call the phone number on the back of my physical credit card to ensure someone isn't scamming me.

Rather than removing EV certificates as a concept, I would love to see some experiments run by browser vendors to see how users can more readily understand who they are interacting with. But instead, the solution seems to be to get rid of the only option since it doesn't work in its current incarnation.

> Part of the argument against them is not just that they're ineffective, but also expensive. It's not unreasonable to simply call it snake oil.

I have a hard time understanding this argument. You can purchase an EV cert for $80 a year from NameCheap. The extra cost is because they have people verify that the company details you have provided are valid and that you are an authorized representative of the company. Any company that is more than a solo founder is going to be in dire straights if $80 a year is too much. I mean, are you even going to find a domain name and hosting for less than $80 a year?

In reality though, I don't think much of anyone other than major email providers and financial institutions really need to worry about EV. If a website doesn't have EV, but uses PayPal, I have no qualms. But if I go to long into Fidelity or PayPal and they couldn't be bothered to spent $100 per year to help me ensure I am actually interacting with them, that says a lot to me. I mean, even my small town NH bank has an EV cert. It just makes sense if you are dealing with finances.

OV was never really accessible in browsers. Even the vendors pushing these seemed to avoid showing how to identify one (when they would screencap the EV green bar), and probably for good reasons.

> You can purchase an EV cert for $80 a year from NameCheap

I've been through this a quite few times. The cost of the cert isn't the true cost. If I could pay $80 to Lets Encrypt to have every issued cert be EV, I'd do it just to avoid this bikeshed. Every single time I've done it, the validation process has been extremely painful. I feel like it's made up on the spot by whatever offshore person gets asked to do the validation. Documents accepted last year are suddenly not accepted at renewal time. Being denied because my Australian company doesn't show up on a UK business register for example.

> avoid showing how to identify one

The certificate policy identifier will be 2.23.140.1.2.2 for OV. You have to look at the certificate details to find it.

I looked into it for someone once. Then I watched in amazement as less technical person insisted on OV certificates.

Yup. A LOT of businesses make this worse by having some sort of half-arsed single sign on solution where a single set of employee credentials work in a bunch of systems, but not all systems. If you show their users a site they've never seen before with a login box and say it's somehow related to the business ("Our company's partnership with Hat Box means you may be entitled to significant discounts on a range of hats, check them out today!"), they will type in the credentials they use for that business's core systems, not because they're idiots re-using passwords, but because they genuinely expect that might be what works and other systems they use have reinforced that expectation. You can get a LOT of valid user credentials this way without even really meaning to phish them.

As well as preventing confused end users from putting their site A credentials into site B, WebAuthn prevents idiots from designing a system on site B that expects the credentials from site A. It just doesn't work, you can't make it work, so you have to go back to the client and say "No, as well as being stupid that's also impossible". So you not only protect the users from the actual security problem you stop engineers building things which incur the problem in the first place.

EV is very useful when banks decide to host some parts of their online presence on what sounds like a phishing domain. Think "onlinewebconnect.com", which redirects through "live.logonvalidation.net" (Saxo Bank - they're hip enough to have their own TLD but apparently not smart enough to actually use it for something good) or the various domains banks liked to use for their "3D secure" login process.

It also drives the cost of phishing attacks up significantly. Sure, you can get a confusing cert issued, but if it requires you to create a new company, it's not going to be used in mass phishing attacks.

Extended validation isn't very useful, for exactly the reasons the article explained. Most users don't take advantage of its benefits no matter how technically sound the concept is. Providing users with anti-phishing and phishing-detection tools doesn't mitigate phishing. The way to mitigate phishing isn't to empower the user with sophisticated awareness, it's to eliminate the need for that awareness.

Ok so we just removed the "sophisticated awareness" and now we wait for a fantasy/unknown solution. No brainer, right? To me this looks like a bad day for the open internet and a good day for walled gardens(i.e. Apple Store).

How exactly did you get from the inefficacy of extended validation certificates (and their subsequent obsolescence) to solidfying moats for walled gardens?

The original purpose of an EV cert is to provide a browser UI that tells a first-time visitor that they can trust the website they've landed on. This is a separate goal from TLS in general, which is just supposed to secure the traffic in transit.

Google in particular has no interest in providing such a browser UI. They want users to use Google Search to establish trust instead. "If you're not sure, Google the business name" is common advice to avoid copycat sites. Boy is that a good position for Google to be in! Why would they invest in an alternate solution with a distributed architecture and client-side UI?

Almost all the "best practice" security advice today is centered around protecting existing relationships with sites. "Use a strong password, a password manager, and two-factor-authentication" does nothing to protect a first-time site visitor from a scams. It makes sense for security professionals to focus on the lowest hanging fruit, but the result is web in which first time site visits are perilous and uses get no help at all with that.

Yikes there's a lot of (in my opinion) misconceived cynicism here...

> The original purpose of an EV cert is to provide a browser UI that tells a first-time visitor that they can trust the website they've landed on. This is a separate goal from TLS in general, which is just supposed to secure the traffic in transit.

This isn't really accurate. Basic TLS (domain validation) provides encryption and authentication - if TLS did not provide authentication in its most basic form, the encryption would not be very secure on its own. Extended validation merely adds further parameters (properties, characteristics, etc) to the server side of the authentication process that already exists in TLS, in combination with administrative work on the part of the certificate authorities.

Then the client provides the UI visual indicators corresponding to the authenticated identity, as you say. But while all of this technically works, most users don't bother with checking it. Security with friction to use doesn't typically provide any security, it just makes you feel like you're doing something.

> Google in particular has no interest in providing such a browser UI. They want users to use Google Search to establish trust instead. "If you're not sure, Google the business name" is common advice to avoid copycat sites. Boy is that a good position for Google to be in! Why would they invest in an alternate solution with a distributed architecture and client-side UI?

I can trade your flavor of cynicism with my own: certificate authorities don't want TLS certificates to be cheap, so they come up with shiny options such as OV and EV to have something they can upsell.

See what I just did? We can just keep arguing cynically if we'd like, but we don't arrive at any new insight about the actual point. The fact of the matter is that it's largely irrelevant what Google's motivation is, because the efficacy of extended validation (or lack thereof) does not rely on Google (or any other browser's) motivation. And for what it's worth, Google is not the only browser maintainer moving away from EV visual indicators.

> Almost all the "best practice" security advice today is centered around protecting existing relationships with sites. "Use a strong password, a password manager, and two-factor-authentication" does nothing to protect a first-time site visitor from a scams.

This is a fair point. It's definitely true that phishing is not as sexy a problem as "technical" security vulnerabilities, and so gets relatively less attention. But a security mechanism only augments security if it's actually used or adhered to. I'm not debating the technical merits of extended validation. I'm stating that it's ineffective beause it's a technical solution to a social problem. The way to resolve that social problem is through more sophisticated education and training. Or more likely, to re-architect the interface and browsing methodology in a way that obviates phishing entirely. Just because one of those approaches seems out of reach doesn't mean we should settle for EV, which in practice doesn't do anything. The only nontrivial users of EV are banks and financial institutions; these are the same institutions who have completely bought into security questions, inability to paste passwords and draconian password complexity requirements.

TLS authenticates in a technical sense. The purpose of EV was to tie the technical authentication to existing processes for legal authentication. That's why, for example, EV certs must include the legal name of the company or a registered DBA (note--edited to fix this).

> But while all of this technically works, most users don't bother with checking it.

Shouldn't that be a UI problem? But instead of improving the usability and utility of EV and OV cert content, browsers are instead just hiding it.

> I can trade your flavor of cynicism with my own: certificate authorities don't want TLS certificates to be cheap, so they come up with shiny options such as OV and EV to have something they can upsell.

A lot of people do feel this way. The objection to OV and EV certs has a large cultural component. Browser providers don't like CAs in general. Part of it is because most CAs are not as technically savvy. But yes, part of it is: who is going own identity and authentication on the Web? It's a tug of war with real business implications.

What gets lost in the fight is that EV and OV certs are not just stupid scam upsells. Conceptually they are different from DV certs, and contain different content that could be used to solve real problems for users. Sure--anyone can create a company and register it with a CA to generate an EV cert. But doing so leaves a paper trail that is easier for law enforcement to follow than just a DNS entry for a DV cert.

> The way to resolve that social problem is through more sophisticated education and training.

This is not how social problems get solved. We didn't provide sophisticated education and training to help people discern real clothing stores from criminals who will rob you; we used the collective resources of society to create processes and records that help us hold business owners accountable if they use their business to commit crimes.

Suppose Alice is looking at a web page, https://example.com/ which she believes is run by Bob, and Alice types in her credit card number, and then she presses the Charge button and a form submission happens, which means behind the scenes the browser does HTTPS POST to https://card.example.com/ Let's walk through this:

1. Alice's browser looks up card.example.com and gets some IP address, it connects to this IP address, with TCP, on port 443 the standard HTTPS port.

2. It does a TLS handshake with the server that answers, it sends SNI asking for card.example.com, the server sends a certificate and proof that it owns this certificate (in older setups the proof may be implied but let's not worry about this detail)

3. The browser validates that the proof is correct, that the certificate is acceptable (signatures etcetera) and that the certificate has a Subject Alternative Name matching card.example.com, if anything is wrong it aborts.

4. Otherwise the browser writes the HTTP POST data over the TLS connection to card.example.com, it gets back an HTTP response body, which it processes as normal, for example, the display body may be a 30x series HTTP redirect back to https://example.com/ and that's displayed for Alice.

Now, where in this process did Alice get a chance to verify that her credit card data goes to Bob?

Nowhere. Even if card.example.com has an EV certificate which says the subject's real name was "Bob Limited" that information is meaningless to a web browser and is never displayed for Alice to look at.

Let's suppose we really try hard to help Alice here. When do we show her the "Bob Limited" subject? We only discover it during the HTTPS POST operation, milliseconds before we send her credit card data. Do we... stall everything, and hope Alice can examine the certificate while the transaction waits? Good luck with that, even if Alice is (unlike all normal users) fastidious enough to not just click "Yes, yes, go away and stop bothering me you stupid computer".

The EV cert is served with example.com, where Alice can see it.

EV is not necessary for card.example.com because a) it's not a domain that Alice will visit directly, and b) Bob has out-of-band opportunities to confirm that he wants his application to connect to card.example.com.

EV does not provide better technical security than DV, it provides better information for following up on problems. If Alice thinks Bob ripped her off, she can look at the EV cert on example.com to get the legal name of Bob's business and the locality in which it is incorporated, and file a complaint against him. She doesn't need to know about how Bob processes credit cards to do that.

But why bake this stuff into the certificate in this scenario?

If Alice is only going to check any of this long afterwards it doesn't need to be part of the X.509 certificates issued for the Web PKI, Alice can check in any number of ways which business it is that she thinks ripped her off.

Of course since she waited until after she was ripped off it may be that it's a company with no practical presence in her country and she can't do anything about it anyway. But EV doesn't make any difference there.

Now is harder to distinguish between legit business websites and scams. The best alternative is to just use an iOS app as Apple does the verification(i.e. what EV provided). EV was far from perfect, they were expensive and hard to get but I think it should be replaced by something better not just removed. I personally never heard/seen of any phishing website using EV certificates.

The reason you haven't seen a phishing website using an EV certificate is because they don't need to even bother with it. They secure their website with regular domain validated TLS, get a domain that looks halfway decent compared to the real one, and users never even look for the extended validation certificate.

Trying to get an incorrect extended validation certificate would just add to the money and risk involved in the campaign. Since users only rarely even check them, you don't even need to bother with it.

It's an ill-conceived solution to a problem which is intrinsically enabled via poor security education and habits. Expecting users who aren't sufficiently diligent to check for slightly incorrect phishing domains to look for slightly incorrect or non-existent extended validation certificates is silly. That's not a categorically different approach to the problem, it's just more of the same to the left of the domain name.

>> The reason you haven't seen a phishing website using an EV certificate is because they don't need to even bother with it. They don't use EV certificates because they are hard, even impossible to get for many. If you also consider that domains get blacklisted by the day, phishing would become unfeasible for many. The internet would be safer with EV-everywhere.

There are two issues with EV:

1. They are too expensive and hard to get/manage. We need something like Let's Encrypt so that you can submit documentation etc through an open protocol.

2. The UI is not good enough.

Due the reasons above many companies didn't implement EV.

I find it hard to understand why would someone remove EV with no replacement in place. How can I tell if google-domains.tld is a domain/website owned by Google Inc or a random scam website? Even a technical person is unable to tell you because there is no tool(at least I'm not aware of any) except the EV certificates.

Funny story, you mentioned "Google Inc" and that's wrong.

The company you're probably thinking of is Alphabet (does your grandmother recognise that name?) but it might be XXVI Holdings, or Google LLC or any of dozens of other subsidiaries created to remove the ability for shareholders to conduct any meaningful oversight. You can buy Alphabet stock with the ticker name GOOG, and maybe it goes up or down, but you get no ability to see whether they're losing money on AI research or gaining money on web searching, that's all now opaque internal information for a private company owned by a different private company that is merely owned by Alphabet, and so it isn't available for you to even think about.

But even though I got sidetracked by a rant, my real point here is that you have no idea what you expected to see in this EV information, so who cares? You thought you wanted "Google Inc" but that doesn't even exist, a scammer could register it, and fool you, whereas the real Google, who don't own this "Google Inc" name couldn't satisfy you. Ludicrous. If you want the company behind Google.com, don't go to Google.some.other.example and hope to somehow check that's the right company, just go to Google.com

>> You thought you wanted "Google Inc" but that doesn't even exist, a scammer could register it,

No, they wouldn't be able to register Google Inc and most likely not any derivate either like they do with domain names. Setting up a company is not that easy as you might think. EV implemented right would make most(90%) of the scams unfeasible.

>> my real point here is that you have no idea what you expected to see in this EV information, so who cares?

Well, that's one of the issues that I mentioned and it's an UI issue not an EV issue.

>> If you want the company behind Google.com, don't go to Google.some.other.example and hope to somehow check that's the right company, just go to Google.com

Why would I go to google.com if the link I received in my email has a gmail.com, accounts.google.co.uk or mailchip.com/clickAnalytics=google.de ? Google has many domains so why this one would not be legit?

Question for you: Is this a legit paypal website? How do you know? https://www.paypal-prepaid.com/account/login

> Setting up a company is not that easy as you might think.

In Ian Carroll's EV experiments it cost him $177 and took 48 hours, to create a new company named "Stripe" in the US and get an EV certificate for it.

So, a lot easier than getting tickets to see a popular musical, but not as easy as buying a McDonalds burger. Is that what you had in mind with "not that easy as you might think" ?

Both the US and the UK have a _lot_ of what are called "brass plate" companies, that is the company doesn't really exist in that country at all, it's just a name plate (made of brass usually) on the wall at some cheap lawyer's office. The real owners of the business will usually never have even visited the country, none of their real assets are present, they just have a legal presence to achieve some other purpose. Setting these up costs under $100 each if you know what you're doing.

I would assume that's a real PayPal web site because PayPal are notoriously bad at this stuff and it's the sort of bone-headed thing they'd do. But if my mother asked about it I'd sigh and suggest she tries the actual PayPal.com and see if there's a link to this "prepaid card" idea from their site. That link might be bad too (PayPal are terrible enough at this that they've done idiot things like advertise sites actually run by scammers because they didn't realise those sites weren't theirs...) but it's the best she can really expect to do when dealing with PayPal.

> It also drives the cost of phishing attacks up significantly.

It also drives up the cost of business for small sites significantly. If thats OK, it better have a pretty significant value. And, all the available evidence indicates it doesn't.

It only drives up the cost of phishing attacks if the customer actually expects the EV cert UI and is willing to bail if they don't see it. One of the major issues with EV is that, while seeing the EV cert may give the user confidence that they're visiting the business they intended to, not seeing the EV cert is not detrimental in any way, because users generally don't expect to see them.

And a personal anecdote to back this up: I'm a pretty savvy web user, I've been around for a while and visit lots of websites, and yet if you were to put a gun to my head and tell me I had to name a website that I was confident would have an EV cert, the only site I could possibly name is my bank, and even that I'm not positive about, I just know that banks usually have EV certs.

(just checked, my bank does in fact have an EV cert)

It's like when you go to aka.ms, it redirects you through sftools.trafficmanager.net before dropping you on a Microsoft oAuth screen. Looks super dodgy, even though it's legit.

They were pretty silly in the first place. All it did was emphasise what a giant scam the CA business is: either all certificates have undergone meaningful validation, or none have, having higher and lower grades is .. broken.

The purpose of an EV cert was to provide the user with trust that the company running the site is a legitimate business. That is different from the purpose of TLS in general, which is simply to secure traffic over the wire. That's why they are different products.

The use case for EV is hard, and CAs did not always deliver on the goal. But instead of working on that hard problem of trust on first visit, most security professionals have decided to ignore that problem and pretend that all certs have ever needed to do is secure the wire. Of course EV certs look silly under that line of thinking, but that doesn't mean it's right or complete.

The industry has basically given up on the idea that there is some way to establish trust on first visit. Which is nuts, because we take it for granted in real life that we can just walk into a brick and mortar store and conduct business without getting mugged.

most security professionals have decided to ignore that problem and pretend that all certs have ever needed to do is secure the wire

If you want to blame someone, blame the original designers of the current system, who decided certificates had to be a one-size-fits-all solution for both encryption and identity. Also, blame the years and years and years during which people on sites like HN condescendingly insisted that identity was the important part of TLS/SSL, and who more or less said you'd be better off unencrypted than encrypted without ultra-mega-hyper-octuple-verified identity.

In real life it's difficult and expensive for me to rent a brick-and-mortar storefront, cover it with the branding and logos of a trusted company, stock it with real-looking products and employees in uniforms, etc. On the web, it takes five minutes and costs little or no money to produce a good-enough imitation of a trusted company's site. Any attempt to analogize between them will fail because of how much lower the barrier is online. Any attempt to say that it's easy in real life, so it ought to be easy online is based on missing this fundamental fact.

Also, we live in an age where it's profitable to cold-call people on the phone and say "I'm the tax authority and you owe money, buy $500 worth of iTunes gift cards and send them to this address", and where the majority of calls that come to my phone use spoofed caller ID to try to scam me.

"Trust on first visit" is really a monstrously hard problem, and I think you're underestimating that.

I'm not underestimating how hard the problem is, I'm complaining that people are taking the difficulty as an excuse to pretend it does not exist, or to treat it as unsolvable.

I'm not saying it's easy in real life, I'm saying it's largely solved in real life. There is a big difference between those two ideas.

The difficulty was part of how it was solved. In addition to the physical difficulty of setting up a store, businesses have to be registered and licensed by state and local authorities. The purpose of the EV cert (and the OV cert, really) was to tie web trust back to that same regulatory infrastructure. If you have a problem with a site using an EV cert, you can look up the company info in the cert and contact their local authorities.

The purpose of the EV cert (and the OV cert, really) was to tie web trust back to that same regulatory infrastructure.

Except the only way to get what you want using EV is to force literally every site on the internet to go through the EV cert process. Otherwise, somebody's going to go get a "less verified" cert, set up an impostor site and phish people.

Is that really the world you want? Is that the price you're willing to pay to get it?

> Except the only way to get what you want using EV is to force literally every site on the internet to go through the EV cert process.

No it's not. There are a lot of ways to physically sell things without setting up a retail establishment. You can drag a box out onto the sidewalk and sell sunglasses to people; you can host a yard sale, you can set up at a flea market, you use a classified ad or Craigslist, you can sell through MLM, etc. Customers will calibrate their level of trust based on the experience you provide.

Operating a physical retail store (or a bank branch, or a restaurant, etc) carries with it an implicit promise of trust to the customer, and it's a promise that is backed by social and legal conventions.

So there's a range of experiences and implied trust in physical life, and it's fine if there is a range online. Site operators could choose the level of trust they're willing to invest in providing.

> Otherwise, somebody's going to go get a "less verified" cert, set up an impostor site and phish people.

That's only true if browsers make less verified certs look the same as more verified certs, which is what they are doing. It's a self-fulfilling prophecy. Now every site looks like a guy with a box on the sidewalk.

That's only true if browsers make less verified certs look the same as more verified certs

Given that decades of user research overwhelmingly indicates that the average web user does not understand the components of the browser URL bar, and in many cases those users are completely unaware there even is useful information there, I'm going to bow out of this, because you're now into territory where you need to forcibly educate every single person on earth to understand the URL bar.

(and you're "only" now requiring that every single person who will ever do business of any sort must pay up for an EV cert, but that's actually less of a problem than trying to force people to understand what an EV cert is and how to tell if a site has one)

Why are we constrained to the URL bar?

I think people have just developed a weird blindness about the possibilities of user interface in browsers. There's no reason browsers could not have created all sorts of interesting user experiences with the validated business information in EV and OV certs.

If you don't have identity as part of the process, the result doesn't do anything. TOFU is broken completely, there are studies showing SSH key rotations in a computer science department triggered no attempts to verify the key change at all.

And the whole point of encryption is you think there's a MITM, so if you are using a scheme that doesn't stop MITM, why bother encrypt at all? Just bank the simplicity and performance savings and don't do it.

Another way to look at this article is: The browsers are killing EV certs.

That seems to be the bulk of the point he's making, EV certs are dead because, especially on Mobile, you can't even tell they are there. He doesn't really, in my mind, support the case that EV certs never were worth anything. I definitely liked to see them when I went to my banks and the like. But I'll admit that I don't remember which ones had them and which didn't, other than that I expected my financial institutions to have them.

> But I'll admit that I don't remember which ones had them and which didn't, other than that I expected my financial institutions to have them.

This is a core point in the article too that you've glossed over: no one knows which websites must have EV information other than a general "hope my bank has one". EV certificates are useless not just because the browsers are dropping them, the browsers are dropping marks for EV certificates because they are useless for actual security.

They were an interesting attempt at security, but like the "take your shoes off at the airport", it only really helped you from maybe blowing up your own foot, tops. Ultimately the only thing that EV certificates were doing was lining the pockets of security theater predators, because despite "reports" they've never really meant anything to the average consumer and most consumers never learned how/where to look for them except sometimes "maybe my bank should have one, I don't know?"

This is worse than that, because no one ever wondered if they should have one.

People only notice when it is there.

I may be different, but to me it seems that EV certificates are useful for dealing with domain typo fishing. Google.com is pretty short and memorable. However, when I type my bank's address, especially if it is a small bank, seeing the EV certificate gives my more confidence that I did not make a typo in the URL. Given that LetsEncrypt makes if free and painless to set up https if you have control of a domain, the EV certificate just gives me just a little bit more comfort over a DV especially for sensitive information.

>seeing the EV certificate gives my more confidence that I did not make a typo in the URL

not really. there's nothing preventing an attacker from creating a legal entity with the same name and legitimately getting a EV certificate.

https://stripe.ian.sh/

This is a much easier problem to deal with than trying to make any other strategy useful. The requirements to get an EV certificate can and should be updated, but it's the closest thing HTTPS does to being a useful security measure.

The reality is that good security doesn't scale. If an entity starts specifying a reasonable list of certificates it has directly verified are the trustworthy well-known entities people expect, you have a good trust system. Once you start throwing in an automatically-verifiable system where everyone should be able to participate, phishing is going to happen.

As much as Let's Encrypt helped encrypt the web for free, it also guaranteed that convincingly phishing the web is also free. Making a legal entity and going through the EV process is a level of frustration that isn't easy to handle repeatedly, and very few checks would be needed to be added to EV to make it near impossible for an entity to rebrand and reappear after being banned for misusing it's certificate. Notice that stripe.ian.sh doesn't actually have an EV cert anymore: A system working as designed.

The only way we are going to ever ensure your bank site can't be imitated by some kid in their garage is going to be to create a system that a kid in their garage can't participate in. And the closest thing to that is EV.

> Notice that stripe.ian.sh doesn't actually have an EV cert anymore: A system working as designed.

Comodo has apologized for incorrectly revoking the certificate for stripe.ian.sh and offered a new EV cert.

https://www.comodoca.com/en-us/about/blog/on-comodo-ca’s-rec...

In fact, many browser security developers would disagree with your assessment:

https://groups.google.com/forum/m/#!topic/mozilla.dev.securi...

I have very little faith in the opinions of "browser security developers" at the moment on account of browser security being a joke. Their focus has been on technical security but lacks practical security. Yes, stripe.ian.sh exists, but have you ever seen a truly malicious use of EV?

Browser security developers concern themselves with arcane exploits of sandboxes while they don't mind nearly that every browser extension has full read/write access to everything people see and do.

EV has flaws, but it's better than literally anything else. We shouldn't be promoting HTTPS if it isn't solving this, the other problems it attempts to solve are mostly overstated problems. Because phishing is a vastly bigger threat than MITM.

EV has theoretical flaws but solves real problems, HTTPS without it has real problems and largely solves theoretical flaws.

Frankly, I have yet to see a typical user point out EV as a problem solver. Usually, when I try to explain my work with EV to an average user, nobody knows what I'm talking about.

I would argue that's because the companies that should be using EV aren't, so users don't see EV often/enough. Google, Microsoft, etc. have no excuse to not be using, and emphasizing EV certificates. Consider how many "Microsoft support" scams would fall flat on their face if people were taught to look for the company they're dealing with was in a green box near the URL, and EV certs were shored up so that only major Fortune 500 or so companies were able to participate.

And before someone suggests that users can't be taught this, there's precedent: We've been trying to teach users not to trust that "Secure" badge/lock icon they've gotten used to. The difference is, the secure icon never represented that they were communicating with someone trustworthy, but the EV designation would.

EDIT: Also, hi Ian! stripe.ian.sh makes you a minor celebrity, and I'm honored by your presence. ;)

Its not Google's job to prop up CA vendor's business selling snake-oil certs. They don't see them as useful. There is compelling evidence that they aren't. So, Google is absolutely right not to encourage people to drop $2k+/year on Comodo for worthless certs and a "warranty" that means nothing.

But pushing snake oil certs is exactly what they've been doing by forcing people to use HTTPS to avoid scare tactic "Not Secure" warnings. HTTPS is far less helpful than something like EV that includes identity, rather than an ethereal statement that you have an encrypted connection to "someone".

The article makes a pretty compelling point that EV certs are worthless. Google and Apple seem to think that EV is worthless - that is why they are removing special treatment for them from their browsers. Many of the largest sites in the world that are the most appealing targets to phish have voted that they are worthless by not purchasing them.

> forcing people to use HTTPS to avoid scare tactic "Not Secure" warnings.

"Not Secure" is a literal description of the state of the connection. Its not secure. What should a browser say? I guess nothing because your site is so special that its users should be ok with having someone MITM the connection and inject who knows what into the page. Whether or not that is OK isn't your decision to make - its the right of your users to make that decision and saying "Not Secure" helps them. That you find that inconvenient for you is well ... inconvenient for _you_.

> HTTPS is far less helpful than something like EV that includes identity

The article makes a pretty compelling point that EV certs are worthless and do no better a job at providing security than regular certs.

I don't find the articles' arguments compelling at all, hence my statements contrary to it. Many of the arguments against EV, including in this article, are circular and depend on appeal to authority towards companies who don't like them.

What about the article isn't compelling?

We have an expert here, writing they are useless.

We have various case studies of different websites using them and then switching away from them without any user outcry - again, showing they are useless.

We have various examples of CAs making highly misleading claims with a clear intent to financially benefit themselves.

We have a "warranty" that no one will explain what it means.

We have major browsers, saying they are worthless by removing their special treatment.

We have major websites voting with their feet, never using them, indicating they are useless.

Its extremely unclear to me exactly what you are objecting to. Maybe if they were useful, then, they would be useful, but, that's circular.

So present an actual argument.

When people insist EV have value, they almost always base it on some hand-wavy claims about preventing phishing. Cite to research (not to advertising claims from CAs) showing that significant numbers of users are aware of EV and use it as an indicator when deciding whether to trust a site, for example.

The problem is you won't be able to; the average web user is barely aware of what the various things in the URL bar mean, if they're even aware of the URL bar at all, as decades of user research have taught us. So it always just comes back to hand-wavy stuff. And hand-wavy isn't enough to justify the cost of the system.

Meanwhile, we have real, hard evidence that even technically-literate, security-savvy users can easily be fooled into giving up their credentials, and even will bypass mechanisms intended to get in the way of them giving up their credentials. I'm going to keep plugging this phishing talk until everyone has internalized that message:

https://www.youtube.com/watch?v=ZjW12K0IHgo

> but have you ever seen a truly malicious use of EV?

Assuming there hasn't been, I think this just supports the idea that EV certs aren't useful: the bad guys don't even feel the need to try to use them maliciously!

Or the return isn't worth it. Malicious actors have to assume that any given domain, certificate, URL, etc. will get blocked or shut down by the security industry, so being able to cycle those endpoints is key. EV is not easy to automate/cycle, and can also be more cost prohibitive, so each cycle is less profitable as well.

That's my point: Systems that don't scale are less profitable to attempt to abuse for malicious ends, because more time and effort has to be invested into any given effort, and ideally, there are actual humans involved in the process which catch discrepancies.

The other reason you may not see a lot of attempts to find exploits in EV (apart from Ian) is that most of the actors sites want to pretend to be aren't using EV either. If you want to fake yourself as Google, EV isn't going to help you since Google doesn't use it.

I would argue the claim "bad actors aren't trying to abuse it so it isn't effective" to be silly, as that claim would apply among all methods that bad actors can't meaningfully abuse.

That's obviously specific to the US, but more to the point: they (Digicert) are looking at moving EV to trademarks which is nationally registered and a better match for 'verified brand'

It's got more credence coming out of Troy's mouth than, say, a random commenter's like mine, his somewhat bit too scathing snark notwithstanding, but on the "stripe.ian.sh" thread a few months ago I observed [1] that EV, or rather, people's mental model of the trust that EV confers is broken. People typically care about whether the site they arrived at was the one they were intending to visit, which the computer can't possibly know without additional input, but EV has attained a role of serving as a flawed signal of such, because the browser bar said something that doesn't look alarmingly different.

What we're seeing now is the convergence of forces that are pushing short-lived, automatic DV certs and players who are keen on de-emphasizing EV's imperfect role as a destination surety signal.

Big sites can get by with DV because people trust big sites by fiat, just by mental associations they already have to a URL. There's no benefit to Facebook having an EV cert, because literally everyone who'd want to visit Facebook knows Facebook's URL. User error about entering credentials on the wrong site -- accidentally due to typosquatting, or through leading such as phishing -- is better mitigated in other ways: multi-factor authentication (especially unproxiable such as U2F); not by making the high-profile site pay thousands of dollars for a text string in green, when there's users who fall victim to phishing from bizarre domains too.

[1] https://news.ycombinator.com/item?id=15904513#15909273

It's got more credence coming out of Troy's mouth than, say, a random commenter's like mine, his somewhat bit too scathing snark notwithstanding

If a CA flogs a guarantee for very expensive certs, but fails to explain what it entails. Then bloviates about nerds on the twitter account of the CEO to then block Troy (who, once again, asked a super legitimate question) then they not only deserve all the snark slung into their general direction.

No, they deserve to fucking die!

I actually found EV useful especially when logging in financial websites. Of course most people can't make the difference between http and https but I thought this issue will only be fixed by time.

That's actually how I found out my Lenovo was doing MITM a few days before the whole Superfish debacle exploded on the net. I went on Bitbucket (I think) and noticed something seemed different, I realised it wasn't showing an EV certificate: I dug deeper and saw that the issuer was suspect.

I feel that EV certificates do have their use for high-worth targets (banks and so one). Getting one is not trivial and definitely not scalable. Maybe they are a bit overpriced, maybe the certificate industry is kind of sketchy, but that's other debates.

I get that it's unreasonable to expect users to distinguish EV from DV certs.

But a machine should be able to distinguish. There should be an Expect-EV pin header, just like HSTS and Expect-CT. That way you can be sure the certificate wasn't issued via DNS hijacking.

We have UI that distinguishes verified accounts from non verified accounts in almkat every current communications system.

And yes, machines can distinguish EV, there's an OID (field) if every EV cert for it.

A machine that just distinguishes it then does nothing is useless. I want the browser to enforce it.

EV doesn't have the user distinction benefit of a blue checkmark if no major websites use it. No one notices EV. Twitter randomly switches between EV and non-EV, but no one gets worried.

You could feasibly (as of recent Mozilla builds) have the browser warn on POST requests to non-verified sites, but it requires verification to get more popular.

Any system starts from no usage, and no education and works up - every bank, payment and fintech company is a pretty good start. Browser security indicators resembling more common verification indicators would help.

Do you have a source for the POST thing? I can't find anything by searching.

Yeah, I agree EV has some potential for users to distinguish. If we add mechanical way for the browsers to enforce it, that could help increase website adoption, and thus also help users to notice it more.

The root problem is SSL/TLS was largely promoted, for years and years, as conflating two concerns:

1. Can an arbitrary third party eavesdrop on my communications?

2. Am I communicating with who I think I'm communicating with?

It is now extremely easy to handle use case (1). Use case (2) is still genuinely hard, because even extremely technically literate security-savvy people can still easily be phished (my current go-to example is this talk: https://www.youtube.com/watch?v=ZjW12K0IHgo).

Compounding the problem, many people insisted, for many years, that use case (2) was the overwhelming majority of all the value of SSL/TLS, and use case (1) was at best a tiny microscopic fraction of a fraction of a fraction of what was useful about SSL/TLS.

Lest you think I'm exaggerating: I've spent years arguing with people, including right here on HN, about this, and being condescendingly told that identity verification is the crown jewel, and that if I'm not going to make use of that then I might as well literally just go back to plain unencrypted HTTPS, because apparently that's actually better than using SSL/TLS without identity verification.

Also, I really recommend watching that video I linked. It's a security engineer at Stripe, talking about how she ran some pretty successful campaigns within the company. Whatever you may think of them, they're not unlettered philistines. But even things like your "Expect-EV" wouldn't have helped -- she cites an example of people noticing their password manager wasn't autofilling, because it knew they weren't on the expected domain, and then users manually copy/pasting the credentials out of their password manager anyway. There just aren't any easy "just do X" technical solutions here.

> she cites an example of people noticing their password manager wasn't autofilling, because it knew they weren't on the expected domain, and then users manually copy/pasting the credentials out of their password manager anyway

One big reason people do that is because probably 99+% of the time their password manager fails to fill the fields is not because it is the wrong site.

It is almost always because the site has done something with its fields that is either preventing the password manager from finding the fields, or is blocking it from filling them (often intentionally).

Why people bypass the password manager's domain checks isn't relevant.

The issue is that credential stores which know how to recognize the "real" version of a site aren't going to achieve the level of effectiveness we'd like to have against phishing.

Yeah, Expect-EV would do almost nothing to help prevent phishing. That's what U2F is for.

Expect-EV would prevent attacks like[1][2] where a domain is hijacked via DNS or BGP. U2F wouldn't help with these attacks. I know that phishing is a much bigger problem than domain hijacks, but domain hijacks do happen, so it would be nice to have protection.

[1] https://www.wired.com/2017/04/hackers-hijacked-banks-entire-...

[2] https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/

No, it isn't easy to have (1) without (2). The people telling you that you were wrong in those arguments are correct, and you're still mis-understanding cryptography.

Encryption without identity verification is objectively worse than no encryption at all. The reasons are straightforward:

• Encryption isn't free. Whilst performance has improved, there's no heartbleed without OpenSSL. It adds complexity, it adds a TON of extra work and operational problems like key expiry policies, and in general increases your attack surface.

• We generally feel the complexity is worth it to block MITM attacks. But if you are just handshaking with whatever is answering your packets, you aren't blocking MITM attacks.

The assumption underlying your position is (being generous) that the world is full of passive MITMs who can't also take part in the conversation, so any Diffie-Hellman key exchange will knock them out. But Snowden proved conclusively that this isn't true. Local attackers can do ARP spoofing, packet injection and other tricks and remote attackers are the NSA who also can perform large scale packet injection and active MITM attacks. Where are the passive-only attackers?

If you aren't stopping active MITM, then there don't seem to be any adversaries you are actually stopping, and at that point the additional (potentially hackable) code required and additional work required is just nothing-for-something.

The assumption underlying your position is (being generous) that the world is full of passive MITMs who can't also take part in the conversation

When I was in college I used to teach friends the importance of encryption by just showing them a live dump of packets on the dorm's LAN. You could see everything: here are the IMs coming to you and getting your away message as a reply, there's your computer refreshing the news site you were looking at a minute ago... it opened their eyes in a big way.

Encryption -- even without checking seventeen forms of government-issued ID from the person on the other end -- does in fact stop that passive surveillance, and like it or not that's a gigantic use case.

The realistic threat model for most people in terms of active MITM is something like their ISP trying to inject ads and tracking into what they browse, or their home router getting compromised. It takes very very little in terms of identity verification to shut that down; DV certs, which you can get by the truckload, for free, from Let's Encrypt -- will handle it just fine. Which means you don't need EV for that.

As to Snowden, I'm reminded of James Mickens' famous breakdown of threat models. All the Ultra-Verified Premium Secure XP+ Guaranteed™ certificates in the world ain't gonna help if a major government decides to come for you.

EV is snake oil. It literally does not solve any realistic problem the average person has when using the internet; all it does is line the pockets of the cert vendors. DV is the absolute most you need to shut down the things you can shut down, and encryption in general -- even without verification! -- is just fine, thanks. I know I might have a secure channel to Satan. I care about the "secure" part, not the "Satan" part.

Also, as I often do when faced with a true believer, I'll ask you: how many times have you initiated an SSH session with some host for the first time and just accepted past the initial warning? If encryption without rigorous verification is "objectively worse than no encryption at all", why didn't you just telnet instead?

I actually kind of agree that EV certificate inspire more confidence when buying something on a dodgy website that you never heard about. But for that one needs to be tech savvy enough to even recognize what an EV certificate is and how it is different from a DV cert, and I am sure that even most developers aren't sure exactly, let alone the wider population. So I doubt it gives much benefit to any website.

If only there was some common, easily visible browser UI element that told users when an EV cert was present, so they didn't have to understand the differences between certs.

next: code signing certificates under Windows

a lot of B.S. there too

Yes. Two years ago I bought EV for code signing to avoid Microsoft Smartscreen.

The whole experience left a stale impression: we were then in the process of switching to non-profit and already dissolved the for-profit company but got the EV for the old company anyway! Clearly the CAs have a moral hazard: if they check too thoroughly they will sell less certificates, so it is not in their interest. In my case they blatantly asked me to provide bullshit evidence for the dissolved company!

No wonder that Microsoft Smartscreen doesn't seem to treat EV certificates as all encompassing truth of existence of something. We had to jump through some more hoops to satisfy Smartscreen, the certificate alone was not enough.

EV certs are a useful as a barrier-to-entry when you do cert pinning against roots/intermediates.

Except that HPKP is being deprecated by Chrome (https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...). And I'd suspect other browsers will follow.

When pinning CAs instead of certificates, you’d use CAA instead of HPKP.

That wouldn’t work, as there’s no differentiator between EV and non-EV

CAA isn't restricting acceptance of certs, it's restricting issuance, assuming the attempted issuer is compliant, competent, and that your domain didn't get hijacked.

I don’t mean website pinning. I mean eg apps etc

We're also using an EV cert for pinning in our native apps (in other words, we're not pinning a public key or a CA, but the fact that the certificate is an EV cert), on the theory that this is less risky operationally than pinning any specific details of an actual certificate. We can get a new certificate from a bunch of CAs, but it's tricky for an attacker to get one for our domain name. (no need to reply to this with stripe.ian.sh)

However, now that EV certs are clearly going the way of the dodo, the risks associated with them are likely to increase. CAs are going to be exiting the EV business (and/or going out of business themselves). The dwindling market is also likely to increase the price of an EV cert, rather than decrease it, as remaining purchasers will have a specific need to use an EV cert.

It might be time to re-evaluate.

I don’t think they’re actually likely to go away for many years. The CA/B forum may decide to deprecate them one day though.

no need to RTFA! EV certs were nonsense from the start.

Google seems intent on creating a more confusing UX in regards to EV certs as EV looks more similar to Non Secure than secure sites in Chrome 69.

For now this has given me the impetus to ditch Chrome. All of the other major desktop browsers still provide useful UI for EV certs. I’m less inclined to deal with finances on mobile through a website anyway, as every financial org I’ve had to deal with has an app, and Apple ends up being the gatekeeper in that realm.

Hopefully there will be some sort of push for useful additions to certificate security coming out of Google, as right now they seem more determined to just be undermining things.

That is an interesting way to describe the most effective mover in all of TLS security. No company has done more to improve it. We owe to Google, in at least a substantial way, if not always entirely:

* The dis-trusting of basically every skeezy dis-trusted CA.

* The adoption of TLS 1.3.

* Certificate pinning.

* HSTS preloading.

* The modernization of OpenSSL.

* The Heartbleed attack that prompted the modernization of OpenSSL.

* Certificate transparency.

I'm rattling these off my head and certainly forgetting something. Obviously, if you broaden the question to everything relevant to browser security, the list gets much longer.

Your list seems focused on behind-the-scenes TLS implementation details. I have no doubt Google has contributed positively in that regard.

Personally, I've found their handling of the Symantec root distrust mediocre (from the perspective of an affected site owner). However, the biggest issue is the changes to the display of certificate info in Chrome 69. To present a certificate with an authenticate legal entity the same as an insecure site indicates we have different priorities, and they no longer align.

That isn't true. Unencrypted sites show up as "Not Secure" which is different from how encrypted sites show up.

Both EV certs and non secure sites show up as:

[icon] Grey Text | example.com

Secure, non-EV sites show up as:

[icon] example.com

No, non-TLS sites show up with a "Non-Secure" label next to the hostname, like the parent commenter said.

Please re-read my comment. The issue is that non-TLS and EV cert TLS sites are presented with exactly the same visual presentation. Low-contrast gray icon, low-contrast gray text, vertical bar, domain name.

non-TLS sites show up as: "Not Secure | neverssl.com". The literal words "Not Secure" appear for non-TLS sites. Those words do not show up for EV sites. That seems like a pretty drastic difference. I'm on Chrome 69. Maybe I'm part of some experiment - but, I don't think so.

If I'm reading you correctly, your actual point of contention is “nonidentical icon/text without a much larger color/layout difference looks sufficiently similar in overall appearance as to be essentially identical for the purpose of conditioning users who aren't intentionally looking”. Except you've decided to incorporate this assumption into the definition of “same visual presentation” and frame it as implicitly true in such a way that anyone who might not agree with it is assumed to have misunderstood you. Charitably assuming that this wasn't deliberate, there's a lot more inferential distance here than you think.

I actually suspect you're mostly right (the EV color is green, not gray, in the Chromium I'm using, but I can imagine this not being easily visible under many conditions), but the way you've decided to talk about this has made me very hesitant to openly agree with you. But for those whose answers are meant as “it says ‘Not Secure’, therefore it's adequately different”, I might be skeptical on the grounds of “having the user know that requires clearing a higher attention bar first”, aka “users don't read”.

> If I'm reading you correctly, your actual point of contention is “nonidentical icon/text without a much larger color/layout difference looks sufficiently similar in overall appearance as to be essentially identical for the purpose of conditioning users who aren't intentionally looking”.

Yes, the decision seems to be intentionally making them confusing. That or else I can only assume they didn't really think through the design decision much.

However, my understanding is that Google is intending the EV company info to be removed from the address bar altogether in a future release. Both of these decisions seem to be poor choices, in my opinion, and I think it is a loss of useful information.

By contrast, Safari 12 no longer displays the EV company name in the address bar, however EV certs result in the lock and domain name being green, and if you click on it, you get a nice popup explaining what legal entity the certificate is issued to. In Chrome, to get that information you have to dig a few levels deep, expanding a tree control and understand X.509 certificate fields.

Based on that changes that are being made in Chrome, it seems they want it to be difficult to learn what information is contained within the cert. But then the rationale is that no one understands what EV certificates means. If there was an honest effort in helping users understand security, I would think their experiments would involve making it easier to find certificate details and understand them, not remove them and make them similar to non-secure sites. This is why I said in my original comment "Hopefully there will be some sort of push for useful additions to certificate security coming out of Google, as right now they seem more determined to just be undermining things."

It isn't too far a stretch to think that the lack of effort in improving he display of certificate information and trying to downplay URLs is because Google wants more users to become more dependent on them as the way to find and authenticate web sites.

I'm definitely not giving you "dis-trusting of basically every skeezy dis-trusted CA" for Google.

All the heavy lifting continues to be done by m.d.s.policy, which is Mozilla's, not Google's if it's anybody's. I used to want to believe that the (behind closed doors) other root programmes also had their own effective mechanisms. A few years of working with m.d.s.policy and watching absolutely nothing else making any difference disabused me of this notion. It gets done in public or it doesn't get done at all, and m.d.s.policy is where it gets done in public.

Does Google have (mostly in the form of Ryan Sleevi who is a Google employee) a contribution to m.d.s.policy? Sure they do. But there are quietly also people from Microsoft and others paying attention, it's just that Ryan is much noisier, for good or bad.

If I was going to single out a _person_ for this work it would be the late Gervase Markham, who was a Mozilla employee. The big list of problems at StartCom is Gerv's list, for example. I think even the idea to go after auditors not just CAs was Gerv's idea.

I'm really not interested in whatever weird personal problems you might have with Ryan Sleevi, sorry.

> For now this has given me the impetus to ditch Chrome.

I think you're approaching this precisely backwards.

> All of the other major desktop browsers still provide useful UI for EV certs.

There is no useful UI for EV certs, because EV certs are not useful.

> right now they seem more determined to just be undermining things.

Citation needed?

> I think you're approaching this precisely backwards.

Based on what criteria? It seems that Google and my interests are aligning less and less. I am starting to care more about privacy. And now Google is removing useful features that I use regularly, so I am stopping using one of their main products, and starting to look into alternatives for other product.s

> There is no useful UI for EV certs, because EV certs are not useful.

You are incorrect in this statement. They are useful to me, because they help me ensure that I am interacting with the website belonging to the company I have an existing relationship with.

> Citation needed?

The citation was the topic of my post. In Chrome 69 they are making the UI for EV certs confusingly similar to non secure sites. The handling of the removal of the Symantec root was handled poorly in terms of helping site operators know they could get a replacement certificate from DigiCert. As a certificate consumer, these are the two interactions I've had with Google in regards to certificates, and both have been negative.

> And now Google is removing useful features that I use regularly

The article makes pretty compelling points that almost no one finds EV certs useful. Maybe you do. Maybe you think you do. I dunno. But, regardless, unless the article is wrong, you are in a tiny minority. Removing special handling of EV certificates reduces pressure on people to buy these certs based on false promises being made about them being generally useful - and that's a good thing.

> The handling of the removal of the Symantec root was handled poorly in terms of helping site operators know they could get a replacement certificate from DigiCert.

The problem with Symantec having horrific security was that Google handled it wrong? This was Symantec's issue. I also don't like that when I google "Do I have to pay my parking tickets" the answer is yes - but that isn't Google's fault either.

Google have done no research on the effectiveness of their browser identity indicators, so I'm not sure where the evidence that they're not useful have come from.

Well, you can certainly apppreciate the fact that for EV, Apple is also changing the indicator. Perhaps it is only a matter of time before Fifrefox does it as well. The logic is reasonable, EVs are not widely used and therefore not worth having as most users probably don't use it to assess the legitimacy of websites. They are also expensive as all hell as I can see from the article.

Considering your point that the way EV are displayed is similar in form to not secure, I find it weird. As the article points out, on mobile the EV looks not different than a DV. On desktop, it is written the full EV name versus the "Not secure" label.

It seems EVs are on their way out, you should at least concede that. It seems the Chromium team are pushing for accentuating the top domain name instead, so there's that.

Reply on news.ycombinator.com