Plus this article explains, in great detail, why EV didn't work/couldn't work. Google didn't cause that, nor did Apple. Researchers have been creating examples of EV's problems for years and the evidence has been mounting against them.

The vast majority of examples of EV "problems" are people who misconstrue what EV is supposed to do, and then prove it can't do that thing. For example, EV was never intended to guarantee globally unique company names, so demonstrating a name collision does not actually show a problem with EV.

I'm not really sure why you're including Microsoft in here either, but I'm a lot less familiar with Microsoft's various product offerings so maybe there is some reason why they care about the public identity business.

Note here that using the mobile app is in no way any form of lock-in, because the exact same app will exist for Android too, and it's free, so there's no barrier to switching platforms.

EV has issues, which the article exaggerates (Troy Hunt has amazingly good services, but absolutely terrible opinions), whilst failing to recognize that the alternative is completely useless.

no it's not?

The title is referencing the author's post on EV certs being dead after the change in Safari and the article quotes Google, Mozilla and Apple's reasoning for the change. Your argument should be with those statements, not a narrative you're forcing on the events.

In other words, HTTPS encryption meaningfully requires some kind of public key infrastructure.

Without some kind of infrastructure, the whole system falls to any active attacker --- and almost all modern attackers in the TLS threat model are active.

And even for well-known domains, https://www.xn--80ak6aa92e.com/ (currently still works in Firefox) is an excellent example of why domain validation remains completely useless.

[1] https://money.cnn.com/2017/09/20/technology/business/equifax...

This is one of the older controversies on m.d.s.policy, for whatever it's worth to you.

I don't really care where you or anyone else comes down on this, as long as we all agree that you can't just jettison certificates and let HTTPS "just provide encryption", which is a common HN refrain and is clearly unsound reasoning.

I am not saying issuing self-signed certs are great, merely that CAs do not meaningfully improve on them if domain validation is all we have, because domain validation doesn't tell you a heck of a lot.

As you said in another response, the CA system has problems. EV, at least, represents something useful when issued by a CA and solves a real problem. And the problems with EV Troy complains about are all fixable.

The CA provides multi perspective check from servers connected to internet backbone, where network hijack is harder than at cafe wifi AP.

If Microsoft included a self-signed cert in my Windows install for itself, I would know my communications with Microsoft came from whoever made my Windows operating system. Meanwhile, with PKI, dozens of companies can technically generate certificates for microsoft.com and we're just all hoping none of them do it without getting caught.

Those changes are being largely driven by Google/Mozilla/etc, via enforcement around what CAs must do in order to be part of the root of trust.

Switching to self-signed certs doesn’t remove any problems. With current PKI, dozens of companies can generate certificates for my website which will be trusted by user browsers. Without PKI, literally anyone can generate a self-signed cert for my website, and there’s no concept of which certs are valid, unless somehow everybody finds a way to share which certs are theirs (and solving that is generally called “PKI”).

EV doesn’t allow self-signed certs to work either, or viably replace DV certs for any threat models, because it’s just as easy to register a similar-sounding company name as to register a similar-looking domain name. Arguably it’s easier, because you can actually register exactly the same name, just in a different jurisdiction.

A rogue/compromised CA will be caught by certificate transparency and distrusted.

Also, as 'tptacek noted, you haven't explained how to securely use self signed certs to protect against attacker at the WiFi AP, which is a very accessible kind of attack (compared to compromising a CA, a registrar, a datacenter or internet backbone traffic).

How is it that this still works in Firefox? It's been fixed for years in all other major browsers. I'm seriously shocked that Firefox still allows IDN homograph attacks.

TLS protects you from active attacker at your internet cafe wifi or small ISP or not-tier1 country's ministry of propaganda.

If the network between multiple aws/gcp/azure regions where e.g. let's encrypt's acme servers are deployed and the server you're talking to is hijacked, TLS doesn't help because hijacker can get valid certificate.

