trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <zw...@apache.org>
Subject Re: Deprecation of SSL v2/3
Date Mon, 25 Apr 2016 23:08:01 GMT

> On Apr 25, 2016, at 4:23 PM, Phil Sorber <sorber@apache.org> wrote:
> 
> On Mon, Apr 25, 2016 at 11:01 AM Reindl Harald <h.reindl@thelounge.net <mailto:h.reindl@thelounge.net>>
wrote:
> 
> 
> Am 25.04.2016 um 17:55 schrieb Phil Sorber:
> > On Mon, Apr 25, 2016 at 3:33 AM Reindl Harald
> >     just a notice again before i try to build with other flags
> >     _____________________________________________
> >
> >     https://www.ssllabs.com/ssltest/ <https://www.ssllabs.com/ssltest/>
> >
> >     docs.trafficserver.apache.org <http://docs.trafficserver.apache.org/>
> >     SSL 2 handshake compatibility   Yes
> >
> > I believe what is going on here is that we use SSLv23_server_method()
> > which will negotiate the highest version of TLS supported by both sides,
> > but does so with the SSLv2Hello handshake. This does not mean we
> > necessarily support SSLv2/3.
> >
> >     www.thelounge.net <http://www.thelounge.net/>
> >     SSL 2 handshake compatibility   No
> >
> >
> > It is my understanding that HTTPD matches the server method to only
> > negotiate the version configured. This means it is using something like
> > TLSv1_2_server_method() which only supports the TLS1.2 handshake. What
> > is your HTTPD config?
> 
> as strict as the ATS configuration (see below) and so no reason for the
> current "ab" behavior
> 
> you can verify with https://www.ssllabs.com/ssltest/ <https://www.ssllabs.com/ssltest/>
the following two
> subdomains:
> 
> * secure.thelounge.net <http://secure.thelounge.net/> (httpd)
> * www.thelounge.net <http://www.thelounge.net/> (trafficserver)
> _____________________________________
> 
> httpd:
> 
> SSLSessionCacheTimeout 900
> SSLStaplingStandardCacheTimeout 86400
> SSLStaplingErrorCacheTimeout 300
> SSLStaplingReturnResponderErrors Off
> SSLStaplingFakeTryLater Off
> SSLProtocol All -SSLv2 -SSLv3
> SSLFIPS Off
> SSLCompression Off
> SSLInsecureRenegotiation Off
> SSLSessionTickets Off
> SSLVerifyClient none
> SSLHonorCipherOrder On
> SSLCipherSuite
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:!LOW:!MEDIUM
> _____________________________________
> 
> ap_log_error(APLOG_MARK, APLOG_TRACE3, 0, s,
>                  "Creating new SSL context (protocols: %s)", cp);
> 
> Can you turn on TRACE3 level logging in HTTPD and see if you can find the output of that?
Trying to trace through the code path in HTTPD to see what they might be doing different than
us.


None of this explains why e.g. docs.trafficserver.apache.org nor www.ogre.com have these issues
:-/

Can anyone else confirm this failure behavior?

— Leif



Mime
View raw message