The TLS handshake is working fine. The issue is that HAProxy is trying
to speak SPDY
with your clients, and they most likely don't support it.
In the Haproxy_1 capture, look at packet #61 send by haproxy to the
client. The application
data protocol is set to SPDY. Is this the expected behavior of your
endpoint?
- Julien
On 2015-02-23 12:33, NuSkooler wrote:
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
