1. 6

  2. 3

    His binary failure in the UI is increasingly annoying. The risk of an expired cert (particularly one thanks cached by the browser and is the same one as the last visit) is much lower than a completely new cert. Yesterday I learned that Safari reports an insecure connection warning with the cryptic message that the certificate is not standards compliant if the CA does not report the cert in the correct way in CT logs. The certificate is valid, is in date, has a working revocation list URL, and is signed by a trusted CA root cert, but is apparently (from the UI) just as dangerous as an unsigned cert from a trivial MITM attack.

    1. 1

      But even if it is cached, revocation checking stops working for expired certs. Just think of Let’s Encrypt: It really mostly works BECAUSE we can assume that an expired cert is not to be trusted regardless of any other parameters.

      1. 1

        It’s definitely not a great idea to trust expired certs, but the threat model is different. If you see an expired cert, the attacker must have compromised the server in some way (at least with an information disclosure that lets them leak the private key). The risk is that you will provide them with the ability to privilege elevate if, for example, they have compromised a proxy server on the front end and you provide credentials that let them access your data on the back end. In contrast, an attacker who presents an unsigned certificate or one with the wrong domain just needs to compromise one hop between you and the server. This could be a public WiFi AP, for example, or someone taking advantage of the latest remotely exploitable vulnerability on ISP-provided consumer APs, and so on. Treating these as equivalent threats is misleading.