Hi, I've modified the subject so that people with SSL skills notice it.
On Sat, Feb 21, 2015 at 02:06:51AM +0100, Baptiste wrote: > On Sat, Feb 21, 2015 at 12:39 AM, NuSkooler <[email protected]> wrote: > > Some additional gritty details: > > * socat 'show errors' shows 0 errors > > * The same bad clients fail to connect to a OpenSSL s_server (logs below) > > > > Since we can't even properly connect to s_server, that may be the end > > of the road for those clients. However, I'm hoping there may be > > something that could be configured to allow them through HAProxy. > > Below is a s_server log. Note the read failure at the end. A similar > > capture in the view of Wireshark is below that. Lastly, *with* HAProxy > > when the NOSRV/BADREQ is issued, the client is sent a encrypted 400 > > Bad Request. > > > > Any help/tips appreciated! This represents a large client base that > > unfortunately cannot be updated for the time being. If we cannot go > > through HAProxy directly, the next step is to figure out a way to > > route old clients around it :( > > > > Hi, > > Since HAProxy returns a 400, it means that the issue is above the SSL > connection. > You should enable HAProxy's stats socket and run the following command > on it right after a 400 has been emitted: "show errors" 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
