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.
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.