TLS/SSL Revocation
Revocation is a particularly important notion in a public key architecture. In computer security, any expert must assume that a system can be compromised and countermeasures must therefore exist to try to contain the risk. In some cases, plan B can also be a vector of attack, which makes risk management relatively nightmarish.
Assuming that a private key of a certificate has been compromised (accidentally shared, stolen, hacked, control of DNS servers) and that it is essential for the owner to be able to act in order to limit the attack.
Revocation informs users (of TLS/SSL in our case) that a certificate has been compromised and thus rejects it if necessary.
There are several methods that I will describe here, such as CRL, OCSP and OCSP Stapling.
From a user’s point of view, if they want to revoke their certificate, they will usually access a web interface to perform the operation or use the ACME protocol. In this case of hacking, it is to be hoped that the hacker has not hijacked the famous Web interface (2FA is useful) and that another account has been associated in order to operate ACME from an uncompromised device.
RFC 8555 describes the ACME protocol for simplified and unified revocation processing. Some CAs like Letsencrypt use it massively when others like DigiCert use it only partially (no revocation support).
I write about OCSP’s security in an article dedicated to trust on the internet.
Certificat Revocation List
CRLs are lists of certificates that have been revoked by their owner. As a certificate owner, you can ask the authority (CA) to revoke your certificate by publishing its fingerprint in a list (the CRL).
Subsequently, the client computer will try to store the CRL files as up-to-date as possible so that shortly after the SSL handshake it can check whether the certificate is still valid or has been revoked.
Typically DigiCert’s CRLs is around 1 MB which is perfectly supportable by a large part of the current equipment. Unfortunately the technical preference has not been given to CRLs (mainly for storage reasons).
The CRL is certainly the simplest but not necessarily the most reliable way to manage a revocation concept.
OCSP
OCSP is a protocol originally described by RFC 2560 (1999) and made obsolete by RFC 6960 (2013) that allows a client to check the status of a received certificate by sending a request to the authority (also called VA for Validation Authority) that will indicate whether a revocation message has been issued against a certificate. OCSP allows the revocation task to be centralized within a PKI. In order to validate a certificate, the client only has to communicate with one entity: the OCSP responder.
Unfortunately for the end user, when he contacts an OCSP responder to perform this verification he leaves a ton of informations that can be used by the responder, 5 of which are the most important.
The IP address: The responder knows where the request comes from (Country/Proximate GPS location)
The User Agent : The responder knows from which type of agent the request has been sent (User-Agent) and can help to dissociate equipment.
Time: When the request was issued
Frequency: Despite the timeout, OCSP queries will be more frequent if you use a particular site.
The website concerned : Indirectly gives the address of the website
OCSP responders know who connects where and how to aggregate that data. It is interesting to see that even if Letsencrypt clearly says it does not sell this data, it conceives to be able to receive them and especially to aggregate them as explained here https://letsencrypt.org/fr/privacy/.
We may also compute, retain and publish aggregate information from server logs
OCSP is currently a particularly functional means of tracking. In any case, if I need the truth, I would buy this aggregated data for my own information, especially in the case of letsencrypt which is the “disruptive” actor of TLS/SSL which has introduced free basic certificates. So everyone who uses this service becomes a product, but that doesn’t mean it’s better elsewhere.
The traditional OCSP is a particularly vicious tracking tool because at (almost) every new SSL connection the computer will request OCSP responder and know using its fingerprint if the site’s certificate is good, leaving informations while requesting… This behavior is also similar to Apple’s, which, to protect people, sends the fingerprints of the software executed (with the same traces) to the OCSP responder, which will then know which software is running. This is for the sole purpose of protecting us from malware (sic). We underestimate the level of requests sent to OCSP responders.
An improvement exists (OCSP Stapling) that prevents a user from systematically contacting the CA. Unfortunately this improvement is rarely deployed because it is not only the customer who decides, the webmaster must also perform a technical action to activate the Stapling. Sometimes even if Stapling is activated, the traditional version will still be used by the client.
It is important to note that OCSP Stapling works for some email servers but is still limited to Web and Mail protocol. OCSP Stapling only works in connected mode.
We all know that traditional OCSP will disappear but that the road is long because despite everything, many do not agree (yet) to make this protocol obsolete.
Finally it is important to know that OCSP is not a marketing tool and is also useful in the surveillance of certificates issued by CAs. And in an organization as heterogeneous as CAs, it is useful to know that authorities don’t (over) do anything. That’s what made Symantec lose its CA right.
OCSP Stapling
The OCSP Stapling described by RFC 6961 (2013) is therefore the successor to the traditional OCSP and operates fundamentally differently than its predecessor. Firstly because it is no longer the client but the server that will contact the OCSP responder (VA) and this one will sign the response by adding certain information and in particular the timestamp (time marker). Subsequently, the server will staple the signed VA response when it sends its certificate to the client. The client will not need to send a request to an OCSP responder. Unfortunately the stapling can only work in connected mode (client <> server).
The client no longer needs to contact the OCSP responder and will simply perform a verification of the signature and timestamp issued by the server. This in this case is more than enough to prove that the certificate is not revoked.
Finally, OCSP Stapling seems to be a good enough solution to protect privacy. Yes, but only in the case where a client talks to the server (and therefore connects).
If we go back to the example of Apple which will check objects (applications in this case) on the client machine. Here, the client does not issue a secure connection with a service but will consult Apple’s OCSP to check the status of the object. In this case, OCSP Stapling cannot be used because there is no server and therefore nothing to staple.
More generally, OCSP Stapling can only be used in a TLS/SSL connection framework and not for objects. Similarly, it remains important to be able to manually check a certificate either by an answering machine or by the CRL.