id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	uname	nginx_version
1714	Server Name Indication (SNI) in NGINX isn't honoring ssl_protocols, ssl_ciphers etc. per server{} config / TLS downgrade and server exhaustion attack.	fortresslinux@…		"== SNI bug: ==

Reproduce: Configure nginx (partly) as:

{{{
server {
    listen 443 ssl http2 default_server;
    ssl_protocols TLSv1.3;
    ssl_ciphers 'TLS_CHACHA20_POLY1305_SHA256';

...

server {
    listen 192.168.66.1:443 ssl http2;
    ssl_protocols TLSv1;
    ssl_ciphers 'DHE-RSA-AES256-SHA';
    server_name www.example.org;
}}}

Test command:

{{{
openssl s_client -servername www.example.org -connect thisserver.com:443
}}}

It should honor the second server ssl_ciphers and ssl_protocols (and more) in SNI, but it uses ssl_ciphers and ssl_protocols (and more) from the first default_server. It sends the right certs though.

Cross-site TLS downgrade is possible in this way too (exchange the two example servers ssl_ciphers and ssl_protocols). And/or it makes the server no-op for older/newer clients.


== TLS server exhaustion attack: ==

NGINX sends a 'server hello + cert + server hello done' after every initial 'client hello + SNI servername'. No matter if the SNI host in the client hello exists on the server or not. With some scripting and fake SNI servername generating, it is easily possible to exhaust all available connections or the server itself... completely.

We recommended to introduce the possibility in NGINX to respond with a code 444; when requesting non-existing SNI hosts/servernames without requiring (or sending) any certs, ciphers, protocols in the (possible catchall) default_server configuration.

Kind regards,

The Fortress Linux Security Team."	defect	closed	critical		nginx-core	1.14.x	duplicate	Server Name Indication SNI TLS downgrade exhaustion attack		"Fortress Linux 4.14.94 #1 SMP Wed Jan 25 12:56:18 UTC 2019 aarch64 GNU/Linux
"	"nginx/1.14.2
"