On Fri, Aug 13, 2010 at 11:50 PM, Bryan O'Neal <
Bryan.ONeal@theonealandassociates.com> wrote:
> 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 ;)
>
Hey, I just bungle along too.
Not sure what I do, I have made it work in many different environments.
No seriously, I use SSL since modern Apache2 renegotiates the connection
after setting to default host name.
I use multiple SSL server names per CERT for very large installations.
I use SNI otherwise, depending on what the installation dependencies and
needs are:
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
SNI is the more secure option and most modern installations/browsers allow
for this trivially (if we are sure to add the line:
SSLStrictSNIVHostCheck off
>
> 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
>
--
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)