Multiple domains on https (apache)

[Aleksandar Milivojevic]

Deron Meranda wrote:
> 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 at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7