Recent problems with revoking SSL certificates have renewed discussion on whether the certificate system is still sufficient to protect users on the Internet.
Some Web browsers handle the revocation process “carelessly,” resulting in users and administrators using SSL certificates even after it is no longer valid, Robert Duncan, Internet Services Manager at Netcraft, wrote on the company blog. Using a revoked certificate can expose the user to fraud, eavesdropping, and theft. The certificate system, as designed, secures the flow of communication between the Web browser and the Web server hosting the site.
The certificate provides a key to encrypt the traffic and also acts as a third-party verification of the site owner’s identity. There are several layers of authentication, ranging from a simple check that the owner legitimately owns the domain name, to performing more extensive identity checks.
Sophisticated malware such as Stuxnet and Duqu are proof that attackers can use compromised keys and certificates to cause significant damage.
If there is a problem with an SSL certificate—because its private key was compromised, the owner of the certificate no longer controls the domain, or it was mistakenly issued—the system handles it by revoking the certificate. There are ways to abuse the system, such as when an attacker performs a man-in-the-middle attack by displaying the incorrect certificate and tricking browsers into connecting to the fraudulent site, as if it was the legitimate one.
“If the certificate, or one of the certificates in the chain, were revoked due to a key compromise and there is an active attacker exploiting the lack of revocation checking in modern browsers, the public could be at risk for an extended period of time,” Duncan wrote.
On April 30, an intermediate certificate issued to Network Associates, which was used to sign multiple SSL certificates belonging to McAfee, was revoked by RSA, Duncan noted. The revocation should have displayed an error message and prevented access to all of the affected McAfee sites as well as the ecommerce site www.mcafeestore.com.
However, the opposite was the case, as “more than a week later nobody had noticed,” Duncan said. (Netcraft waited till the certificate was replaced before posting.)
At issue was the way the certificate was revoked, Duncan said. There are currently two main ways for browsers to check the certificate’s status: Online Certificate Status Protocol (OCSP) or looking up the certificate in the Certificate Revocation List. OCSP provides information from the issuing certificate authority while CRL is a list that browsers have to download to use.
RSA revoked the intermediate certificate by adding it to the CRL. However, it turns out Firefox does not download CRLs for Websites which use the most popular types of SSL certificates, Duncan noted. “Without downloading the CRL, Firefox is happy to carry on as usual; letting people visit the website and transfer sensitive personal information relying on a certificate that is no longer valid,” Duncan wrote.
Google Chrome also by default doesn’t make standard revocation checks, although it does aggregate a limited number of CRLs and distributes the list via its update mechanism. While Google Chrome does offer the option to enable proper revocation checks, it depends on the platform the user is on, Duncan said. Internet Explorer handles the revocation correctly, making it “one of the most secure browsers,” Duncan said.
It appears mobile browsers also do not properly check the certificate’s status. “Neither Google Chrome on Android nor Safari on iOS present a warning to the user even after being reset,” Duncan said. Safari on iOS makes revocation checks for the higher-level Extended Validation certificates and not for any of the lower level ones.
“The state of revocation amongst modern browsers is sufficiently fragmented to ensure that the entire concept of revocation is on shaky ground — without consistent behaviour and timely updates, if or when the certificate is finally blocked it is too late,” Duncan said.
The situation may not be as grim as Duncan paints it. While Netcraft highlights the need for effective encryption controls and certificate revocation, “it’s not the technology that’s to blame,” Jeff Hudson, CEO of Venafi, told SecurityWeek. The problem lies into the fact that these certificates are not managed properly.
Hudson cited recent research by Ponemon Institute which found that 51 percent of organizations did not know how many keys and certificates were deployed within their networks. The same survey estimated that an organization had an average of 17,807 keys and certificates deployed.
Attackers want people to be “totally unaware of the vulnerability,” Hudson said.
Criminals understand this “gaping vulnerability” and the overall reliance on the trust-based system, Hudson said. “Cybercriminals look for the weakest link in security defenses and are quick to identify and adapt in order to maximize the damage on targeted organizations,” he said.
Enterprises, financial institutions and governments need to secure trust by establishing control of their digital certificates and keys to secure their corporate networks, Hudson said.