Hi Andrei,
I
only see a single session of that IP in the cap file.
What we
can see from the dump is:
- the client provides both a TLS session
ticket and a session ID
- the server acknowledges the session ID
-
the server sends a "Change Cipher Spec" message [1]
- the client
disconnects
I don't think this is enough information to draw a
conclusion. A wild
guess could be that the client gets upset about
the Change Cipher Spec
message, but that is really a very wild guess.
We
would need to see the session before and after this one, to be able to
put
them in context. Any additional informations about the User-Agent would
certainly
also help.
Btw, can you clearly reproduce this, or is this a
random session failed on
your prodution box?
Regards,
Lukas
[1]
http://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Change_Cipher_Spec_Protocol
Hello Andrei,
That
would definitely help, in order to pass it via ssldump. Or you can
do
it yourself as well. What I'm seeing anyway (-q wasn't the most helpful
option
here :-)) is that the client closes first. The sequence looks like
this
:
client SYN server
port 58713
-----------------------> :443
SYN/ACK
<-----------------------
ACK
----------------------->
PSH: TLSv1 client
hello with SNI
----------------------->
PSH: TLSv1 server hello
<-----------------------
FIN: client decides to close
----------------------->
FIN: server
acknowledges and closes
<-----------------------
RST: client had already closed
----------------------->
So in short, the client disagrees
with what the server proposed. Either
it's because of the algorithms
in use, or because something is missing.
For example, I'm not seeing
any certificate presented by the server, so
it looks like session
resumption.
Ssldump would tell us what algorithms were negociated
in each direction.
You can also try with tshark/wireshark I think.
Best
regards,
Willy
Hello Andrei,
It's
very hard to suggest anything unfortunately, since most SSL/TLS errors
can
be very cryptic. It would be nice if you could take a pcap capture of
one
such faulty connection so that we can see the whole handshake and try
to
find what the issue is. Many things can be involved, including
versions,
algorithms, key sizes, etc...
In order to take this
capture, please use "tcpdump -s0 -npi eth0 -w file.cap"
to ensure
that packets are not truncated. If you'd prefer not to reveal your
public
IP address on the list, then please send me the capture in private.
But
I must say that people here on the list tend to read SSL traces faster
than
me :-)
Regards,
Willy
Hello everyone!
I've moved off AWS ELB today to HAProxy 1.5dev18. I'm doing SSL
termination at the LB and I'm encountering a rather large number of
messages such as:
- SSL Handshake failure
- Timeout during SSL handshake
- Connection closed during SSL handshake
The problem is similar to the one I've found in the archives about 2
weeks ago (
http://marc.info/?l=haproxy&m=137158875803495&w=2),
but unfortunately I'm unable to debug this. I'm trying to clarify if
these are errors that are normal and I just didn't see on ELB, or if
there's anything to do to better configure HAProxy. As far as I can see
in the logs, some hosts are able to connect successfully sometimes, and
with errors other times. Hosts that have errors tend to have more errors
than successful requests. Also, almost of the devices accessing this
service are Android and iOS devices.
I'm using a free StartSSL certificate.
I've posted the relevant haproxy.cfg lines below. Any ideas are extremly
welcome!
defaults
option accept-invalid-http-request
option httplog
log global
mode http
option http-server-close
option redispatch
timeout connect 60000ms
timeout client 60000ms
timeout server 60000ms
frontend www_secure
mode http
bind 0.0.0.0:443 ssl crt CERTNAME1.pem crt CERTNAME2.pem
(acl's directing traffic to 2 backends)
