Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <48D75DF1.8010705@ice-sa.com>
Date: Mon, 22 Sep 2008 10:57:21 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: HTTPS and Virtual Hosts
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi.

I'm not an expert at anything below, that's why I am asking.
I am also not looking for a very precise answer, just a rough summary.

The question :

As I remember from reading about this a while ago, there is/was a 
fundamental incompatibility between the HTTP Virtual Host mechanism, and 
HTTPS/SSL, in the sense that there is some egg-and-chicken problem 
involved, which roughly goes like this :
- the client connects to the host and requests an encrypted connection 
to a certain hostname
- the host and client negociate the encryption (based or not on the name 
of the host)
- on subsequent requests, the client sends the request encrypted, 
including the "Host:" header that (acording to the HTTP protocol) should 
indicate the name of the Virtual Host it wants to talk to
- the server should decode the request (including this "Host:" HTTP 
header) in order to determine which Host the request is addressed to, 
but it can't because it does not know which host it is yet, and thus 
cannot decode the request
- we are thus stuck

Is the above, very roughly and approximatively still a valid explanation 
of what happens, or is it totally wrong, or has something changed 
in-between that I am unaware of ?

Thanks


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org