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
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
