Nginx critical error with SSL handshake

Question

I have a 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 checked the 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 searched for more information about this and found that this could be a problem with the old version of OpenSSL. So I 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 also replaced the old OpenSSL binary with a new one using a 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 I have an 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 could not find any other new libssl in Ubuntu after updating OpenSSL. How to upgrade libssl so that nginx can use the latest version?

PS1 Perhaps the critical error issue is not related to the OpenSSL version.

PS2. I think this critical error can affect my entire virtual machine. I also have a problem with the "occasionally" crashing VM.

I have tried so many things and now I am hopeless. Stackoverflow, please help!

Answer 1

... BYTES_TO_CIPHER_LIST: improper reserve), and SSL-acknowledgment, client: 10.0.2.2, server: 0.0.0.0-00-0043

It looks like someone is checking to see 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 to detect SSL lower attacks, such as POODLE , you can take a look at http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/ .

TLS_FALLBACK_SCSV is a fairly new option designed to detect SSL-lowering attacks. It needs support on the client and server. Old Nginx / OpenSSL and old browsers simply did not have this feature, so this problem could not be detected and thus was not registered in earlier versions. This message is critical because it may indicate an actual attempt to attack an SSL failure against a client that was defeated by this option. In practice, this is probably a tool to support options, such as SSLLabs .

For reference, the corresponding code from ssl / ssl_lib.c: 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; } 

Answer 2

Will this affect the client’s dispatch request? As I understand it, the client sends its first request to our server, but perhaps our load balance at high load, which occurs with the first connection, failed. And then the client will try to downgrade the protocol version to reconnect, but due to the fact that our server supports TLS_FALLBACK_SCSV, this will cause the ssl handshake to fail.

So, the client will not have a chance to connect our server later?

If our load balance restores normal load, will the client have the opportunity to reconnect to the high protocol version?