Hacker News Reader

Comment by vertex-four | Hacker News Reader

> We're right back to the same level of security of you just checking that the browser bar points at the domain you actually intended to go to.

So you’re sitting in a cafe, and you go to Facebook.com. Lo and behold, someone’s installed a MITM proxy on the router, that presents its own encryption key instead of Facebook’s, and your browser has no way to tell this because the CA system isn’t a thing. They now have your password, can steal your session to spam your friends, whatever else. How do you prevent that?

Automated domain validated certificates are meant to ensure that when you go to Facebook.com, you’re talking to Facebook.com and not a MITMing router on the way there. They’re not meant to protect against phishing - they’re meant to protect against the very real cases I’ve seen where my mobile ISP adds random JavaScript into the web pages I view, and sells information about me based on my use of the web.

View on HN

Idea that's been floated before: TOFU plus a distributed network of people automatically sharing what cert fingerprints they encounter. Chances are high that you already hit Facebook on your $device, and if you all of a sudden retrieved a certificate that didn't match the one you had before, or that most other people online hadn't seen, halt and throw up the warnings.

Given the exploitability, laziness, general failure to follow best practices, not to mention misaligned incentives that we're seeing from major CA vendors, having centralized CAs seems like an ever-worsening solution.

And how would rollover work?

It would wind up being visible to a large chunk of users simultaneously. Furthermore, since we're relying on the wisdom of the crowd rather than a true CA, you'd be able to trust companies' own CAs rather than delegating off to a not-so-trusted third party.

In other words, if someone claiming to be Facebook has told a significant number of people all over the world that Facebook's cert fingerprint is ABCD124, and that fingerprint matches what they're getting presented, it's probably legitimate. We can add additional points for the cert signer being the same one as the previous cert, lack of listing in a CRL, cert transparency logs, etc.

There's no reason this system couldn't bolt on top of the existing CA infrastructure to avoid a bootstrapping problem either.

It adds a probability value into the mix, in other words. That value has always existed, but now we expose it to the user in some way and stop pretending that it does not.

This is what HTTP Public Key Pinning is for; the hash of the public key of the cert tells browsers to not trust a cert for the same domain with a different public key: https://news.ycombinator.com/item?id=16582534

Where do you store the trust from all those people to be able to query the statistics? That's just another central point of failure.

It's not as if distributed hash stores are new...

That didn't answer anything. How can you trust the result if anyone can write there. How can you trust the individual store that it doesn't manipulate its contents, etc.

Technically, certificates automatically validated only guarantees that you are on the website that let's encrypt thinks correspond to facebook.com. MiTM state wide could tamper with it

How so?

Presumably, someone could MITM a CA, and get their own domain validated certificate to another site. The cert may protect you from MITM in a coffee shop, but it doesn't necessarily help you against state-level actors.

It’s currently standard for CAs to host multiple verifiers in multiple jurisdictions, to reduce the chances of this happening, afaik.

Let's Encrypt is developing this feature but it might be a little premature to call it "standard"—it's not specified in the Baseline Requirements and I'm not sure whether there's any CA that has announced it as a part of all certificate issuance.

Most CAs aren't automated :) I believe any that do ensure that DNS requests are tried from multiple different locations to prevent this happening. Though you're right, the standards haven't caught up yet.

>The cert may protect you from MITM in a coffee shop, but it doesn't necessarily help you against state-level actors.

I can use HPKP to pin the cert I get from Lets Encrypt; a cert issued for my domain some other way won’t be trusted due to the hash of its public key being different from the one I pinned.

From https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...:

The Public Key Pinning Extension for HTML5 (HPKP) is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates.

HPKP makes administration more complicated but if your threat model includes state-level actors, it prevents them from getting a CA to issue a valid certificate for your domain.

Certificate Authority Authorization (CAA) has been mandatory for CAs since September 2017; it uses DNS to specify which CAs are allowed to issue certificates for your domain: https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c....

It's worth noting that Chrome has plans to deprecate header-based pins in a few months and static pins (the ones baked into binaries) at some point after their Certificate Transparency policy covers all non-expired certificates. That'll make Firefox the only mainstream browser with HPKP support. (Mozilla hasn't announced their intentions so far.)

Reply on news.ycombinator.com