Thursday, May 12, 2022 [Tweets] [Favorites]

Extended Verification Certificates

Troy Hunt (via Nick Heer):

Ah, now we know the cert has been issued to DigiCert Inc. in the US. So, all good right? No, because who are they? I mean, all we know is that the cert has been issued to an entity with that name, we don’t know if they are a certificate authority or a company that certifies how many fingers you have on your hand (digits - get it?). This is what Ian Carroll demonstrated a few years back when he got an EV cert for Stripe Inc. Perfectly legit cert issued to a perfectly legit entity, just not the one everyone thought it was.


Amazon doesn’t have an EV cert, inevitably because they’re smart enough to realise it wouldn’t do them any good if they did! But you see the problem: if DigiCert wants to make the case that you should inspect a cert by drilling down 2 clicks (not one) before trusting the site, that clearly flies in the face of how the web actually works. Same with eBay. Same with Alibaba. Same with the little shop I buy my coffee from. Don’t “look beyond the lock” because if you do, you’re not going to be buying anything online any more.


Let’s keep humouring DigiCert: how do you look “beyond the lock” on mobile? You know, those devices that are now massively dominant in the mobile shopping space? The ones that account for about three quarters of all e-commerce sales? Try it on Safari on iOS. Can you figure out how to inspect a site’s certificate? You won’t, because you can’t.


Joshua Ochs

At what point do we admit that the entire "trusted authority" system of certification is fundamentally broken? We keep seeing misuses of it, unfixable problems, and breakage left, right, and center, but keep on as if it's the only possible way. And meanwhile, we make perfectly valid uses of encryption (self-signed certificates for home, development, etc) more and more difficult to deploy. Surely we've come up with better systems to verify/trust remote systems in the last 30 years?

@Joshua Ochs:

We have; it's called DANE (or SSHFP, for SSH): simply publish keys or their hashes in DNS. But for silly political and self-serving reasons the Great and the Good in big tech and government refuse to endorse it. (Certificate Transparency is clearly only helping the big players, of course we can eventually fix middleboxes, convenience of other solutions taken up by the big players is no match for security, not to speak of good design, etc.)

@ Joshua: we can do centralized identity with CAs, registrars, governments, etc., and that creates incentive problems (very easy for a CA to set up a business that doesn't really _do_ much of anything other than collect money in exchange for reputation) as well as privacy issues. Or we can do decentralized identity with Web Of Trust, etc., and there's a multitude of reasons that has never taken off and perhaps never will.

@ Sebby: DANE just ties the identity of TLS to that of DNS. It doesn't really solve "is this who they think they are"; instead, it punts that to "well, maybe the domain registrar is more trustworthy than the CA".

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment