4 ms·

In order to revoke a certificate, you first must at least suspect it has been compromised. An expiration date can help limit the impact of compromises you don't

In order to revoke a certificate, you first must at least suspect it has been compromised. An expiration date can help limit the impact of compromises you don't suspect.

segfaultbuserr 6y ago
It's also important to see that the SSL/TLS system does not allow you to revoke a certificate with 100% certainty, the revocation mechanism is flawed - it's often practically impossible to reliably revoke a certificate after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability. * CRL is a list of revoked certificates, it must be downloaded and manually applied to all clients, which only occurs once in a while as a new update, and many hate system updates. The huge lists of revoked certificate have size, performance and scalability problems, currently they are considered obsolete and mainly replaced by OCSP. * In OCSP, clients ask a CA's OCSP server to determine the validity of a certificate. It operates out-of-band from the main TLS connection, and networks and CA servers are not reliable, especially in the early days. Timed out OCSP requests were common. If you are a web browser, you don't want a failed OCSP request to block/DoS HTTPS, thus OCSP becomes essentially "optional". Browsers reject bad certificates when the connection goes through, but if it times out, nothing happens. An attacker can simply block the OCSP server to bypass the revocation check. There's also the problem of privacy - you have to send the name of every website you visit to third party servers. * In OCSP Stapling, the webserver acts like a proxy - it hosts a cached copy of the OCSP response for itself (it cannot be forged because it's signed by the CA) and sends it to clients in-band, via normal TLS channel. Because now the client no longer asks CA's OCSP servers for a response, but instead simply asks the webserver itself, it eliminates the problem of third-party OCSP servers, solves the reliability and privacy issues. However, there's nothing to prevent an attacker to run a server with a compromised certificate with OCSP Stapling turned off. * In OCSP Must-Staple, you can get a certificate from a CA that says "you must use OCSP Stapling, otherwise this certificate is null and void." Hence, if a browser sees a certificate with "OCSP Must-Staple" enabled, it must see whether the webserver supports OCSP Stapling, and via OCSP Stapling, the certificate's validity will be determined. If OCSP Stapling is not supported by the webserver, the connection is rejected. Thus, an attacker who uses a compromised certificate has to either disable OCSP Stapling and be rejected, or to enable OCSP Stapling and gets caught. Finally the problem of reliable revocation is solved. But this is an optional feature and is only used by a tiny percentage of sysadmins. Also, it's only supported by webservers and browsers, other TLS-based applications like VPN, FTPS, SMTP, IMAP, XMPP, IRC servers/clients, etc, usually don't support OCSP Stapling at all. Thus, it's often practically impossible to reliably revoke a certificate in SSL/TLS after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability, an unrevokable certificate that expires within 90 days is less dangerous than a zombie certificate that lasts two years.
- spockz 6y ago
  I see a lot of discussion about server certificates. But does there exist ocsp stapling for clients at all?
  - segfaultbuserr 6y ago
    No, I don't think so. According to RFC 6066, Section 8 "Certificate Status Request" (a.k.a OCSP Stapling)... > In order to indicate their desire to receive certificate status information, clients MAY include an extension of type "status_request" in the (extended) client hello. Servers that receive a client hello containing the "status_request" extension MAY return a suitable certificate status response to the client along with their certificate. And in a TLS handshake, the procedure is ClientHello, ServerHello, Server Certificate, CertificateRequest, Client Certificate. But "Certificate Status Request" is only specified in ClientHello, not CertificateRequest, so it's not possible for a server to request OCSP status from the client. Hence, OCSP Stapling strictly a service provided to the clients, not vice versa - unfortunately, reliable revocation of client certificate is a still a problem. But I guess it's much easier to blacklist the offended client certificates on your own server, perhaps still problematic in a big organization, but certainly easier than blacklisting every leaked certificate on the Internet. Disclamer: I don't have any experience on managing systems that use client verification. I did my best to RTMF and fact-check myself, but corrections are welcomed.
    - spockz 6y ago
      This is indeed as far as I got as well. Maybe we can make it if we made an ssl extension ourselves but I’m not versed enough in them. It also would require controlling all ssl libraries in use.

In order to revoke a certificate, you first must at least suspect it has been compromised. An expiration date can help limit the impact of compromises you don't suspect.

segfaultbuserr 6y ago

It's also important to see that the SSL/TLS system does not allow you to revoke a certificate with 100% certainty, the revocation mechanism is flawed - it's often practically impossible to reliably revoke a certificate after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability. * CRL is a list of revoked certificates, it must be downloaded and manually applied to all clients, which only occurs once in a while as a new update, and many hate system updates. The huge lists of revoked certificate have size, performance and scalability problems, currently they are considered obsolete and mainly replaced by OCSP. * In OCSP, clients ask a CA's OCSP server to determine the validity of a certificate. It operates out-of-band from the main TLS connection, and networks and CA servers are not reliable, especially in the early days. Timed out OCSP requests were common. If you are a web browser, you don't want a failed OCSP request to block/DoS HTTPS, thus OCSP becomes essentially "optional". Browsers reject bad certificates when the connection goes through, but if it times out, nothing happens. An attacker can simply block the OCSP server to bypass the revocation check. There's also the problem of privacy - you have to send the name of every website you visit to third party servers. * In OCSP Stapling, the webserver acts like a proxy - it hosts a cached copy of the OCSP response for itself (it cannot be forged because it's signed by the CA) and sends it to clients in-band, via normal TLS channel. Because now the client no longer asks CA's OCSP servers for a response, but instead simply asks the webserver itself, it eliminates the problem of third-party OCSP servers, solves the reliability and privacy issues. However, there's nothing to prevent an attacker to run a server with a compromised certificate with OCSP Stapling turned off. * In OCSP Must-Staple, you can get a certificate from a CA that says "you must use OCSP Stapling, otherwise this certificate is null and void." Hence, if a browser sees a certificate with "OCSP Must-Staple" enabled, it must see whether the webserver supports OCSP Stapling, and via OCSP Stapling, the certificate's validity will be determined. If OCSP Stapling is not supported by the webserver, the connection is rejected. Thus, an attacker who uses a compromised certificate has to either disable OCSP Stapling and be rejected, or to enable OCSP Stapling and gets caught. Finally the problem of reliable revocation is solved. But this is an optional feature and is only used by a tiny percentage of sysadmins. Also, it's only supported by webservers and browsers, other TLS-based applications like VPN, FTPS, SMTP, IMAP, XMPP, IRC servers/clients, etc, usually don't support OCSP Stapling at all. Thus, it's often practically impossible to reliably revoke a certificate in SSL/TLS after someone has compromised your private key. The only feasible workaround is early expiration to reduce the window of vulnerability, an unrevokable certificate that expires within 90 days is less dangerous than a zombie certificate that lasts two years.

spockz 6y ago
I see a lot of discussion about server certificates. But does there exist ocsp stapling for clients at all?
- segfaultbuserr 6y ago
  No, I don't think so. According to RFC 6066, Section 8 "Certificate Status Request" (a.k.a OCSP Stapling)... > In order to indicate their desire to receive certificate status information, clients MAY include an extension of type "status_request" in the (extended) client hello. Servers that receive a client hello containing the "status_request" extension MAY return a suitable certificate status response to the client along with their certificate. And in a TLS handshake, the procedure is ClientHello, ServerHello, Server Certificate, CertificateRequest, Client Certificate. But "Certificate Status Request" is only specified in ClientHello, not CertificateRequest, so it's not possible for a server to request OCSP status from the client. Hence, OCSP Stapling strictly a service provided to the clients, not vice versa - unfortunately, reliable revocation of client certificate is a still a problem. But I guess it's much easier to blacklist the offended client certificates on your own server, perhaps still problematic in a big organization, but certainly easier than blacklisting every leaked certificate on the Internet. Disclamer: I don't have any experience on managing systems that use client verification. I did my best to RTMF and fact-check myself, but corrections are welcomed.
  - spockz 6y ago
    This is indeed as far as I got as well. Maybe we can make it if we made an ssl extension ourselves but I’m not versed enough in them. It also would require controlling all ssl libraries in use.