HTTPS and Virtual Hosts
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTPS and Virtual Hosts
From: André Warnier [mailto:[EMAIL PROTECTED] 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 Almost. The client connects to the host on a given IP address and port, which requires an encrypted connection. No hostname is transferred at this point, as encryption must happen first. - the host and client negociate the encryption (based or not on the name of the host) Based on the certificate that the host sends to the client as part of negotiating the encryption. That certificate contains the common name of the host (or occasionally a wildcard name such as *.melandra.com). The client should be suspicious if the common name in the certificate does not match the hostname the client thinks it sent the request to. Therefore, the host cannot know to which virtual host the client wishes to connect when it sends the certificate. Therefore, the host cannot send the right certificate unless all requests to a given hostname and port are designed to use the same certificate. Therefore, virtual hosting using SSL is a problem. 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 ? It's close, but the problem occurs at an earlier step than you outline :-). - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: HTTPS and Virtual Hosts
From: Ognjen Blagojevic [mailto:[EMAIL PROTECTED] For instance, you could put 2 or more network cards in the server, and than configure one virtual host for each of these cards. Or configure multiple IP addresses on one card - almost all operating systems these days allow multiple IP addresses on one adapter. Cheaper, and you don't run out of card slots so fast :-). - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTPS and Virtual Hosts
André Warnier wrote: 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 ? Yes, that's about it. Here is the official explanation: http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts The workaround is also proposed. You can use different ports or IP adresses for different SSL enabled virtual hosts. For instance, you could put 2 or more network cards in the server, and than configure one virtual host for each of these cards. -Ognjen - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTPS and Virtual Hosts
Ognjen Blagojevic wrote: André Warnier wrote: 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 ? Yes, that's about it. Here is the official explanation: http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts The workaround is also proposed. You can use different ports or IP adresses for different SSL enabled virtual hosts. For instance, you could put 2 or more network cards in the server, and than configure one virtual host for each of these cards. You do not need multiple NICs to support multiple IP addresses. You can quite happily configure a NIC with multiple IP addresses. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] RE: HTTPS and Virtual Hosts
Peter Crowther wrote: Or configure multiple IP addresses on one card - almost all operating systems these days allow multiple IP addresses on one adapter. Cheaper, and you don't run out of card slots so fast :-). Didn't know that. That's definitely better. -Ognjen - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTPS and Virtual Hosts
- Original Message - From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, September 22, 2008 10:57 AM Subject: HTTPS and Virtual Hosts 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 -- Mmm yes... kinda Andre check out the hand shake in SSL... Keeping it very conceptual... the secure system between a browser and server is owned by Verisign, or GoDaddy, or whatever CA. And it is checking a few things... Like the domain name used and the expiry date... So when you buy a cert and give them www.andre.com Thats it... This is because the cert is pulled (checked) during the handshake... and host headers only come later... thats the official version of the story, but I actually cant see any reason why the hand shake couldnt be extended to look at the incoming URL... other than people would start doing server tricks and making extra free certs ;) I conclude... its more about biz, that it is about technology certificates are sold per domain... this is the real issue ;) Its actually interesting, because when we were making the Pojo server, this issue came up... especially because we want to give the company using the system the ability to be a CA... so we dropped the domain check, and then the only condition on the server is that the administrator knows the private key... ... clearly a really crap biz model because one can use the certs on a million servers... but an interesting thing happens... ... virtual host are NOT and issue ... Its secure on any port Ha ha... its about the biz model I believe ;) Hell they got to make money and it is beeg bucks... a local chap made a cool 3 billion dollars out of his CA ;) Yup... I think its about biz ;) --- 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]
Re: HTTPS and Virtual Hosts
- Original Message - From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, September 22, 2008 10:57 AM Subject: HTTPS and Virtual Hosts 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 -- Mmm yes... kinda Andre check out the hand shake in SSL... Keeping it very conceptual... the secure system between a browser and server is owned by Verisign, or GoDaddy, or whatever CA. And it is checking a few things... Like the domain name used and the expiry date... So when you buy a cert and give them www.andre.com Thats it... This is because the cert is pulled (checked) during the handshake... and host headers only come later... thats the official version of the story, but I actually cant see any reason why the hand shake couldnt be extended to look at the incoming URL... other than people would start doing server tricks and making extra free certs ;) I conclude... its more about biz, that it is about technology certificates are sold per domain... this is the real issue ;) Its actually interesting, because when we were making the Pojo server, this issue came up... especially because we want to give the company using the system the ability to be a CA... so we dropped the domain check, and then the only condition on the server is that the administrator knows the private key... ... clearly a really crap biz model because one can use the certs on a million servers... but an interesting thing happens... ... virtual host are NOT and issue ... Its secure on any port Ha ha... its about the biz model I believe ;) Hell they got to make money and it is beeg bucks... a local chap made a cool 3 billion dollars out of his CA ;) Yup... I think its about biz ;) --- 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]
RE: HTTPS and Virtual Hosts
From: Johnny Kewl [mailto:[EMAIL PROTECTED] I actually cant see any reason why the hand shake couldnt be extended to look at the incoming URL... Because the URL (or at least the host header) would have to be sent over the wire in cleartext, as it's before the encrypted connection is negotiated. This is an information disclosure vulnerability. - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTPS and Virtual Hosts
Mark Thomas wrote: Ognjen Blagojevic wrote: André Warnier wrote: 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 ? Yes, that's about it. Here is the official explanation: http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts The workaround is also proposed. You can use different ports or IP adresses for different SSL enabled virtual hosts. For instance, you could put 2 or more network cards in the server, and than configure one virtual host for each of these cards. You do not need multiple NICs to support multiple IP addresses. You can quite happily configure a NIC with multiple IP addresses. Allright. Thanks to everyone for the answers and references. This was also linked to another thread Re. Connector problem, for which I am also interested in the practical solution. Now, a follow-up question : I seem to remember that there was talk about a scheme or a protocol that would allow (very roughly) a client/server pair to start a session using HTTP (not SSL), negociate, then in the course of the session upgrade this link to HTTPS. And that this somehow could be a solution to the Virtual Host issue under HTTPS. Am I dreaming this up, or does there exist something in that general area ? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HTTPS and Virtual Hosts
From: André Warnier [mailto:[EMAIL PROTECTED] I seem to remember that there was talk about a scheme or a protocol that would allow (very roughly) a client/server pair to start a session using HTTP (not SSL), negociate, then in the course of the session upgrade this link to HTTPS. And that this somehow could be a solution to the Virtual Host issue under HTTPS. Am I dreaming this up, or does there exist something in that general area ? I've no idea whether such a protocol exists today; however, the current set of browsers don't appear to support such a beast. It might be a good solution 5 years down the line, once all the old browsers that don't support it have fallen out of use, but even if the protocol's ready to go now the installed browser base isn't ready for a site that uses it. - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 12:19 PM Subject: RE: HTTPS and Virtual Hosts From: Johnny Kewl [mailto:[EMAIL PROTECTED] I actually cant see any reason why the hand shake couldnt be extended to look at the incoming URL... Because the URL (or at least the host header) would have to be sent over the wire in cleartext, as it's before the encrypted connection is negotiated. This is an information disclosure vulnerability. - Peter http://support.microsoft.com/kb/257591 If it send the HOST info in step one and the server chose the correct cert I see no problem, the secure session hasnt even kicked in yet ;) So what are they not allowing? I think the only vulnerability is to the CA's biz model ;) If not what is the vulnerability? Whatever cert is sent what oput there by the admin dudes, and will be checked client side anyway ;) --- 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]
Re: HTTPS and Virtual Hosts
- Original Message - From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Monday, September 22, 2008 12:21 PM Subject: Re: HTTPS and Virtual Hosts Mark Thomas wrote: Ognjen Blagojevic wrote: André Warnier wrote: 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 ? Yes, that's about it. Here is the official explanation: http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts The workaround is also proposed. You can use different ports or IP adresses for different SSL enabled virtual hosts. For instance, you could put 2 or more network cards in the server, and than configure one virtual host for each of these cards. You do not need multiple NICs to support multiple IP addresses. You can quite happily configure a NIC with multiple IP addresses. Allright. Thanks to everyone for the answers and references. This was also linked to another thread Re. Connector problem, for which I am also interested in the practical solution. Now, a follow-up question : I seem to remember that there was talk about a scheme or a protocol that would allow (very roughly) a client/server pair to start a session using HTTP (not SSL), negociate, then in the course of the session upgrade this link to HTTPS. And that this somehow could be a solution to the Virtual Host issue under HTTPS. Am I dreaming this up, or does there exist something in that general area ? Andre, I'm not aware of anything like it... one can actually do anything with crypto stuff, but the problem is that half the engine is built into the browser, if it doesnt want to play, it doesnt happen... there are do it yourself secure layers out there at javascript level, but they have issues... dont secure whole page etc. ... dont think so... However as soon as you leave the browser environment... anything is possible. --- 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]
[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 * With thanks to User Friendly (http://www.userfriendly.org), over the years, for warping my mind enough to devise this URL. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
