Hacker News Reader

I don't understand the odd focus on Google/Chrome here. Apple got rid of EV long before anyone else (on mobile Safari, then later MacOS Safari). Google is following Apple.

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.

Apple, Google, Microsoft, all dislike EV for the same reason: because it is a decentralized tool for establishing identity. Identity is something they prefer to own proprietarily because a) they trust themselves more than anyone else, and b) it is lucrative.

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.

Why do you claim Apple dislikes a decentralized tool for establishing identity? No part of Apple's business is even remotely related to what EV certs do, and the closest they come to "identity" in general is the recently-announced "Sign In with Apple", which is personal identity for use with other services, not a public identity or anything used for a company. Apple cares about this purely for user experience, nothing else.

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.

You don't think Apple cares whether you feel safer downloading the Bank of America iOS app from their carefully curated App Store, instead of navigating to bankofamerica.com in mobile Safari?

Correct. Apple doesn't make money off of your interaction with BofA either way. They care that you have the best experience and continue to use their platform, but whether you use bankofamerica.com versus a mobile app, it doesn't matter.

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.

The article is about Chrome, which is a monopoly-positioned product, making a change, upon where the author has stated that as such, EV is really dead. I am not sure why talking about Chrome here would be an "odd focus". When the dominant party does something, it means a lot more than when a minority party does something.

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.

> The article is about Chrome

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.

The Safari change was mentioned in past tense (a year ago) as was Apple's statement about it, and this article is about the change in Chrome and Firefox.

HTTPS encryption itself doesn't meaningfully require public key infrastructure, it's just that without PKI, you don't know who sent the encrypted traffic

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 it fails to be useful without a way to tie it to a brick-and-mortar entity, aka, EV. Which is my point. That was exactly what PKI could bring to the table.

Either you're not understanding me or I'm not understanding you. I'm making a simpler point: some kind of authentication does indeed have to happen in TLS. Without it, TLS provides essentially no security.

I'm saying in a world where equifaxsecurity2017.com is a real domain, and securityequifax2017.com is a fake one that the real Equifax Twitter account posted[1], domain authentication is not authentication at all. As such, without EV, TLS provides essentially no security, correct.

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

Your complaint is about phishing. I agree that phishing is too easy. But that concern is orthogonal to (and significantly harder than, both technically and from a policy perspective) reliably encrypting the TLS transport.

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.

You could jettison PKI though. Self-signed certificates would provide as much security after the initial connection. The theory of PKI is that the CAs are providing a source of trust in the identity of the certificate holder, but that is mostly meaningless if domains cannot be meaningfully connected to real businesses and/or people.

How exactly do you think a self-signed certificate addresses this problem? I connect to BANKOFAMERICA.COM. It presents me a self-signed certificate. How do I know if that's BofA's self-signed certificate, or any active attacker's?

How do you know bankofamerica.com is owned by the actual Bank of America? Or that someone didn't use a Cyrillic character in that URL so it looks legitimate and even has a CA-signed cert? Or that one of the more questionable CAs hasn't given someone else a cert for bankofamerica.com.

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.

You keep answering this question with an unrelated question. Like I said: phishing works and is too easy to accomplish. That isn't an answer to the question I just asked you.

You are dismissing the primary issue at hand, which underpins the entire conversation. Phishing is what EV addresses. And if you're not addressing phishing, you're not meaningfully addressing any sort of Internet security whatsoever.

The incoherence of EV as a response to phishing is part of why it's failed. But I'm not talking about EV; I could care less about EV. I'm addressing your (false, increasingly so as thread deepens) claim that HTTPS doesn't require any form of PKI and that users might as well rely on self-signed certificates. Obviously: no.

The self signed cert will need to be rotated from time to time, without being signed by previous cert because e.g. private key was lost or because private key is known to have been compromised. How will your browser, connected to cafe wifi, know that change in self signed cert since last connection is legitimate vs MiTM by wifi AP in cafe?

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

The CA system also provides dozens of organizations all over the world to issue certificates for any domain and to hand them out to pretty much anyone.

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.

You haven't answered the question. There are flaws with the CA system, yes. But replacing it with self-signed certificates creates new problems. How do you address them?

There are mitigations in various stages of progress for this, like certificate transparency, CAA records, and the removal of CAs who violate best practices through either malice or stupidity.

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.

Your OS or an app talking to their mothership can and do use cert pinning. What about all the millions of websites?

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

> And even for well-known domains, https://www.xn--80ak6aa92e.com/ (currently still works in Firefox)

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 only says you're having a private conversation with a server, not how trustworthy it is. Maybe you're having a private conversation with the devil!

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.

> [1]HTTPS encryption itself doesn't meaningfully require public key infrastructure, it's just that without PKI, you don't know who sent the encrypted traffic. Since domains are terrible "identities" and it's common for large organizations to use many of them that sound similar to scam domains, domain validation really doesn't tell anyone anything about whether or not they're talking to a trustworthy entity.

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.

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

Adding the word “bank” is problematic on its own as the naming itself is regulated.

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.

>Also, companies like banks regular scour business records for similarly named businesses, which means the window for fraud is smaller

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.

I'm sure they can and do. But it's not an either-or situation. Also, AFAIU, EV certs won't even issue without heightened scrutiny regarding domain name ambiguity.

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.

if you're dealing with a known legal entity that's misleading and has phishing content, you're already in a much better spot than dealing with a random dude that paid for bogus dns in cash and signed with let's encrypt.

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

> There is nothing in the design of EV that prevents this, and name collisions between corporate entities are common and acceptable practice

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.

This is why I used the expression "problematic but fixable". There are issues, sure, but as another commenter pointed out, they're easier to trace, and these are problems that can be fixed. Meanwhile, domain validation is only peripherally better than "no validation at all".

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.

Google wants to be the world's business authentication provider, but without taking on the responsibilities of an EV certificate issuer to the "relying party".

That was kinda my impression. Extended Validation is supposed to be complicated enough that you shouldn't be able to automate it, and Google hates anything that it can't automate.

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.

This is no different to when Microsoft launched their passport services, MS wanted to develop a global register to verify everyone's identity. It didn't work. The same identity dupe problem highlighted elsewhere re stripe inc registered in Delaware, also exists when it comes to code signing applications on windows.

> [1]HTTPS encryption itself doesn't meaningfully require public key infrastructure, it's just that without PKI, you don't know who sent the encrypted traffic.

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.

> [1]HTTPS encryption itself doesn't meaningfully require public key infrastructure, it's just that without PKI, you don't know who sent the encrypted traffic. Since domains are terrible "identities" and it's common for large organizations to use many of them that sound similar to scam domains, domain validation really doesn't tell anyone anything about whether or not they're talking to a trustworthy entity.

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.

> The irritating thing is that EV is the closest thing to a useful thing PKI can provide

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?

We can make EV useful if we add an Expect-EV header similar to the Expect-CT header. And ideally add preloading to the header too.

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