Experts say browsers fall short on certificate alerts

[William Knowles <wk () C4I ORG>]

http://news.cnet.com/news/0-1005-200-3342605.html?tag=st.ne.1002.tgif.ni

By Paul Festa
Staff Writer, CNET News.com
October 30, 2000, 6:30 p.m. PT

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.

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."


*==============================================================*
"Communications without intelligence is noise;  Intelligence
without communications is irrelevant." Gen Alfred. M. Gray, USMC
================================================================
C4I.org - Computer Security, & Intelligence - http://www.c4i.org
*==============================================================*

ISN is hosted by SecurityFocus.com
---
To unsubscribe email LISTSERV () SecurityFocus com with a message body of
"SIGNOFF ISN".