Two weeks ago, I documented an incompatibility between how Microsoft implements digest authentication (RFC 2617, which can be seen at http://kaizi.viagenie.qc.ca/ietf/rfc/rfc2617.txt, a secure log-in standard for Web sites) and how Apache, Mozilla and others implement it. (See “IE, Apache Clash on Web Standard.”)
As part of my March 18 story, I recommended the combination of HTTPS (HTTP transmitted over Secure Sockets Layer) and basic authentication as one workaround to get secure log-in functionality that works with all browsers and Web servers.
Since then, a number of readers wrote to me describing problems they were having using Apache and HTTPS with Internet Explorer clients, so it seems this approach wont work all the time, either.
Tom Anderson, CEO of IT consultancy Order amid Chaos Inc., described how he had found this problem:
“In your article … you suggest that developers fall back on SSL. However, there is a problem with IEs SSL close notify and HTTP keep-alive functionality which currently plagues Web sites across the Web with intermittent cannot find server messages being sent to users with IE. This was a major problem on a site I developed for a client of mine and it was almost impossible to track down. We went up and down the Perl shopping cart code for months looking for a problem. But it only happened sometimes, and sometimes it went for long periods without this problem occurring, so without consistent behavior it was very hard to test it. It only occurred in the shopping cart so thats where we looked, and it wasnt for quite some time that we realized that it only happens on SSL pages (which happen to only be in the shopping cart). Finally, we found some discussion about this problem on the Web after specifically looking for it.
“Turns out it is really a problem in Internet Explorer, but you can work around it by adding the following line to the httpd.conf file, which forces the server to not use HTTP/1.1, keep-alive connection, or send the SSL close notify messages to IE:
“SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
“Clearly, the majority of Web site administrators do not know about this problem as I see it on sites all across the Internet. This is probably because the behavior is so inconsistent that the developers may never have seen it, especially if they generally test in another browser and just check IE compatibility sporadically. However, it can be a major problem as most customers will be lost forever if they get to check-out and the server spits out an error message.”
Tom also pointed me to a more detailed description of various Internet Explorer problems with Apaches SSL implementation, at www.modssl.org/docs/2.8/ssl_faq.html#ToC49. If you are using Apache with SSL and with Internet Explorer clients, you should check out this link to see if these issues might be the source of mysterious site problems.
Another reader, Mark Overton, Director, Knowledge Pathways Development, at IT training firm Global Knowledge Network Inc., pointed out a limitation Microsofts Internet Information Services Web server has with digest authentication: the Web server must be run on the same machine that is the domain controller for digest authentication to work (see http://msdn.microsoft.com/library/ default.asp?url=/library/en-us/dnmag00/html/websecure2.asp).
This is a major security risk, especially since digest authentication also requires passwords to be stored using reversible encryption. When I did my testing for this story, by coincidence, I happened to test IIS this way, and so didnt run into this limitation. However, I wouldnt deploy this configuration in a production environment.
In contrast, iPlanet E-Commerce Solutionss iPlanet Web servers definitely do not have this limitation—they use the LDAP-based iPlanet Directory Server to do authentication, and the LDAP server can be located anywhere on the network.
Based on my reading of the Apache documentation, Im also fairly sure that Apache allows digest authentication to be used with remote user directories (one such example Id find attractive is IBMs LDAP-enabled version of Apache, which is free and available at www-3.ibm.com/software/webservers/httpservers). I havent tried this myself, though—if you are using Apache and a non-local directory system, Id be interested in hearing how you did it.
Back on the digest authentication front, I also heard from a Netscape engineer working on Mozilla who wanted to run my test cases against the latest builds of Mozilla (I sent them) and the working group that manages RFC 2617 issues is also aware of the problem, so Im hopeful that the digest authentication interoperability issues will be addressed in the near future.
As for these other issues, well work on them one at a time.
West Coast Technical Director Timothy Dyck can be reached at timothy_dyck@ziffdavis.com.