Warning: Illegal string offset 'thumbnail_type' in /home/cyberdefensemag/public_html/wp-content/themes/Magazon/st-framework/templates/single.php on line 46
Security researcher Adam Langley of Google explained the real efficiency of revocation checking in response to OpenSSL heartbeat bug.
The Heartbleed bug is a source of great concern for IT industry, every day we discover that the flaw in the OpenSSL library has had a significant impact on Servers, on the mobile industry and on the anonymity of Tor users.
Last debate is related to PKI infrastructures, in particular under revision the process of certificate revocation, a crucial activity to limit the validity of a given certificate for security reason.
The Heartbleed attack can allow an attacker to compromise a vulnerable server to steal the secret key associated with the certificate generated for server authentication. Once stolen the key a bad actor could easily impersonate the compromised site.
After the disclosure of OpenSSL flaw, administrators of vulnerable servers have updated the OpenSSL library and generated a new certificate for their infrastructure (so a new public key), but as noted by the security researcher Adam Langley of Google, the old certificates still work allowing an attacker with the old private key to still impersonate the website.
The online certificate status protocol (OCSP) is the Internet protocol used for managing the revocation status of an X.509 digital certificate, it is an alternative to certificate revocation lists (CRL). The messages communicated via OCSP are usually communicated over HTTP, OCSP manages less information respect a typical CRL and this allow an optimized use of networks and client resources. Practically the OCSP protocol requires the client to contact a third party to confirm certificate validity.
Common browsers submit a request to the OCSP server to check the certificate status, they receive a signed assertion that tells them whether the certificate is still valid. In the case the browser for some reason doesn’t get a response from the OCSP server, it has to decide whether to accept the certificate.
Langley has written a specific post titled “No, don’t enable revocation checking” to analyze the large number of revocations resulting from precautionary rotations for servers affected by the heartbeat flaw.
“If you’re worried about an attacker using a revoked certificate then the attacker first must be able to intercept your traffic to the site in question. (If they can’t even intercept the traffic then you didn’t need any authentication to protect it from them in the first place.) Most of the time, such an attacker is near you. For example, they might be running a fake WiFi access point, or maybe they’re at an ISP. In these cases the important fact is that the attacker can intercept all your traffic, including OCSP traffic. Thus they can block OCSP lookups and soft-fail behaviour means that a revoked certificate will be accepted,” Langley wrote.
In the post Langley proposed different scenarios in which revocations are useless and cannot prevent attacks, for example for offensives related to a nation-state attacker who is able to intercept the entire victim’s traffic.
“Firstly, the attacker can use OCSP stapling to include the OCSP response with the revoked certificate. Because OCSP responses are generally valid for some number of days, they can store one from before the certificate was revoked and use it for as long as it’s valid for. DNS hijackings are generally noticed and corrected faster than the OCSP response will expire.”
Langley explained the checking method implemented by Google Chrome that daily monitors the status of certificates for high-value sites and pushes the information to Chrome users, in this way a revocation is propagated within a day or so.
“It’s called the CRLSet and it’s not complete, nor big enough to cope with large numbers of revocations, but it allows us to react quickly to situations like Diginotar and ANSSI. It’s certainly not perfect, but it’s more than many other browsers do,” Langley wrote.
“A powerful attacker may be able to block a user from receiving CRLSet updates if they can intercept all of that user’s traffic for long periods of time. But that’s a pretty fundamental limit; we can only respond to any Chrome issue, including security bugs, by pushing updates.”
Langley is suggesting a scalable solution to the revocation problem in the form of short-lived certificates or something like OCSP Must Staple, limiting the validity of OCSP response in a few days.