Hi Actually, most answers in this thread are more or less outdated. It IS possible to use one IP with multiple certificates, just not with tomcat to far.
There IS (since June 2003, that is more than 5 years!) a TLS extension SNI (server name indication) that does the trick: It sends Information about the requested hostname to the server during ClientHello handshake. It IS supported by almost all browsers in their current versions. See: http://www.ietf.org/rfc/rfc3546.txt, Section 3.1 See: http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-host s-with-mod_gnutls/ I hope this will find it's way into java/tomat soon. Regards, Steffen -----Ursprüngliche Nachricht----- Von: Johnny Kewl [mailto:[EMAIL PROTECTED] Gesendet: Montag, 22. September 2008 15:02 An: Tomcat Users List Betreff: Re: [OT] RE: HTTPS and Virtual Hosts ----- Original Message ----- From: "Peter Crowther" <[EMAIL PROTECTED]> To: "'Tomcat Users List'" <users@tomcat.apache.org> Sent: Monday, September 22, 2008 2:30 PM Subject: [OT] RE: HTTPS and Virtual Hosts [Marked OT as this is not even remotely about Tomcat] > From: Johnny Kewl [mailto:[EMAIL PROTECTED] > 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) is subject to eavesdropping. The URL, in particular, MUST NOT be sent in cleartext - consider a URL of the form https://www.innocentsite.com/myphotos/notsoinnocent/llamapr0n372.jpg *. The user would no doubt expect SSL to defend his/her access to that URL 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 content is pretty explicit, and some people might get rather upset if they knew 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, rather 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 your thinking - what might a *client* get upset about? - Peter Ok... its off thread, but I disagree.... the secure session doesnt start out secure... even a certificate is clear text, dont see the big deal... once you in a session, different story... I guess this means you not going to help me with my new book ;) Curve Ball technology for biz sake... ha ha --------------------------------------------------------------------------- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --------------------------------------------------------------------------- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
