SSL & Browser behaviour/policies
Ian Grigg
(RFCs 2817, 2818 cover HTTP/TLS and upgrading
from clear to SSL only, not HTTP/SSL. Eric
Rescorla's book is .. close, but as it's
fairly new, what was used beforehand?)
iang
-------- Original Message --------
Subject: SSL & Browser behaviour/policies
Date: Sun, 19 Sep 2004 15:27:51 +0200
Hi Ian,
I'm looking for the RFC or other "de facto" standard describing the
behaviour of a browser when engaging an HTTP session over SSL.
E.g. I understand that the "Common Name" (CN) should hold the FQDN or
hostname, but I would like to understand if there is more to it. Like what
happens in case the client has a certificate as well and the server requires
the client to engage in a two sided authentication.
Any idea?
thanks
xxxx
Nelson Bolyard
> Someone sent me this question - any ideas?
>
> (RFCs 2817, 2818 cover HTTP/TLS and upgrading
> from clear to SSL only, not HTTP/SSL. Eric
> Rescorla's book is .. close, but as it's
> fairly new, what was used beforehand?)
>
> iang
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.
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.
/Nelson
Ian Grigg
> 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
Julien Pierre
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.