Rich Megginson wrote: > Nelson B. Bolyard wrote: >> One more thing: http upgrade is EVIL. :-/ > > Why? And does that apply to LDAP upgrade as well? Because the > recommended way to use TLS with LDAP is to use the startTLS extended > operation on the unsecure port to upgrade the connection to TLS.
Two issues: 1. RFC 2817 defines two forms of upgrade, optional and mandatory. The "optional" form never encrypts the request, only the response. So, if the request contains sensitive info, it's been sent in the clear. RFC 2817 provides no guidance (that I saw) as to when an http client should use one or the other. Further, as Julien as made clear, RFC 2817 provides no means by which a URL can tell the browser that "for this URL, you MUST do a mandatory upgrade, and if that fails, you must STOP and not continue without ecnryption." So, RFC 2817 is useful only in applications that KNOW that they MUST upgrade or die. I submit that these are special purpose applications, not general purpose browsers. Some might say that RFC 2817 is also useful for "opportunistic encryption" but I consider that to be useless and a waste of time and CPU cycles. If my application (e.g. online banking) needs protection then it NEEDS protection. An encryption-based protection scheme that provides encryption or not, out of the control of the client, and out of control of the writer of web pages that have the URL/links in them, is a scheme that the user cannot RELY upon to protect him. Ergo, the user should only use it for data that he really doesn't care if it is encrypted or not. Then one asks, why waste precious shared resources (server CPU cycles) on such trivial stuff? 2. "mandatory" http upgrade and startTLS both seem to have similar properties WRT MITM vulnerability. An MITM need only intervene in a few initial messages - to prevent the server from learning that the client wishes to upgrade/startTLS, and to prevent the client from learning that the server is capable of ugprade/startTLS - to defeat it. Again, if an application, such as an ldaps client or an IMAPS client has been configured to upgrade/startTLS or die, and NEVER fall back to unencrypted communications, then the worst an MITM can do is a DOS attack. And of course we know that no crypto protocol can prevent a DOS attack. So, I see no problem with startTLS in applications like LDAP clients and IMAP clients, which are likely to be (able to be) configured to require that the upgrade/start succeed, or else stop. But for general purpose browsers, clearly one would not want to mandate successful upgrade on every http link, and no other means is defined to tell the browser "this is a URL on which successful upgrade is mandatory". 3. A certain popular web server product has the property that the http and https parts of it share a common doc root. By default, if you merely turn on https support on one of their servers, your pages get served equally well with http or https, with or without SSL. Admins of those servers FREQUENTLY forget to take the extra actions to ensure that part of their doc root is accessible ONLY via https. A certain popular browser didn't warn about transitions from https to http. The web page authors tested only with that browser, and no never noticed that some of their links effectively disabled SSL, and after navigating one of those links, the browser would not then return to https. So the web site's web pages got sloppy, and unwittingly included http links in pages that should bear only https links. The web page authors never detected their error because their non-mozilla browsers never alerted them to it. Their users would start out with an https link, and begin to navigate the (bank) web site, and then after navigating it for a while, the user would discover to his horror that somehow his browser had silently stopped using SSL to talk to this server, and his last N pages from that server have had no protection. One of the most common questions we used to get from web site authors who used that particular brand of server was: "why do our users who navigate our web site with Netscape/mozilla browsers get warnings about leaving encrypted pages while navigating, but users of other browsers do not?" Some of them got pretty irate about these warnings, denying that they had done anything to disable encryption in their web sites. I would explain to those authors that in fact they WERE effectively disabling encryption for their users by going to http links to their pages. I pointed out that mozilla was protecting its users, and the other browser was not protecting its users. In every case, I got a thankful reply from a red-faced web site developer who appreciated being informed that his pages actually were disabling user security. (Search google groups for many occurrences of such interfaces between [EMAIL PROTECTED] and others.) Now, I submit that http upgrade will only make that old problem worse by orders of magnitude. Web site authors will no longer be able to tell, *by inspection of their web pages* whether their links are going to preserve cryptographic security for their users, or not. 'Nuff said? </dead horse :-> -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