It is trivial to get an EV cert for a company that has the same name as a trustworthy entity[0]. There is nothing in the design of EV that prevents this, and name collisions between corporate entities are common and acceptable practice[1].

[0] https://stripe.ian.sh/

[1] Trademarks are a different matter, but getting an EV cert for a company that has the same incorporated name as a different company in a different state is completely legal.

It is legal. But it's also much more easily traced (even through various shell companies as process agents want to get paid), which compared to the way most crime works on the internet is infinitely more risky for the perpetrator.

Also, companies like banks regular scour business records for similarly named businesses, which means the window for fraud is smaller. I'm not surprised that someone would find it easy to spoof Stripe, but let's see how long they manage to spoof PayPal or Bank of America. If they don't already, EV certificates should issue only after the named entity has existed for N months (or years).

There’s a separate rule that you can’t name a new bank “America” or “USA” or anything like that. The existing ones are grandfathered but no new ones are allowed.

can't they also scour the certificate transparency logs as well? I'd imagine that's easier and more reliable than scouring the public records of hundreds or thousands of jurisdictions.

When SSL first came out there was a heavy focus on informing the public to check for the padlock; that if they were worried about fraud then checking for the padlock was a concrete step they could take to help reassure themselves. But there was never a similar campaign regarding EV certs. There were attempts, but they were short-lived and not nearly as aggressive. Partly that's because the messaging was more difficult, but it could have been done.

Google could have put more effort behind it. But they weren't interested, partly because as someone else mentioned they have their own ideas about how to move forward, ideas that just happen to fit in better with Google's commercial interests. Some of those ideas are reasonable, but again this isn't an either-or situation. They're making it either-or.

you've got someone to sue if criminal activity happened which is already miles better than the current situation.

Which is exactly why name collision are not actually a failing of EV and why the Stripe EV trick, while cute, did not demonstrate anything meaningful about the utility of EV certs.

EV was never intended to be a perfect phishing prophylactic, so I can't understand why people seem to get so much mileage out of pointing out that EV's can't prevent all phishing.

What EV certs do better than DVs is provide a paper trail for sites that commit crimes. To get that name-colliding Stripe EV cert, Ian had to use his real identity to create a company; he even helpfully links to the record! That's going to make it a bit easier for law enforcement to track him down if they are investigating his website.

Unfortunately, the only meaningful form of identity confirmation we have is being railroaded away using one-off examples of imperfections that can be fixed fairly trivially, and which have never been effectively used maliciously.

Fundamentally I believe security doesn't scale, and that something you can automate is inherently inadequate for security. Which is perhaps why I have so many security problems with Google's approach.

It really does though, because without PKI a MitM attack is totally undetectable. That means any ISP can tamper with and read all your stuff. Any public WiFi can trivially read all traffic over the wire. Any temporary and intermittent manipulation of DNS comes with immediate compromise. And on a LAN, that affects IP or name resolution is compromised.

The only thing you would defend against are constrained infrastructure managers (those who could MitM but don't have the resources) and people sniffing the line but not able / willing to modify data on the line. That would be really covert agencies and people with a WiFi sniffer.

I agree that for PKI in general, something like EV would be great. But that is a lot more useful for something like S/MIME or a replacement of PGP, not in the case of HTTPS.

This largely misses the point. PKI infrastructure allows me to click a link from a trusted webpage (like a search engine which removes malicious content) to an unknown website and be reasonably sure that I am talking to same unknown web site that the search engine looked at. It's right there in the name "web" - trusted sites refer to other sites by domain, so domains are what we need to validate.

If true, that says more about the usefulness of PKI, than the usefulness of EV certs.

> And the only reason it's being pushed out is because Google doesn't like it and hence Chrome has been retiring it.

Google is far from the only people that don't like it, and far from the only ones pushing for their abandonment. They're fundamentally broken, in my view. And it's worth noting that Google/Chrome is just following the trend of not using them; are they really driving anything here?

This allows EV to have real benefits without requiring any user alertness.