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