Hacker News Reader

Comment by xahrepap | Hacker News Reader

The problem is you can't trust what you're reading to be from the source. Maybe the site doesn't take credit cards. But after a MITM it might suddenly start taking credit cards. And other things. Whatever the attacker wants! All in the seeming name of the origin.

View on HN

MITM like that still works for most https websites because of the automatic domain validation by ACME-based certificate authorities. The only caveat is that now an attacker has to get a valid certificate, so first he has to do MITM on the route from the datacenters where CAs run validators to the datacenter where the website is hosted, which for most websites today is likely a long route crossing many countries, after that an attacker gets the exact capabilities as with MITMing http.

Feb 19, 2020: Multi-Perspective Validation Improves Domain Validation Security (https://letsencrypt.org/2020/02/19/multi-perspective-validat...)

That's the thing, they don't seem to bother actually addressing the problem and assume no other interception capability than hacking BGP. But we are talking here about exactly that, i.e. if you can intercept traffic in any other way somewhere close to a website or its nameservers - you can get a valid certificate and use it to MITM its visitors anywhere in the world where you can intercept traffic too. And in case of using big cloud providers for validation to "improve" security, this still likely pushes traffic from all of them through some big IX before reaching a datacenter with a website and at worst only adds a couple more points an attacker has to intercept traffic at to get the certificate.

This is where all that centralization is really bad for security. It basically makes https a protection only against low effort MITM of last mile ISPs.

No, you're forgetting about Certificate Transparency, which protects against this attack.

It doesn't. Pretty much no one monitors CT logs and for those who do there is no way to prove misissuance of domain-validated certificate and revoke it, they don't have private keys.

If you believe you have been successfully attacked this way you should report it, the logs would be part of your evidence. I spent some time looking for this sort of thing, and it does look like it happens sometimes, mostly to military or political targets, but it's rare. That work is owned by a previous employer, but let's say dozens of times across several years.

You are entitled to revocation of any unexpired certificates for names over which you can demonstrate control. For Let's Encrypt for example you can automate this, simply make the API calls to demonstrate control (as you would for issuance) and then present the certificate that is to be revoked (it's in the logs) and ask their API to revoke it.

But if an attacker can intercept domain validation to issue a certificate, there is little reason not to protect his own certificate from revocation by preventing subsequent validations until it is used on a target, if he can't hide this fact in some way of course. A report of that will look like someone is trying to revoke a certificate for a domain they don't control and won't actually solve the problem even if a human can be convinced by other method that you do control the domain.

Maybe DNSSEC could be used here to help if ACME added a way to force DNSSEC-only domain validation.

Reply on news.ycombinator.com