nginx critical error with SSL handshaking

Question

I have problem with my nginx on Ubuntu 14.04 LTS. From time to time I get a critical error:

2015/01/18 12:59:44 [crit] 1065#0: *28289 SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: 10.0.2.2, server: 0.0.0.0:443

I've checked version of my OpenSSL:

root@www:~# ldd `which nginx` | grep ssl
        libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f39e236b000)

root@www:~# strings /lib/x86_64-linux-gnu/libssl.so.1.0.0 | grep "^OpenSSL "
OpenSSL 1.0.1f 6 Jan 2014

I've searched for more information about it and found that it might be problem with old version OpenSSL. So I've tried to compile the latest version:

wget https://www.openssl.org/source/openssl-1.0.1l.tar.gz && tar xzf && cd openssl-1.0.1l

./config && make && make install

I've also replaced old OpenSSL binary file with new one via symlink:

ln -sf /usr/local/ssl/bin/openssl `which openssl`

After that I have:

root@www:~# openssl version
OpenSSL 1.0.1l 15 Jan 2015

But still I have the old version in nginx:

root@www:~# strings /lib/x86_64-linux-gnu/libssl.so.1.0.0 | grep "^OpenSSL "
OpenSSL 1.0.1f 6 Jan 2014

I couldn't find any other new libssl in Ubuntu after updating OpenSSL. How do I update libssl so that nginx could use the newest version?

P.S.1. Maybe the problem with critical error isn't about version of OpenSSL.

P.S.2. I think that this crtitical error might affect my whole Virtual Machine. I have also a problem with "from time to time" crashing of VM.

I've tried so many things and now I am hopeless. Stackoverflow please help!

Answer 1

Will it affect client send request? As my understanding, client send his first request to our server, but maybe our load balance on a high load which occurs first connection failed. And then the client try to downgrade its protocol version to retry connection,but because of our server supports TLS_FALLBACK_SCSV, it will do ssl handshake failed.

So the client will have no chance to connection our server later?

If our load balance recover its normal load, will the client has a chance to retry connection with the high protocol version successfully?

Answer 2

...BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: 10.0.2.2, server: 0.0.0.0:443

This looks like someone checking if the server supports TLS_FALLBACK_SCSV, which it does in your case. Nothing to worry about. On the contrary this means that your server supports a useful security feature. For more information about TLS_FALLBACK_SCSV and how one can detect SSL downgrade attacks like POODLE this way you might have a look at http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/.

TLS_FALLBACK_SCSV is a fairly new option intended to detect SSL downgrade attacks. It needs support on client and server. Older nginx/OpenSSL and older browsers simply did not have this option so this problem could not have been detected and thus not logged in earlier versions. This message is critical because it could indicate an actual SSL downgrade attack attempt against the client which was defeated by this option. In practice it is probably some tool probing for support of the option, like SSLLabs.

For reference the relevant code from ssl/ssl_lib.c function ssl_bytes_to_cipher_list:

/* Check for TLS_FALLBACK_SCSV */
if ((n != 3 || !p[0]) &&
        (p[n-2] == ((SSL3_CK_FALLBACK_SCSV >> 8) & 0xff)) &&
        (p[n-1] == (SSL3_CK_FALLBACK_SCSV & 0xff)))
        {
        /* The SCSV indicates that the client previously tried a higher version.
         * Fail if the current version is an unexpected downgrade. */
        if (!SSL_ctrl(s, SSL_CTRL_CHECK_PROTO_VERSION, 0, NULL))
                {
                SSLerr(SSL_F_SSL_BYTES_TO_CIPHER_LIST,SSL_R_INAPPROPRIATE_FALLBACK);
                if (s->s3)
                        ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_INAPPROPRIATE_FALLBACK);
                goto err;
                }
        p += n;
        continue;
        }