nginx skips SNI when determining protocols for SSL negotiation

[mqudsi.neosmart.net@…]

aka "unexpected downgrade of SSL protocol vulnerability when using SNI"

The nginx documentation for ssl_protocols is pretty clear:

Context: http, server

Given a (partial) sample nginx configuration like this:

http {

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

#Default server for port 443 only to handle clients that don't do SNI (and, by extension, SHA2)
server {

listen 443 default_server ssl;
server_name _;

ssl_protocols SSLv3;
ssl_certificate /var/data/ssl/selfsigned.crt;
ssl_certificate_key /var/data/ssl/selfsigned.key;

}

server {

listen 443 ssl;
server_name example.com;

ssl_certificate /var/data/ssl/example.com.crt;
ssl_certificate_key /var/data/ssl/example.com.key;

}

}

What should happen:

A CLIENTHELLO with an SNI server_name extension field with value "example.com" should be able to negotiate SSL via the TLSv1/1.1/1.2 protocol, while a client that does not use SNI should wind up with the SSLv3-only

What actually happens:

A CLIENTHELLO with an SNI server_name extension field with value "example.com" attempting to negotiate a TLSv1 handshake will fail:

$ openssl s_client -msg -servername example.com -connect example.com:443 -tls1
CONNECTED(00000003)

TLS 1.0 Handshake [length 0074], ClientHello

01 00 00 70 03 01 56 aa d1 b4 d3 17 53 bb 1a bc
1f aa 50 0c a0 c4 66 11 fb 54 5f d1 7a af b2 8b
46 bf 39 a0 bc 2c 00 00 2e 00 39 00 38 00 35 00
16 00 13 00 0a 00 33 00 32 00 2f 00 9a 00 99 00
96 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00
08 00 06 00 03 00 ff 01 00 00 19 00 00 00 11 00
0f 00 00 0c 6e 65 6f 73 6d 61 72 74 2e 6e 65 74
00 23 00 00

SSL 3.0 Alert [length 0002], fatal handshake_failure

02 28

21033:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_pkt.c:300:

[Maxim Dounin]

How nginx works is somewhat different. When connection is initially handled, it is handled in the context of default server for the listen socket in question. As in this server protocols are restricted to SSLv3 only, SNI can't be used - as it's not available with SSLv3.

See ​Name-based HTTPS servers for some additional information.

[mqudsi.neosmart.net@…]

May I propose that in this case the bug be re-opened as a defect in the documentation, as the actual behavior is not entirely in agreement with the documentation?