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/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx