Intermittent SSL Handshake Errors
ericr
nginx-forum at nginx.us
Tue Feb 3 18:18:25 UTC 2015
I just finished running an experiment that has shed some light on the issue.
It has not yet been solved though.
I setup another nginx server with the same configuration with an upstream
app that always responds with HTTP 200. I included JS on each page load in
production to make a single request to this server.
I ran tcpdump on the test server and what I found was very interesting.
Client connections producing the above "inappropriate fallback" on the test
server all appear to do some form of the following:
(Client and Server successfully complete 3-way handshake)
Client: Client Hello TLSv1.2
Server: RST
Client: ACK
Server: RST
(Client and Server successfully complete 3-way handshake)
Client: Client Hello TLSv1.1
Server: RST
Client: ACK
Server: RST
(Client and Server successfully complete 3-way handshake)
Client: Client Hello TLSv1.0
Server: Encrypted Alert (Content Type: Alert (21))
(Client sends RST, which the server acknowledges, and the connection ends)
I don't know what the alert is, but I can only assume it's related to
TLS_FALLBACK_SCSV since the client closes the connection right after.
What's interesting here is that there is little consistency to these RSTs.
Sometimes a client downgrades to TSLv1.1 before getting the Encrypted Alert
(Content Type: Alert(21)). Sometimes a client tries the same version over
and over again, each time getting an RST from the server, and eventually
gives up. Later many of these IP addresses are observed establishing
successful connections.
Am I correct to assume Nginx is sending these RST packets?
Posted at Nginx Forum: http://forum.nginx.org/read.php?2,256373,256427#msg-256427
More information about the nginx
mailing list