2 ms·
> This is built into browsers? Yup, unfortunately, browsers often have to do revocation (and SCT) checks because traditional servers like Apache and nginx don'
by mholt 9y ago
> This is built into browsers?
Yup, unfortunately, browsers often have to do revocation (and SCT) checks because traditional servers like Apache and nginx don't staple OCSP responses by default (and even if they are configured to do so, the implementations in these servers are not robust against outages).
Firefox checks OCSP for DV certs, but that will be disabled in a near-future release.
- wbl 9y agoEven better: OCSP failures cannot result in failing closed because of middleboxen. So all this traffic wasn't needed anyway.
- tialaramex 9y agoYour reference to SCT here seems weird. [Anybody following at home: SCTs are signed timestamps proving a particular Certificate Transparency log server logged this certificate's details at a moment in time. These log servers are public proof of what certificates should exist. The cryptography behind the log servers makes it impossible for them to lie about what they know beyond a certain horizon, policy today sets that horizon at 24 hours] Today the only thing any browser (Chrome) does with SCT by default is to verify whether valid (properly signed) SCTs are provided for certain certificates. This doesn't result in any additional connections, although if OCSP is needed already the SCTs might optionally be included with OCSP. Eventually browsers will be able to automatically report information to detect any discrepancies (e.g. where a log is telling different things to different people), but today that's something which exists only in prototype, not as a default feature in production web browsers ordinary people use every day.