Menu
▾
▴
RE: [webmin-l] SSL
|
From: Ravi G. <mai...@ra...> - 2006-03-27 18:55:26
|
Kris, Thanks for the explanation. I have already arranged to buy ip addresses so things should be straight now. Ravi. -----Original Message----- From: web...@li... [mailto:web...@li...] On Behalf Of Kris Deugau Sent: Monday, March 27, 2006 10:44 AM To: web...@li... Subject: Re: [webmin-l] SSL Ravi Gehlot wrote: > When you say "not effectively" you mean it wouldn't work? In short, no. > If I could > type on my browser http://www.thataddress.com/ and have it proxied to > http://www.thataddress.com:8080/ That would work fine for HTTP (please note, NOT HTTP*S*!) because the browser has a chance to send the domain/site address it's looking for before it sets up the SSL layer. But then with standard HTTP you don't need to bother with multiple ports because that mechanism is available in the first place. > then it would be great because none of > my clients would need to know what "non-standard" port the website is > being forwarded. Now, with this in mind I know that I can install > multiple SSL certificates in one shared IP where all web addressed would > use a non-standard port. Indeed, I could secure many websites sharing > the same ip without having obligating my customers to know port numbers. If you're serious about providing HTTPS service for your customers, you'll do it right and set each secure site up with its own IP. About the best you can do otherwise is have a "shared" HTTPS site that either acts as an HTTPS proxy wrapper for the "real" site (https://secure.yourdomain.com/customersite), or you must include the bare alternate port numbers in the address so Apache can figure out which site to serve (https://customer.com:customport). http:// URLs will not be secure, because the browser won't know to initiate the SSL key exchange. Here's the detailed reason why: Regular HTTP access: The browser opens a connection to the specified port (or the standard HTTP port if none is specified) on the appropriate server. It sends the HTTP request, along with additional headers that tell the webserver which domain it's looking for: GET / HTTP/1.1 Host: domain1.com The above two pieces are the bare minimum for hosting multiple regular websites on a single IP; I can't think of any browsers that DON'T support this capability. Based on that "Host:" header, the webserver can pick which of the virtual hosts to send out the default index page for. If it's omitted, most webservers include configuration for a default virtualhost, which is what will be served. HTTPS access: The browser opens a connection to the specified port (or the standard HTTPS port if none is specified) on the appropriate server. It initiates the key and certificate exchange necessary to A) secure the connection (key exchange) and B) provide some degree of authenticity for the site address (certificate). Note that at this point, the webserver has NOT received an HTTP-specific request; this process is part of ALL certficate-associated SSL connections! The ONLY information the webserver has with respect to which site to provide content from is the IP and port that the browser connected to. Once the SSL handshake is finished, the browser then sends the same basic request headers as with regular HTTP access. But at this point, because of the SSL handshake, there is no way to suddenly switch to a different virtual host; doing so would require a new SSL handshake - which would have to be chosen based on a different IP and/or port than the original connection. -kgd ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 - Forwarded by the Webmin mailing list at web...@li... To remove yourself from this list, go to http://lists.sourceforge.net/lists/listinfo/webadmin-list |