So you do name based virtual hosts with SSL and without SNI? I would
love to see your config files!
- As always you teach us lowly mortals so much ;)
On Fri, Aug 13, 2010 at 11:38 PM, Lisa Kachold <
lisakachold@obnosis.com> wrote:
> 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
> "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
>
---------------------------------------------------
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)