I have never heard so much various misinformation in my life!
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
>>
>
>
>
I setup SSL Certificates in NAT environments all the time.
Various solutions are available:
1) Apache2 Name Based Virtuals
2) /etc/hosts file utilization on the server
3) split DNS for IP based virtuals
It's not called Network Address Translation for nothing!
This is very simple (you are thinking about this triangulated authentication
from a one sided point of view):
*If the IP ADDRESS matches the SSL CERT, DNS name and certificate called
from the browser to Apache2, the content will be trusted. It's just that
simple.*
Reference:
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch20_:_The_Apache_Web_Server
--
Office: (602)239-3392
AT&T: (503)754-4452
http://it-clowns.com <
http://it-clowns.com/wiki/index.php?title=Obnosis>
"Faith is, at one and the same time, absolutely necessary and altogether
impossible. "
--Stanislav Lem
---------------------------------------------------
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)