Score:0

Questions about NGINX config after upgrade, TLSv1.2 TLSv1.3, etc. proxy config, getting SSL_do_handshake() failed, failed

cn flag

I recently upgraded a DOCKER container running NGINX to use the NGINX repo at nginx.org instead of the Debian distro version, and for security purposes we are making some adjustments to the server config regarding SSL/TLS, etc. When I scan one of the server domains with a Qualsys ? scan it actually gets an A, but fails for some of the older browsers. Looking at the Log file, I am actually seeing errors mostly like this:

2022/05/28 02:41:14 [info] 24#24: *12871 SSL_do_handshake() failed (SSL: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher) while SSL handshaking, client: 192.168.1.1, server: 0.0.0.0:443
2022/05/28 02:41:28 [info] 24#24: *12874 SSL_do_handshake() failed (SSL: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol) while SSL handshaking, client: 192.168.1.1, server: 0.0.0.0:443
2022/05/28 02:41:38 [info] 24#24: *12877 SSL_do_handshake() failed (SSL: error:142090C1:SSL routines:tls_early_post_process_client_hello:no shared cipher) while SSL handshaking, client: 192.168.1.1, server: 0.0.0.0:443
2022/05/28 02:41:39 [crit] 24#24: *12878 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 192.168.1.1, server: 0.0.0.0:443
2022/05/28 02:41:43 [info] 24#24: *12869 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking, client: 192.168.1.1, server: 0.0.0.0:443
2022/05/28 02:41:43 [info] 24#24: *12872 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking, client: 192.168.1.1, server: 0.0.0.0:443

In the HTTP block, not in the server blocks, I have something like this, and I tried a few different setting for ciphers, etc. I am not an expert, but I presume those errors are related somewhat to that configuration. I actually am not seeing any errors on my dev server, just in production at this point, but the server seems to be still working, except for a 502 error a couple of days ago.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256-CBC:ECDH+AES128-CBC:DH+3DES:!ADH:!AECDH:!MD5:!kDHE; # !kDHE disables disable DHE key exchange
#  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

There are a few other errors that might just be warnings, e.g.

2022/05/28 13:43:36 [warn] 24#24: *13173 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/4/00/0000000004 while reading upstream

Just looking for some pointers on how to resolve that issue. The NGINX version is 1.22.0 built directly from nginx.org.

Steffen Ullrich avatar
se flag
The scan by Qualsys will cause lots of errors in the log files by design since it tries different client side TLS settings to figure out if they succeed or not and thus derive information about the server. So no worry about all these handshake errors unless these are in the context of a real client which you need to have working. In other words: I cannot see an actual production problem here.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.