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)
From: Peter Crowther <Peter.Crowther@melandra.com>
To: 'Tomcat Users List' <users@tomcat.apache.org>
Date: Mon, 22 Sep 2008 13:30:58 +0100
Subject: [OT] RE: HTTPS and Virtual Hosts
Thread-Topic: [OT] RE: HTTPS and Virtual Hosts
Thread-Index: AckcrHDeFKwEnsXxT36OMQ/CNVdgfwAAJlFg
Message-ID: <6715CF65287F8F408DA109EC03AC6C0D07E72896EC@puma.melandra.net>
References: <48D75DF1.8010705@ice-sa.com>
 <000201c91c9c$6939ee90$0300000a@animal>
 <6715CF65287F8F408DA109EC03AC6C0D07E72896E4@puma.melandra.net>
 <004701c91cac$775dfa10$0300000a@animal>
In-Reply-To: <004701c91cac$775dfa10$0300000a@animal>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

[Marked OT as this is not even remotely about Tomcat]

> From: Johnny Kewl [mailto:john@kewlstuff.co.za]
> http://support.microsoft.com/kb/257591

... OK...

> If it send the HOST info in step one....

... which it doesn't as far as I can see...

> and the server chose the correct
> cert.... I see no problem, the secure session hasnt even
> kicked in yet ;)

Yes, exactly.  So anything sent across the wire (such as the host header) i=
s subject to eavesdropping.

The URL, in particular, MUST NOT be sent in cleartext - consider a URL of t=
he form https://www.innocentsite.com/myphotos/notsoinnocent/llamapr0n372.jp=
g *.  The user would no doubt expect SSL to defend his/her access to that U=
RL from eavesdropping :-).

The case for not sending the host header in cleartext is weaker, but still =
present.  Consider a blog site such as LiveJournal, for example.  It hosts =
a range of content, separated onto one hostname per blog.  Some of that con=
tent is pretty explicit, and some people might get rather upset if they kne=
w that *even though they thought they were on a secure channel* then others=
 could eavesdrop on the mere fact that they were reading *that* content, ra=
ther than some other innocent content that happened to be on the same IP.  =
So I consider that the ID vul is still present, even via disclosure of just=
 the host header.

> If not what is the vulnerability? Whatever cert is sent what
> oput there by
> the admin dudes, and will be checked client side anyway ;)

You're thinking about ID vuls from the side of the server admin.  Broaden y=
our thinking - what might a *client* get upset about?

                - Peter

* With thanks to User Friendly (http://www.userfriendly.org), over the year=
s, for warping my mind enough to devise this URL.

---------------------------------------------------------------------
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