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 session.
Vendor Response: Microsoft was notified via [EMAIL PROTECTED] 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 behavior. 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
