Move ALPN handling from finalizer to delayed call
authorBenjamin Kaduk <bkaduk@akamai.com>
Tue, 1 Aug 2017 19:50:22 +0000 (14:50 -0500)
committerBenjamin Kaduk <kaduk@mit.edu>
Tue, 15 Aug 2017 15:52:21 +0000 (10:52 -0500)
commit5626f634c31cfde48ccbbee243be29e0eb77171e
treeb0828a3ee9c94307d96504856836cb962b6a18a0
parent12997aa984cf0e5def1045fd22d7b0675caaa0a1
Move ALPN handling from finalizer to delayed call

Commit 02f0274e8c0596dcf7e2d104250232a42c650b96 moved ALPN processing
into an extension finalization function, as the only documented ordering
requirement from previous commits was that ALPN processing occur after
SNI processing, and SNI processing is performed before the extension
finalization step.  However, it is useful for applications'
alpn_select callbacks to run after ciphersuite selection as well -- at
least one application protocol specification (HTTP/2) imposes restrictions
on which ciphersuites are usable with that protocol.  Since it is generally
more preferrable to have a successful TLS connection with a default application
protocol than to fail the TLS connection and not be able to have the preferred
application protocol, it is good to give the alpn_select callback information
about the ciphersuite to be used, so that appropriate restrctions can be
enforced in application code.

Accordingly, split the ALPN handling out into a separate tls_handl_alpn()
function akin to tls_handle_status_request(), called from
tls_post_process_client_hello().  This is an alternative to resuscitating
ssl_check_clienthello_tlsext_late(), something of an awkwward name itself.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4070)
ssl/statem/extensions.c
ssl/statem/statem_srvr.c