3 ms·
The problem is that revocation essentially doesn't work. What other browsers do is this: * Connect to OCSP server * If connection fails certificate is consid
by hannob 11y ago
The problem is that revocation essentially doesn't work.
What other browsers do is this:
* Connect to OCSP server
* If connection fails certificate is considered valid
At some point the Chrome devs decided that instead of having a stupid, insecure revocation check that does nothing if an attacker knows how stupid and insecure it is they could also disable it.
This could be fixed with OCSP Stapling and Muststaple, but it's still a long way till this will reasonably work.
- patcheudor 11y agoI raised the OCSP validation issue with the Chromium team in the past: https://code.google.com/p/chromium/issues/detail?id=439851 https://code.google.com/p/chromium/issues/detail?id=439851 While I understand their position, I don't entirely agree with it for one simple reason. I'm not convinced someone will always be on a compromised network. From my own experience, the most likely network man in the middle scenarios occur while traveling like when connecting to an airport or hotel network. Many bad guys know how to evil-twin WiFi and implement transparent TLS proxies. With this in mind, if a user visits a site frequently and that site revokes their cert, there's a good chance the user will not be on an evil network when the OCSP check is made. Therefore, if Chrome cached the responses and permanently revoked the certs the risk to the user does in fact decrease. As stated in my report, Heartbleed really did make the choice to ignore OCSP a bit more risky because private key material really was stolen from a number of companies.