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
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
