[CLUE-Tech] apache ssl only on non-well-known port?

[Jim Ockers]

Angelo,

Angelo Bertolli wrote:
> 
> > The SSL key exchange happens before any HTTP data is exchanged.
> 
> And therefore it is impossible for the server to know which domain name
> you are using before the SSL is set up?  Well that's understandable, but
> after the SSL connection is set up, couldn't we still decide on which
> virtual host to use?

Each key is issued to a specific common name (server name).  Suppose
your scenario were true, and consider this:

User puts in https://www.domain.com/ , where www.domain.com resolves
	to 10.1.1.1.
Web browser connects to server 10.1.1.1:443.
Server presents "certificate" (issued for www.domain.com) to browser.
Browser verifies that CN matches URL.
HTTP headers exchanged.

User puts in https://www.domain2.com/ , where www.domain2.com resolves
	to 10.1.1.1.  (Virtual hosted, per above.)
Web browser connects to server 10.1.1.1:443.
Server presents "certificate" (issued for www.domain.com) to browser.
Browser notices that the certificate's CN does not match the URL,
	and presents a warning/error message.

I think what you're asking might require changing the cryptographic
keys in the middle of an SSL connection, so that a different "certificate"
is presented based on the name of the server given.

I'm sure that some technical people have looked at this but as far as
I know the current state of the art is that each certificate is valid
for one server name and one IP address.  Incidentally you can issue
certificates yourself that are valid for *.domain.com or just * if
you want; then you can use the same certificate for multiple sites.

I don't think that any/many web servers support the use of more than
one certificate per IP address, since it doesn't make sense given the
current common SSL architecture.

> > The SSL keys are issued to specific hosts (unless you issue your own).
> > Therefore the SSL key has to match the hostname that is using that key.
> > The browser uses information in the key (common name) to compare with
> > the servername that was in the URL; if they don't match it throws an
> > error dialog box up.
> 
> We use our own key, but we are given a certificate by a trusted third
> party.  It would be nice if certificates were valid for "anything at that
> IP address" but maybe this would compromise some security.

I think you can have more than one IP address using the same certificate,
but I don't think any/many web servers let you have more than one
certificate on the same IP address.

> > With SSL the server returns information (the key) as part of the key
> > exchange before the browser can tell it what site it wanted to connect.
> 
> But that's not really the beginning of an HTTP session is it?  Shouldn't
> we be able to start a regular encrypted HTTP session that doesn't know
> anything about the SSL that is being used?

It is the beginning of an HTTPS session.  Unfortunately "a regular 
encrypted HTTP session" is by definition a SSL/TLS session.  I might
be reading your question wrong but it sounds like you're asking
about an encrypted session that doesn't know anything about the
underlying encryption?

If you want to play with HTTP in SSL you can use stunnel, which is
a nifty tool for mucking around with SSL/TLS encryption.  Check this 
out:

$ stunnel -c -r maradi.ockers.net:443
GET / HTTP/1.1
Host: maradi.ockers.net

HTTP/1.1 200 OK
Date: Sat, 03 Apr 2004 00:17:27 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) etc. etc. etc.

If you wanted to you can try out your HTTP/1.1 virtual hosting stuff
against various web servers using stunnel to make the SSL invisible,
and you can just type in the HTTP commands you want to issue.

Hope this helps,
Jim

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/