> On Apr 25, 2016, at 4:23 PM, Phil Sorber <[email protected]> wrote: > > On Mon, Apr 25, 2016 at 11:01 AM Reindl Harald <[email protected] > <mailto:[email protected]>> 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
