Re: Multiple domains on https (apache)
From: Aleksandar Milivojevic (amilivojevic_at_pbl.ca)
Date: 02/24/05
- Previous message: Bill Rugolsky Jr.: "Re: Distributed file system"
- In reply to: Deron Meranda: "Re: Multiple domains on https (apache)"
- Next in thread: Joe Orton: "Re: Multiple domains on https (apache)"
- Reply: Joe Orton: "Re: Multiple domains on https (apache)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 24 Feb 2005 09:59:03 -0600 To: For users of Fedora Core releases <fedora-list@redhat.com>
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@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
- Previous message: Bill Rugolsky Jr.: "Re: Distributed file system"
- In reply to: Deron Meranda: "Re: Multiple domains on https (apache)"
- Next in thread: Joe Orton: "Re: Multiple domains on https (apache)"
- Reply: Joe Orton: "Re: Multiple domains on https (apache)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
