Experts say browsers fall short on certificate alerts

A mishap that compromised the integrity of two security keys used by Sun Microsystems is fueling criticism of current methods for scrambling sensitive data and verifying identities on the Web.

Sun last week issued a warning that two of its applications' "certificates" had been compromised after the company inadvertently included certificate numbers in early-stage, or "alpha," code it sent to partners. A certificate verifies the identity of an application's source, in this case Sun.

Gartner analysts John Pescatore and Victor Wheatman say Sun Microsystems' warning that several of its public key certificates have been compromised points to a serious problem with this widely used security technology. see commentary

The alert, posted on Sun's Web site and distributed through security groups, has precipitated criticism from Internet security analysts who say the system for getting the word out about compromised certificates is inadequate.

"The worst fear of a participant in a public key system is that the private key be exposed," wrote SecurityFocus.com analyst Elias Levy in an alert to members of the press. "If that were to happen it means that the person that obtained a copy of the private key could impersonate the owner of the key."

Levy argued that key owners should be able to count on a better mechanism for informing people on the Web that compromised keys are no longer valid. Without that knowledge, people could be duped by those who have gained access to the key.

"Companies such as Sun are left trying to inform the world that some certificate should be retired by means that are not likely to be very effective," Levy wrote. "It's unlikely the majority of users that have this certificate installed in their system will hear about the advisory or care enough to remove the certificate."

The way the public key infrastructure works now, keys that are old or compromised are added to Certificate Revocation Lists (CRLs) maintained by certificate authorities (CAs), which issue certificates. Both Microsoft and Netscape said their browsers have supported checking of CRLs for years.

But others questioned the reliability of current CRL checking.

VeriSign, the leading provider of certificates, agreed that certificate checking practices need improvement and placed the responsibility on browser makers.

"It's important to note that there's a weakness in the way some vendors have chosen to implement the technology," said Bob Pratt, director of product marketing at VeriSign. "We've supported revoking certificates for years, but the problem is, not every application has implemented checking. At the end of the day we can't force every application vendor in the world to implement this."

While Netscape said it has supported checking at least since Communicator 4.5 and Microsoft said Internet Explorer has done so since version 4.0, Levy identified several instances where the browsers failed to detect expired certificates and showed no evidence of communicating with CAs to check revocation lists.

In one of several examples, a Web page with a Java applet signed by International Thomson Publishing offered a certificate that expired nearly two years ago, on Nov. 12, 1998. But neither IE 5.5 nor Netscape 4.7 detected that the certificate was expired.

Levy also monitored the traffic between his computer and the Web servers and found that no messages were exchanged with certificate authorities that maintain the CRLs.

"This by no means proves that these browsers do not support online CRL checking, but it does point in that direction," Levy wrote in an email interview. "More in-depth research is required. But it seems that at least in some instances Web browsers do not contact the certificate authorities to check whether a certificate presented in a signed applet has been revoked or not."

Netscape, a division of America Online, maintained that the browser was performing as expected.

"The applet was signed by a valid certificate and has a valid signature," said a Netscape representative. "The fact that the signing certificate has expired does not invalidate the signature...The signatures are still valid because the signing cert was valid when the messages were signed."

Microsoft representatives were not available to respond to Levy's findings.

VeriSign's Pratt compared CRLs to the old books of stolen credit card numbers that merchants used to consult on fraudulent or expired cards. Another technology, which provides a more immediate method of checking, is the Open Certificate Status Protocol (OCSP), standardized by the Internet Engineering Task Force (IETF) and co-authored by VeriSign.

Netscape said it would support OCSP in Netscape 6, the version of its browser now available in its third trial, or "beta," release and due in its final version by the end of the year.

Sun is still playing catch-up with certificate revocation checking. The company said that while the Java software development kit (JDK) has supported manual checking since JDK 1.2, released in 1998, it has yet to support automatic checking. The next version of Java 2 should include it through the CertPath application programming interface (API).

Levy speculated that only a public key disaster would spur changes in the current system.

"Imagine what would happen if Microsoft's private key for ActiveX controls were stolen," Levy wrote in his press note. "Until such a high-profile private key is stolen and abused it's unlikely we'll see many vendors implement CRLs and online certificate validation."