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.
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)
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?
> 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'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.
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.