A bit late to this discussion but the issues sound familiar. I've seen this type of issue in the past between openssl and java's ssl implementation, primarily in java 6 and java 7. I don't remember the full details but from what I recall avoiding the EC based ciphers from the supported list resolves the issue.
The following are some references that should help clarify: - http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC - https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1006776 - https://bugzilla.redhat.com/show_bug.cgi?id=1022017 For our java apps behind haproxy we limited their supported ciphers to: - TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 # for TLS 1.2 - TLS_DHE_RSA_WITH_AES_128_CBC_SHA # for TLS 1.1 TLS1.1 is required for testing with libssl based clients, otherwise we'd have left that out. Hope this helps. Jinn On 23/02/2015 21:55, NuSkooler wrote: > Attached is the information you requested -- and hopefully performed > correctly :) > > * no_haproxy.pcap: This is a successful connection + POST to the > original Mochiweb server. Note that here the port is 8443 not 443 > (IP=10.3.3.3) > * ha_self_signed.pcap: Failed attempt against HAProxy with a self > signed certificate & key. > * TEST_cert_and_key.pem: The self signed cert/key from above. > > The bind line for ha_self_signed.pcap looks like this: > bind *:443 ssl crt /home/bashby/Lukas/TEST_cert_and_key.pem ciphers AES128-SHA > > Thanks again to you and everyone here taking the time to look at this! > > On Mon, Feb 23, 2015 at 2:01 PM, Lukas Tribus <luky...@hotmail.com> wrote: >> Ok, so as expected, this didn't really change anything, but at least >> we have a config/capture consistency. >> >> Now, it looks like the client decides after the (what appears to be a >> successful) handshake to close the connection by sending a FIN, which >> then triggers the "400 Bad request" from the haproxy side. >> >> Two questions we need address: >> - how does the handshake look like in the legacy config (Mochiweb terminates >> SSL) when using those old apps/clients? >> - what happens on from a SSL/TLS perspective on the unencrypted layer? >> >> >> So, could you possibly: >> - send us a working SSL/TLS session pcap trace of those clients/app on your >> current mochiweb service? Perhaps the client is buggy on all but a specific >> ciphers, although he advertises otherwise. If we replicate the mochiweb SSL >> handshake as close as possible, we may be able to get it to work, and then >> we >> can start pin pointing the issue. For example, we could try to force: >> TLS_RSA_WITH_RC4_128_MD5 by configuring "RC4-MD5" as cipher string in >> haproxy. >> >> - recreate the issue with a self-signed key/cert and a non-FS ciphers, >> and provide us pcap, cert and private key (triple checking none of >> those thing are confidential)? That way, we see what happens inside the >> encrypted channel. Since the client doesn't really send any application >> data, >> what we are most interested in are encrypted handshake messages. >> >> >> Its pretty clear the Mozilla recommendation doesn't help us in this case, >> since >> there seems to be a specific implementation bug, so we may as well use non-FS >> ciphers for the troubleshooting session. >> >> >> >> Regards, >> >> Lukas >> >>
