III. Solution
Check Certificates
The CERT/CC recommends that prior to providing any sensitive
information over SSL, you check the name recorded in the
certificate to be sure that it matches the name of the site to which
you think you are connecting. For example, in Netscape, click on the
"padlock" icon to engage the "Security Info" dialog box. Then click on
the "View Certificate" button. A dialog box will appear, listing the
certificate authority that signed the certificate and the server for which it
was issued. If you do not trust the certificate authority or if the name of
the server does not match the site to which you think you're connecting, be
suspicious.
Validate Certificates Independently
Web browsers come configured to trust a variety of certificate
authorities. If you delete the certificates of all the certificate
authorities in your browser, then whenever you encounter a new SSL
certificate, you will be prompted to validate the certificate
yourself. You can do this by validating the fingerprint on the
certificate through an alternate means, such as the telephone. That
is, the same dialog box mentioned above also lists a fingerprint for
the certificate. If you wish to validate the certificate yourself,
call the organization for which the certificate was issued and ask
them to confirm the fingerprint on the certificate.
Deleting the certificates of the certificate authorities in your
browser will cause the browser to prompt you for validation whenever
you encounter a new site certificate. This may be inconvenient and
cumbersome, but it provides you with greater control over which certificates
you accept.
It is also important to note that this sort of verification is only
effective if you have an independent means through which to validate
the certificate. This sort of validation is called out-of-band
validation. For example, calling a phone number provided on the
same web page as the certificate does not provide any
additional security.
The CERT/CC encourages all organizations engaging in electronic
commerce to train help desk or customer support personnel to answer
questions about certificate fingerprints.
Reject certificates that don't match the host name
As a specific defense against this vulnerability, we recommend not
accepting certificates that don't match the host name. The most likely
cause of a non-matching certificate is a configuration error on the
part of the web server administrator. However, a user is unable to
distinguish between a benign misconfiguration and a malicious
attack. Even if the user does not intend to provide any sensitive
information to a site with a non-matching certificate, answering "OK"
to this dialog may permit an attacker to successfully carry out the
exploit.
Stay up-to-date with patches, workarounds, and certificate
management products
Apply a patch from your vendor. Appendix A contains
vendor information.
Appendix A Vendor Information
iPlanet
[...] the potential exploit in question can be completely prevented
if the user does not click "continue" as stated above. Because of this
safety measure, we do not feel an emergency release is
necessary. However, we are planning on addressing this in a future
release of Communicator, scheduled for release later this year.
Additionally, this flaw was fixed in PSM
approximately 6 months
before [the initial report of the vulnerability].
The CERT Coordination Center thanks Kevin Fu of MIT and Jon Guyer
for initially discovering and reporting this vulnerability, and their
help in constructing this advisory.
Shawn Hernan was the primary author of this document.
This document is available from:
