I don't understand the glee, schadenfreude even. So because the UI side of things didn't work out, it is an improvement that now all certificates will go back to the "crusty Perl script fetching a side-channel secret from a webserver" method of "validation"?
On the contrary, we should just push for extended validation on all certificates. Whether they come with a fancy UI or not.
Because if we are on the topic of https UI effectiveness, then I'm pretty sure everything we have right now is doing a horrible job and could be removed with much the same tenuous reasoning.
"I don't understand the glee, schadenfreude even."
Because he has personally been on the front line of the debate, been told by lots of people and entities with power in the relevant domain that he's wrong, and events are proving him right, at least in terms of his predictions about what would happen. Taking a bit of a victory lap is only human. I thought he was suitably discreet about it.
Separately, I think it there is improvement here, which is that the system is no longer claiming to be securing an element of the connection which it isn't really securing. Sometimes if you want to make progress you have to clear the fake solutions out of the way that are just sitting there creating the illusion the problem is solved, so that nobody tries a real solution. Personally I'd say that what we have right now does a good job of being what it is, it's just that there's a mismatch between what it is and what people thinks it is. This makes room for other potentially better solutions by helping to resolve that mismatch.
(In a nutshell, the system is good at asserting that you are speaking to someone who has convinced the world that they are capable of serving web requests issued using a particular domain name (I tried to write that carefully), and that nobody in the middle of that connection can intercept or modify the contents. We can now clearly see a problem in how we connect that legal entity to the domain name, without EV certificates sitting there pretending to solve that problem.)
It’s because the existing system is built around greed more than quality identity verification. I wouldn’t be able to verify the identity of someone in (ex:) India and, I assume, it’s just as hard for them to verify mine. Every time I’ve done verification for code signing I’ve dealt with someone who, IMHO, wasn’t qualified to verify my identity.
One of the worst experiences I had was getting docs notarized just to have the CA turn around and ask me to send them a list of notaries in my area so they could call the one I used.
The whole system is terrible and the margins are so huge that nothing will ever be fixed unless the CAs are forced to come up with something better.
Because it makes the people who complain about LetsEncrypt go away. EV certs (arguably) provide extremely little value while allowing an industry to extract money for no reason and also publish FUD about LetsEncrypt, which is among the most impactful projects in history for getting humans to use encryption.
The only meaningful impact of LetsEncrypt and HTTPS Everywhere pushes is that now most phishing sites use HTTPS. Since most non-technical users trust the presence of the lock icon (even though they shouldn't), this has been great for phishing sites.
Then again, the phishing problem is that you can get m1cros0ft.com registered. If you can get that one and trick someone, you won. If you can get it and a cert for it (free or not) then you as a phisher win. If you can't get it, then you can't get an LE cert for it either and you lose. Therefore, the LE part is just icing on the cake, not the enabler for scams.
Cost is a barrier to entry, and when you are scamming people, you often have to be able to generate large numbers of scam attempts, as most will fail. A cert costing $70 is a big deal for a scammer, because a scammer may need to get certs for a large number of domains. Therefore, before HTTPS Everywhere, phishers weren't using them much, it added a lot of cost to each attempt. Now, it's a requirement to avoid warnings in browsers, and the certs are free, and hence, all phishers now use HTTPS. And unfortunately, a whole generation of computer illiterate users believe that lock means the site is legit.
> a scammer may need to get certs for a large number of domains.
Why? In the m1cros0ft.com example, you just need one domain, and you can send a phishing link out to millions of addresses.
> And unfortunately, a whole generation of computer illiterate users believe that lock means the site is legit.
That's exactly why EV doesn't help, because those users _also_ don't know that the absence of green is supposed to carry semantic meaning. In fact, those users largely don't know or care what a URL is in the first place.
HTTPS everywhere is unequivocally a good thing. I can (and do) personally run websites that have active user accounts precisely because of LetsEncrypt; it would be a terrible idea to train my users that they should type a password into a form that's submitted over HTTP. But I don't have a budget to pay rent-seeking CAs for certificates whose value is based on artificial scarcity.
Phishers weren't using SSL before HTTPS Everywhere much because it didn't matter. Most users (and in particular, unsophisticated users that are more likely to fall for phishing attempts) who type in passwords by hand aren't going to notice the lack of a padlock. We needed HTTPS Everywhere before browsers could meaningfully penalize the HTTP experience, otherwise they'd be penalizing the majority of sites on the internet. And we can't have HTTPS Everywhere unless SSL certificates are easy to obtain.
Which is to say, the fact that phishers can obtain a LE cert today for their phishing site and therefore not have the "Not Secure" indicator is not meaningfully different from the old days where they'd use HTTP and not have the small green padlock that most people don't notice.
Maybe EV isn't the answer. But there is opportunity for something else out there, because right now https is not living up to the "authentication" promise when you have Firefox, Chrome et al. kotau to company proxies and all kinds of dubious state CAs in the trust root.
That's before you get to the UI failures, where phishers can trivially get that lock for their microssoft.com domains.
> But there is opportunity for something else out there, because right now https is not living up to the "authentication" promise when you have Firefox, Chrome et al. kotau to company proxies and all kinds of dubious state CAs in the trust root.
There's already a lot of things being done to improve the situation. Honest question: Are you aware of them? Do you know Certificate Transparency? Have you followed the intense discussion about Dark Matter? Do you know what the Baseline Requirements are? Do you know how Webauthn prevents Phishing?
There is a security benefit to EV: the paper trail to which the CA attests. That provides a tool that law enforcement can use to track you down if you use your EV-cert-provisioned site to commit a crime. To get an EV cert, you must prove to the CA your identity, portions of which are then encoded in the cert itself.
This is analogous to how a fraud is discouraged in physical stores. A street address and business license won't prevent a store from ripping you off. But it gives you plenty of info to pursue a complaint if it happens.
That's assuming you even get an EV cert though. EV failed because it didn't provide any benefit, as evidenced by sites like PayPal (which you would think is the poster child for EV) ditching it. Because it didn't matter to users if you had an EV cert, you didn't need to get one.
The reason why "Stripe, Inc." is interesting is because it disproves the whole claim that users can trust the business name displayed, because they can't. It doesn't matter if the CA has a paper trail for the EV cert, because nobody's saying people will use EV certs for large-scale phishing attacks (users don't even notice its absence to begin with so there's no point). But since you can't trust the business name, it means EV is actually an attack vector for spearfishing. Pick a single high-value target, get a misleading EV cert, get them on that site. EV is now a significant negative.
> The reason why "Stripe, Inc." is interesting is because it disproves the whole claim that users can trust the business name displayed, because they can't.
The only people who made this claim, did it so they could attack it.
The only claim of the EV system is that the display name matches a real legal entity, which is not the same thing as being consumer-recognizable.
The intent with EV was that the presence of its UI element--regardless of what it said--would confer trust. The idea does not rely on users recognizing the company name any more than trust in physical stores relies on users memorizing street addresses.
The concept is that a legit company would opt to tie its online presence back to its legal entity (via an EV cert), but a scam would not because doing so would take more effort and make it harder to escape.
Again: this is analogous to the effort that it takes to set up a physical store. You can buy things off the back of a truck, but everyone knows that is sketchy. You don't know where that stuff came from, and you have no recourse once the truck drives away.
Setting up a store is a lot harder than driving up a truck--a company has to establish a legal presence in the jurisdiction, sign a lease, get a business license, comply with all sorts of regulations, pay taxes, etc. But they go through that effort because doing so confers trust. It is this system that is behind the social convention that it's ok to walk into a new store and hand them your credit card to buy something.
The goal of EV, of the CA system in general, was to try to create a similar set of trust signifiers and conventions online.
> The intent with EV was that the presence of its UI element--regardless of what it said--would confer trust.
I don't see how you can say that.
If I go to paypal.com and see "Joe's Pizza Shack" in the green text, there's no way I'm going to trust it.
If a phisher is capable of legitimately acquiring a certificate that says "Stripe, Inc." just as they could one that says "Joe's Pizza Shack", then the presence of the green text means nothing more than "someone was convinced to pay money for green text", and it certainly doesn't mean I'm talking to the company I thought I was.
And the ability to get a legitimate certificate saying "Stripe, Inc." means that EV can aid phishing attacks, because the existence of the green text is supposed to trump all other trust indicators ("is paypalcares.com legitimate? It's got the green 'PayPal, Inc.' text, it must be!").
Which is to say, users don't notice if the green text is gone, meaning it has no benefit, and users may trust the green text over other warning signs, meaning the ability to successfully spoof another company's green text makes EV an attack vector rather than a defense.
> then the presence of the green text means nothing more than "someone was convinced to pay money for green text"
It means someone was willing to pay money and publicly confirm their legal identity.
I think you under-appreciate the implications of that, and are overly focused on the mechanics of phishing (which is just one aspect of security). Even if EV certs are not any better than DV at preventing phishing, they're better for investigating phishing.
If that worked well, over time it would create a deterrence around using EV for crimes, which would not be perfect, but would create an improvement in trust.
But it doesn't work well. So to be clear, I'm explaining why EV certs exist--what they are actually for. I'm not claiming the system works great; in fact I think it's pretty crappy how poorly it's implemented by the browsers. As you note elsewhere, it's hard to see and do anything with the extra info in an EV cert. And I have to wonder why that is.
> Even if EV certs are not any better than DV at preventing phishing, they're better for investigating phishing.
Except general phishing sites won't use them, which means they won't do anything for investigating phishing. There's no need for phishing sites to use them since users don't notice.
The only real scenario where they'd be used is in a spearfishing scenario where it's worth the risk in order to snag a high-value target, especially because it's a lot less likely that your misleading EV cert will be captured by investigators (once you're done with that one target, take down the site before anyone can look into it).
I'd rather not go back to the 2000's and earlier method of validation that required faxing in paperwork, then waiting days and days, etc. This is paperwork which could easily be forged, by the way. Finally, after decades, it is simple enough to get TLS that people actually do it.
On the contrary, we should just push for extended validation on all certificates. Whether they come with a fancy UI or not.
Because if we are on the topic of https UI effectiveness, then I'm pretty sure everything we have right now is doing a horrible job and could be removed with much the same tenuous reasoning.