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

[David Anselmi]

This is a little long.  If you don't understand what I'm saying, start a 
new thread and ask specific questions.  Looks like the Apache 2 docs 
have good info on the whole topic too.

Angelo Bertolli wrote:
>  Jim Ockers wrote:
[...]
>> 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.

This is a limitation (feature?) of the SSL protocol.  It has no way to 
say "who are you calling?" and then pick a key based on that.  It should 
be possible to extend the protocol but that hasn't been done (yet). 
Possibly the benefit isn't worth the added complexity.

SSH is not really different.  You have an SSH server with a key and an 
IP address.  There is no way to have the server use different keys for 
the same IP.  The client side is different.

> 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?

Not exactly.  The CN (that the server maps to its IP) is provided to the 
client as part of the SSL handshake.  What the CN is is irrelevant to 
the handshake itself and it is up to the client to decide what to do 
with the CN it is given.  Web browsers match it to the URL and complain 
if they are different.

> 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.

Yes, but then you lose the virtual host part of HTTP.  The browser 
matches the CN with the URL.  If you use an IP for the CN and for the 
URL, all is well.  But then you don't have different URLs at the same IP 
anymore.

You could make a browser that would match the IP (from DNS lookup of the 
URL) with the CN.  That might make some sense.  But it leaves you wide 
open to DNS spoofing.

[...]
> 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.

Man in the middle attacks are actually the easiest attacks against http. 
  And encryption without authentication is essentially useless because 
it permits them.

Who could be a man in the middle?  Obviously the operators of the 
network between me and the server, but I'm not too worried about them. 
They run networks for a living, they don't steal my credit card number 
(some of them already have it).

Who else?  A bad guy that gives me a link disguised to look like my bank 
but that goes to his site.  He could give it to me in email (spam/worm) 
or on a web page.  If I click it, he passes my traffic through to the 
real bank site and sniffs out my account/password/whatever.  My 
connection to the bad guy is encrypted.  His connection to the bank is 
encrypted.  But because I didn't authenticate my connection with the 
bank I don't know anything is amiss.

This is a bigger concern to me than the network operators carrying my 
traffic because anyone can do it, not just those with access to the 
network.  And if I defend against this, I defend against both.  You've 
seen spoofed email claiming to be from Ebay or Paypal.  They don't use 
SSL because they can't (easily) get a certificate to use (not that 
people wouldn't fall for a misleading certificate).

IPSec initially allowed an encrypted mode with no authentication.  It 
doesn't anymore.

[...]
> 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...

Third pary CAs are, IMO, not worth what they charge.  You have to 
understand how much to trust them and people generally don't.  Of course 
running your own CA means understanding how much to trust yourself and 
people probably won't understand that either.

SSH is different because you have to verify the server key manually. 
There are no certs so there's no CA telling you who you can trust.  This 
is simpler than SSL, and adequate for replacing a system of shared 
secrets (passwords) but it doesn't scale for e-commerce.

Dave