Nelson Bolyard wrote:
Ian, the questions being asked here are vare vague and open. Please encourage your correspondent to ask his questions here in this newsgroup, and to be specific about what is wanted.
OK, I sent on the reply, thanks.
BTW, HTTP "upgrading" (running SSL/TLS on port 80) has been rather roundly rejected, IMO, for a number of good reasons. If you care, perhaps you can ask Julien to say more about this.
Oh, ok! Julien? The topic comes up everytime someone starts talking about increasing utilisation of SSL/TLS. Perhaps you could point me at any doco that explains why?
iang
There were a number of issues with TLS upgrade that I objected to during its design phase, which never got addressed. Googling for my name in conjunction with TLS upgrade will find most of the discussions, around year 2000, back when I was working on an HTTP server (iPlanet web server), rather than on the NSS libraries.
The #1 issue that caused me not to implement TLS upgrade in my HTTP server is that there is no new URL scheme specified to tell the browser to connect with HTTP and then do a TLS upgrade. The existing http:// scheme is inadequate for general web use in secure applications, as it will result in no security when used with old clients (which don't support TLS upgrade with http://), at best, and compromise of data with many web applications that use confidential data within URL fields.
The URL scheme may seem like a small thing, but given that TLS upgrade needs to be implemented on both the server and client side, I felt it was very important to get the design right, and so opted not to implement the TLS upgrade draft in iPlanet web server.
Note that TLS upgrade was designed specifically for use with the Internet printing protocol, and not for general HTTP use in browsers, as the authors of the draft themselves admitted.
TLS upgrade indeed had the potential to increase SSL/TLS use for HTTP, and in particular of allowing SSL virtual servers on a single IP/port by way of using the Host header in the plain-text HTTP request before the TLS upgrade.
However, this need is now addressed in the TLS 1.1 extensions draft through the "server name indication" field in client hello. This is a much cleaner and more secure way to accomplish the same goal, as well as one that can work with all protocols and not just HTTP. We haven't had requests to implement this yet, but there are RFEs on NSS. See bugzilla 116168 and 116169 .
The need that TLS upgrade for HTTP filled which the TLS extensions draft doesn't is to get rid of the dual ports 80/443 for HTTP and HTTPS . However, the HTTP and HTTPS servers are already out there on two different ports by the millions, and I believe trying to get rid of one of the two ports given the situation now is bound to fail, not to mention pointless.
IMO, the TLS server name indication extension makes the HTTP TLS upgrade scheme irrelevant, and the later should simply be skipped in web browsers.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
