Re: [webmin-l] SSL

[Kris D. <kd...@vi...>]

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