Am 25.04.2016 um 16:10 schrieb Phil Sorber:
On Mon, Apr 25, 2016, 08:05 Reindl Harald <[email protected] <mailto:[email protected]>> wrote: Am 25.04.2016 um 15:54 schrieb Leif Hedstrom: >> On Apr 25, 2016, at 4:47 AM, Reindl Harald <[email protected] <mailto:[email protected]>> wrote: >>>>> i will give it a try ASAP, however the whole web and mail stack is >>>>> built with that flags (based on the flags below which are %{optflags} >>>>> and only ATS has the specific problem >>>> >>>> Yeah, it seems odd that it’d break like that because of compiler flags. >>>> But I honestly have no other ideas as to why it breaks on your system, >>>> and not mine :-/. Can anyone else confirm or deny this breakage on their >>>> installs? >>> >>> just a notice again before i try to build with other flags >>> _____________________________________________ >>> >>> https://www.ssllabs.com/ssltest/ >>> >>> docs.trafficserver.apache.org <http://docs.trafficserver.apache.org>: >>> SSL 2 handshake compatibility Yes >>> >>> www.thelounge.net <http://www.thelounge.net>: >>> SSL 2 handshake compatibility No > > Double checked the docs.trafficserver configs: > > [root@docs ~]# traffic_ctl config match proxy.config.ssl.SSLv > proxy.config.ssl.SSLv2: 0 > proxy.config.ssl.SSLv3: 0 > > I have no idea what this means, is there something in here that makes it properly detect that we handle V2, but do not negotiate it? i have both at the same value since i am not the TLS internals guru i can't say what goes wrong and where, my httpd servers have "SSL 2 handshake compatibility Yes" and my ATS servers never had but that pretty sure explains "140575331768288:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769" which don't happen to my other servers given that this is for years now, don't happen on identical virtual machine clones running httpd instead ATS for me ATS is guilty and not any other piece in the stack not sure what "s23_clnt.c:769" means since there is no "s23_clnt.c" in the httpd source tarball from which "ab" at the end is built I believe that is in OpenSSL
ok, but still don't explain why the same OpenSSL binary in the lcient as well in the server don't suffer from this issue without ATS
signature.asc
Description: OpenPGP digital signature
