I'm not currently sure on the JRE version. These are Android clients written with a old Android SDK. All new clients are C++ / OpenSSL based.
I have set the DH param size to 1024 with the same results. Additionally, I set up a bind statement that reflects that of the backward compatibility link you provided from Mozilla. Again, with no luck. Attached two pcap files: haproxy_1.pcap: Capture of client against HAProxy with the target configuration I started with + 1024 DH param. HAProxy is @ 10.3.2.74 here haproxy_2.pcap: Capture of the client against OpenSSL s_server run as such: openssl s_server -accept 443 -cert ~/Downloads/json_rpc_server_cert_and_key.pem -msg -debug -state. s_client is @ 10.3.2.118 here In both cases the client is @ 10.1.1.93. (Note: I'm not 100% sure if I can attach here; If not I'll post links in a follow up) On Sat, Feb 21, 2015 at 3:15 AM, Lukas Tribus <luky...@hotmail.com> wrote: > 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 > >
haproxy_1.pcap
Description: Binary data
haproxy_2.pcap
Description: Binary data
