Thanks for updating the subject -- this does seem to be SSL/handshake related. I'm pretty confident that these are just bad clients that were getting away with whatever they're doing on the old Mochiweb SSL setup. As a last resort we're coming up with a backup plan on routing them to the old setup and newer clients via HAProxy, but as you say, it will be irritating to not know the real issue here.
For reference here is my HAProxy configuration file. I probably should have posted it sooner: http://pastebin.com/9c77k5FS Here is haproxy -vv output: HA-Proxy version 1.5.11 2015/01/31 Copyright 2000-2015 Willy Tarreau <w...@1wt.eu> Build options : TARGET = linux2628 CPU = x86_64 CC = gcc CFLAGS = -g -fno-strict-aliasing OPTIONS = USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built with OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013 Running on OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 8.32 2012-11-30 PCRE library supports JIT : no (USE_PCRE_JIT not set) Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. On Sat, Feb 21, 2015 at 2:25 AM, Willy Tarreau <w...@1wt.eu> wrote: > I've modified the subject so that people with SSL skills notice it. > > Unfortunately he said there were zero errors. The BADREQ here is the > result of the failed handshake leading to the connection being closed > before a request is received. That makes me think that we don't start > the full session until a handshake is completed, so if we see this log, > it means that the handshake completes. It's possible then that the > client terminates the SSL session just at the end of the handshake, > with a TLS alert or something like this, resulting in no request being > received over that connection. I suspect something is improperly > negociated and the handshake never completes, maybe a cipher or > something like this. Just thinking loud, maybe this is totally > different and the client runs with a null timeout and closes before > having a chance to send a request :-/ > > It may help to try to refine the ciphers string to something very > minimal, and/or to experiment with force-tlsv12 or force-sslv3 to > see if this is something related to the SSL/TLS protocol version. > > Maybe some of the TLS experts here can bring a few hints :-/ > > The fact that it also fails with openssl s_server makes me think > that there's definitely something odd with the client, but it's > really irritating not to find what. > > Willy >
