> Attached is a pcap with the bind line cut+paste from your link.
>
> In this case I see Encrypted Alert, but I'm struggling to decrypt it
> in WS with this setup.
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
