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

[Angelo Bertolli]

>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.
>
>  
>
I'm imagining the SSL layer going between the TCP/IP layer and the HTTP 
layer.  I guess there are two things I would like to know:

1) The SSL layer obviously knows the common name to do its job, so when 
the initial connection is made, can it simply provide the name and 
expect the server to respond with the correct certificate?

or

2) Can a common name instead be an IP address, and all SSL connections 
to virtual hosts be checked against the IP address instead of the URL 
domain request.

>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.
>
>  
>
The way it was put to me is that if I wanted to configure the server for 
multiple SSL connections under different domain names, I would have to 
get multiple IP addresses.  Seems like a waste to me.  So I ended up 
doing (what I think a lot of people do) was just creating 
mysecuredomain.com and anything that any other domain needs to have 
secured gets a directory under this domain name.

I believe the most important thing is encrypting the information.  I 
know a lot of security-minded people will yell at me for not really 
caring about "man in the middle" attacks, but... I really don't think it 
will ever happen.  I've never even heard of it happening to anyone--I 
think it's easier to compromise the server and just take all the 
information directly.


>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?
>
>  
>
Maybe.  I'm thinking of a layer which lies underneath HTTP, and is 
decrypted by the time it gets to that protocol.  I think security must 
necessarily be its own layer for it to be robust.

Thanks for all the insights into the complexities involving third 
parties.  That's really the problem here... if only everything operated 
like ssh without giving you that warning that scares people off...

Angelo