RFC: suggestions for SSL security enhancements in Microsoft Internet Explorer

From: dhalterm@csc.com
Date: 04/03/02

Date: Wed, 03 Apr 2002 07:42:58 -0500
From: dhalterm@csc.com
To: vuln-dev@securityfocus.com

Behavior: Microsoft Internet Explorer (tested version 5.0) allows a user
to establish an SSL session when a server presents a public key certificate
that was not issued as an SSL server certificate. Though the browser
issues a warning, the user may override this warning and accept the

Vendor Response: Microsoft was notified via secure@microsoft.com and
responded within one (1) business day. The vendor correctly noted that
this is a known behavior, not necessarily a vulnerability or security bug.
Microsoft requested that the issue be re-submitted via its product feedback
mechanism. The submitting author notes that the SSL security model would
be enhanced if Internet Explorer explicitly rejected attempts to establish
SSL server connections when a certificate is not configured as an SSL
server certificate.

Objective: The authors request comments from security professionals
regarding the desirability of changing this behavior in Internet Explorer.
Motivated individuals are encouraged to test this behavior on their own
systems in order to verify and validate the authors' findings.
Consolidated responses will be forwarded to Microsoft, with suggestions, as
explained in the "Vendor Response" section above. The submitting author is
especially interested in considered opinions regarding whether the user
should be given the option to accept an SSL session when the presented
certificate was not issued as an SSL server certificate. Since the
implementation of PKI is expanding, and both simple and
mutually-authenticated SSL connections may become prevalent in the Internet
realm, the submitting author believes that a prominent browser such as
Internet Explorer should offer a more definite assertion of an SSL
connection's validity. Thoughtful debate on this concept is solicited.

Risk: The general risk appears negligible. Though it is not possible to
predict every potential attack vector, the submitting author surmises that
an individual with dubious motives could find other, better ways to spoof
users into making an SSL connection with a server and then reveal sensitive
information. That being said, a major factor of the public key model is
trust. Since the mere possesion of a public key certificate--or even a
public/private key pair--does not imply a finite state model, both
programmers and users must rely on established trust to decide whether a
certificate is valid and acceptable. Most users do not understand the
implications of overriding a security warning. The submitting author
contends that the security model maintained by Internet Explorer would be
more robust if its behavior followed the state-machine concept, in which
the establishment of an SSL session were considered an invariant property.
While the submitting author makes no claims to authoritative knowledge, it
would appear that allowing a user to override a warning would leave the
authenticity of the SSL connection in an uncertain state. Refer to page
three (3) of the following document:
http://www.radium.ncsc.mil/tpep/library/ramp-modules/mod_05.pdf . See the
"Background" section below for detailed information on the undesirable

Background: While working on a development project that utilizes basic SSL
connections, we found ourselves on an isolated network and in need of an
SSL server certificate. Having none handy but wanting to continue, we used
a personal end-entity certificate we happened to have on disk, which had
been issued by the DoD PKI test lab. This was loaded into Microsoft IIS as
its SSL server certificate. Since the DoD community uses both Netscape and
Internet Explorer (IE), we needed to test both browsers. We tried Netscape
4.7x with PSM first, and it rejected the certificate as not being of the
correct type for the requested connection. When tested with IE 5.0, the
browser issued a warning about the certificate, but the user was allowed to
override the warning, accept the SSL session, and continue. These
behavioral differences were puzzling. Upon investigation, the authors
concluded that what defines an SSL server certificate is the inclusion of
the server's fully qualified hostname in the Common Name field of the
X.509v3 certificate. For example, a web server named
"base.group.service.mil" would need to have the matching
"base.group.service.mil" in its cn field. In this particular incident, the
personal end-entity test certificate obviously contained the common name of
the person to whom it was issued. Later, we obtained a certificate with
the proper credentials, imported the trust chain, and both Netscape and IE
accepted the properly configured SSL certificate without comment.

Afterword: Upon correcting the immediate problem, the authors were
obligated to move on and continue developing their primary project. Time
does not allow us further detailed investigation of the SSL server
certificate mechanism. However, the differences in behavior between the
two major browsers, IE and Netscape, continue to cause additional labor
since their variant responses must be documented in our environment. This
is not a diatribe on the desirability of IE vs. Netscape. Rather, it is a
call for consistency and standardization in the way browsers accept,
import, export, validate, select, and protect internal or external
certificates. It is technically feasible at this moment to widely enable
not only simple SSL tunneling but mutually authenticated (or client-side)
SSL in the Internet environment. This will lead the way for more popular
acceptance of sensitive transactions conducted on the Internet. However,
the submitting author contends that if a browser allows a user to accept an
SSL connection with an entity that presents a public key certificate not
its own, that is a breakdown of the trust model and makes it impossible to
guarantee party identification, transaction integrity, and non-repudiation.

Authors: William Annocki & Don J. Halterman, Jr.

Don J. Halterman, Jr.
CSC JCALS Systems Engineering
856-983-4400 x4530