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 > >
ha_self_signed.pcap
Description: Binary data
no_haproxy.pcap
Description: Binary data
TEST_cert_and_key.pem
Description: Binary data
