Hi all,

I'm only reposting below Lukas' mail without mixed text/plain Content-Type and html inside, in case someone couldn't read it ;-)

Le 24/02/2015 01:04, Lukas Tribus a écrit :
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!

Ok, so what I can see by decrypting the SSL session with the self signed
certificate is that as soon as the server sends the "Server Hello Done", the
client sends a "TLS Finished". So the client doesn't like the Server Hello,
basically, or something along those lines.

Comparing it with no_haproxy.pcap, its immediately obvious that without
haproxy, you are doing client certificate verification: the server asks the
client to provide a client certificate and verifies that certificate.

You are also doing client certificate verification in haproxy_1.pcap (which
fails).

So, maybe those clients absolutely want to send their certificate and
abort the TLS session a soon as the handshake is complete if the server
actually didn't request their certificate.

And maybe, in your first configuration (where you DO verify the client
certificate, their is certificate mismatch that fails on the HAProxy
side, which is why HAproxy in this case closed the session - we don't
know, because we can't decrypt the relevant handshake messages in
haproxy_1.pcap).


In fact, when I look at your config on pastebin, I can see that you
used "crt-ignore-err all" on the bind line, but that should probably be
"ca-ignore-err all", I believe. The documentation doesn't really do
a good job of explaining the difference between ca and crt-ignore-err.

Can you retry with "ca-ignore-err all", and, if it still doesn't work,
provide the pcap trace in this config:

bind *:443 ssl crt /home/bashby/Lukas/TEST_cert_and_key.pem ciphers AES128-SHA \
verify optional ca-ignore-err all crt-ignore-err all ca-file 
/etc/ssl/certs/cw_client_ca.pem



I am not an expert but from the following I can understand
that client and server agreed to use
TLS_RSA_WITH_AES_128_CBC_SHA cipher but over SSLv3. I am wondering if
AES cipher suite is supported on SSLv3

No, its really TLSv1.0 that we see in this handshake (TLSv1.0 is 3.1, TLS
v1.1 is 3.2, TLSv1.2 is 3.3). Also ssldump has not seen any updates in
about 10 years, which is why it doesn't recognize most of the ciphers, FYI.



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.

We are using non-FS ciphers like AES128-SHA here anyway, so we already
excluded that.



Regards,

Lukas


--
Cyril Bonté

Reply via email to