On Fri, Aug 13, 2010 at 9:49 PM, Eric Shubert
<ejs@shubes.net> wrote:
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