Intermittent SSL Handshake Errors

[Maxim Dounin]

Hello!

On Fri, Mar 20, 2015 at 02:15:42PM -0400, tempspace wrote:

> I had to start looking at this issue again now that yet another openssl
> security issue. Now that I know I can go back to a working setup just by
> downgrading SSL, I am able to gather more information.
> 
> This morning, I updated the libssl libraries and restarted nginx, and the
> errors started flooding back. This time, I took a packet capture to see what
> was happening and what I could correlate.  I run a set of servers that
> handle API requests from a mobile phone application, and every single client
> that produced this error was running iOS.
> 
> In the packet capture, we offer the same cipher that the clients always use
> without a problem, but for some reason, some of our iPhone clients have
> issues (not all.) I have been unable to discern a pattern, but it's always
> iPhones and doesn't seem to have anything to do with the device model or the
> OS version. I haven't found a single Android instance of the IP's that show
> up in our error logs, and we have slightly more Android devices than iOS
> devices.
> 
> We get the Client Hello which has a list of 37 potential ciphers for TLS
> 1.2. We send the server hello and offer the normal cipher. The client,
> instead of continuing on, immediately sends a FIN, ACK. It then tries to
> connect again over TLS 1.0, gives the client hello, we send the ACK and
> almost immediately, WE send a FIN, ACK to the client.

So it looks like th fallback prevention part looks like it should - 
the inappropriate fallback is prevented.  The question now is why 
fallback happens at all, that is - why the client sends a FIN.  It 
might be some specific cipher which causes the problem - you may 
try switching ssl_prefer_server_ciphers to off (the default) to 
see if it helps, and/or playing with ciphers supported (again, 
default will be a good starting point).

-- 
Maxim Dounin
http://nginx.org/