Incidentally, SSL (or TLS) can be used to secure other protocols besides HTTP, such as SMTP (mail) and so on. Many of those other protocols don't have such limitations, because they allow the application protocol to handshake first without encryption, and then switch over to SSL/TLS on the fly. HTTP was designed before SSL was invented, and because of some of its fundamental design assumptions, could not be easily retrofitted to work that way without completely breaking compatibility.
Actally, all those other protocols were around here decades before SSL was invented. HTTP was one of the first protocols that was SSL-ized. SSL implementations for all other protocols learned from mistakes made with HTTPS, and using implicit SSL tunnel is depricated in them (if allowed at all).
Theoretically, it is perfectly possible to implement HTTP over SSL the way other protocols are now using it. Currently, simplified HTTP conversation on port 80 might look something like:
-> GET / HTTP/1.1 -> Host: www.foobar.com -> More-Headers: blah blah -> <- HTTP/1.0 200 OK <- More-Headers: more blah blah <- <- content of index.html from foobar.com
The second line is important, since it tells the other side the host name we are attempting to connect to (this is what Apache and all other web servers are using for domain-based virtual hosting). If your browser dosn't send host header (very old versions of IE for example), virtual sites based on domain names are not going to work at all.
For HTTPS, that uses implicit SSL tunnel on port 443, simplified conversation looks like this. "->", "<-", and "<->" indicate direction of traffic, it is not part of actual data exchange.
<-> SSL handshake -> GET / HTTP/1.0 -> Host: www.foobar.com -> More-Headers: blah blah -> <- HTTP/1.0 200 OK <- More-Headers: more blah blah <- <- content of index.html from foobar.com
Obviously, data needed for server to send correct certificate was sent after SSL handshake. Too late.
The problem could be corrected if anybody was kind enough to extend HTTPS to allow for explicit requests for SSL on standard port 80 (this is preferred way of doing things in all other protocols, as I said, lesson learned from HTTPS). SSL channel is brought at explicit client request for it. No need for special port (such as 443) either. Simply use standard port 80. That way, client can pass data needed to choose correct certificate.
-> AUTH TLS -> Host: www.foobar.com -> <- HTTP/1.0 200 OK <- Some-headers: completely optional, we probably don't want <- to blah blah too much in cleartext <- <-> SSL handshake -> GET / HTTP/1.0 -> Host: www.foobar.com -> More-Headers: blah blah -> <- HTTP/1.0 200 OK <- More-Headers: more blah blah <- <- content of index.html from foobar.com
However, HTTPS does not provide for this option. There is no standard describing anything like this for HTTP protocol. And it is not likely that there will be one in foreseable future. If there was, server would be able to choose correct certificate before SSL handshake was to occur based on data passed from the client (the host header).
Interestingly enough, if you use proxy, something similar is implemented. When using proxy, client sends "CONNECT" command to the proxy, followed by headers (which usually include host header) before SSL tunnel is established (basically, explicitly requesting SSL tunnel). Proxy than makes connection to the server using implicit SSL tunnel. Again, if we had "AUTH TLS", this "CONNECT" command and special handling of proxies (when SSL is used) in browsers would not be needed.
So, it is not that it isn't technically possible. It is simple thing that HTTPS was one of the first protocols to deploy SSL, and nobody thought about the problem (or cared enough about it) until it was too late. Other protocols (that were SSL-ize after HTTP) learned from this mistake.
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
