OT (slightly): SSL Requirement

[Eric Shubert]

Thanks Russ. You're once again a great sanity check. :)
-- 
-Eric 'shubes'

R P Herrold wrote:
> On Fri, 13 Aug 2010, Eric Shubert wrote:
> 
>> I don't necessarily believe everything I see, and would like to check 
>> on something I read.
>>
>> Is the following statement true or false?
>>
>> "SSL requires a distinct outbound IP for every distinct certificate
>> (different domain name)."
> 
> Clearly technically not true, but not in the way you probably expect -- 
> One can have a SSL certificate for the purposes of securing web content, 
> and a separate one for the purpose of securing email transfer -- check 
> the headers of this piece, whch use a StartSSL [highly recommended] 
> certificate for opportunistic SSL layer transport of content
> 
> If you had added the qualifier 'for a given protocol (TCP) and port 
> (443) pair', it would be true in the usual case, absent heroic and 
> non-customary approaches
> 
>> My understanding is that multiple hosts with distinct certificates 
>> could coexist behind a NAT'd firewall on a single public address and 
>> still provide SSL connections via the public address.
>>
>> Would someone who's more knowledgeable than I about this care to shed 
>> some light on the subject?
> 
> I assume web connection here.  I put to one side a 'wildcard' 
> certificate where several boxes all offer a connection secured by a 
> single credential.  TLS/SSL protected email to multiple clients using 
> differing certificates, as the negotitaion occurs 'late enough' that one 
> could 'hand off' a connection, perhaps, to a second unit inside a load 
> balancer, to complete the SSL/TLS connection setup.
> 
> The flaw with a webbish (port 443) delivery in your setup is based on 
> when in the request the secured connection is set up
> 
> The negotiation and establishment of the SSL tunnel occurs BEFORE any 
> hostname part (indeed, any part) of the URL is transmitted.  How would 
> the NAT device know which credential to offer?  How can the remote end 
> verify that an offered certificate is not on a recovation list at the CA?
> 
> If a connection were established to point A on the outside, with a 301, 
> 302 type redirector to  a 'new' URL 'inside' it might be doable as a new 
> secured connection setup can occur, and if there is low volume and a 
> unique client IP at the far end, but this cannot be counted upon ...
> 
> I see a suggestion tht a Level 3 router can sniff the request and do 
> internal direction.  I am aware of no such mechanism to do this only up 
> to L3 of the stack in a web session.  The needed session credentials are 
> not yet knowable at the time of the negotiation ond DH key exchange of 
> the session encryption key.  Once that session is set up, there is not a 
> mechanism for a 'handoff' of a running session, for that is the essence 
> of a Man in the Middle attack
> 
> -- Russ herrold