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