Hacker News new | past | comments | ask | show | jobs | submit login

I don't think you understand. There is no way to tell your users' browsers to reject the bad cert other than revocation.



yeah I'm not sure why you need to make the BROWSER reject the bad cert, when your server can reject it -- what are you trying to avoid?


Because the BROWSER is what's being attacked in a MiTM. To the server it just looks like a regular client connecting. It never sees the certificate the client saw. There is nothing for the server to reject.


You're trying to avoid Mallory setting up her own evil server with the old cert that she stole via heartbleed and pretending to be you.


The attack being described here goes like this:

1. Attacker steals the private key via heartbleed or other means

2. Attacker sets up their own server using the stolen private key

3. Attacker tricks a user into accessing their server rather than the real server via any of a number of methods, such as a compromised hotspot.

4. User provides their sensitive information to the attacker, thinking they're on the real site.

No server-side action can mitigate the risk of a stolen private key in the above scenario, since the user never communicates with the legitimate server. That said, most browsers ship with certificate revocation lists disabled by default, so revoking the certificate doesn't help nearly as many people as we'd like. But for people who do enable CRLs, they'll see the scary warning rather than their browser trusting the revoked cert.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: