Hi, > 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 :(
Can you share the actual pcap file of the fails ssl handshake so I can take a look at it in Wireshark/ssldump? Can you tell what exact JRE release those clients are running? For example, does it affect JRE 6 but not JRE 7? Out of the blue, I would suggest to make sure DH params for DHE ciphers are fixed to 1024 bit (known Java limitation to only support 1024 bit with DHE ciphers in the older releases) - this can be either in the certificate file or generated by haproxy at startup (in which case its configurable with tune.ssl.default-dh-param) and to set the other parameters as mentioned in: https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility Regards, Lukas
