[openssl-dev] [openssl.org #4388] [PATCH] Don't be sensitive to the order of ALPN and NPN.

[David Benjamin via RT]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Don-t-be-sensitive-to-the-order-of-ALPN-and-NPN.patch
Type: application/octet-stream
Size: 1391 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160307/bbffa9db/attachment.obj>