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 -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)