If the server consumer configures NPN and not ALPN, OpenSSL should still
resolve NPN against clients which advertises it. (NB: Chrome will be
removing NPN soon, so hopefully there won't be any such consumers.) Losing
the alpn_select_cb check makes OpenSSL depend on whether ALPN or NPN comes
first in the ClientHello.

If NPN comes first, it will set next_proto_neg_seen but then the ALPN logic
will unset next_proto_neg_seen even though tls1_alpn_handle_client_hello
won't do anything. If ALPN comes first, it works.

This check used to be there, but got lost in
062178678f5374b09f00d70796f6e692e8775aca.

The NPN-Server-Sync test in BoringSSL's test suite can be used to repro
this:
https://mta.openssl.org/pipermail/openssl-dev/2016-March/005779.html
(Although I didn't actually add a test for this ordering issue explicitly.
This was found on accident because the order our Go code happened to put
ALPN and NPN in.)

David

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4388
Please log in as guest with password guest if prompted

Attachment: 0002-Don-t-be-sensitive-to-the-order-of-ALPN-and-NPN.patch
Description: Binary data

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to