We’ve run into an issue with the ALPN and SNI TLS extension callbacks in 1.0.2.
The same behavior may be in master, but I have yet to check.
In summary, the ALPN selection callback is invoked before the SNI/servername
callback, yet the ALPN value returned may be dependent on the server being
connected to. In other words, ALPN may be broken for virtual servers.
There’s a comment in ssl_parse_clienthello_tlsext() that clearly states:
/*
* Internally supported extensions are parsed first so SNI can be handled
* before custom extensions. An application processing SNI will typically
* switch the parent context using SSL_set_SSL_CTX and custom extensions
* need to be handled by the new SSL_CTX structure.
*/
There are 4 functions that handle TLS extensions, and are invoked in the
following order
ssl_scan_clienthello_tlsext()
* saves servername
* saves ec_point_formats
* saves elliptic_curve list
* saves opaque PRF input
* calls session ticket callback
* saves status request
* saves heartbeat
* notes NPN seen
* calls ALPN callback
ssl_check_clienthello_tlsext_early()
* calls servername callback
* calls PRF callback
ssl_scan_clienthello_custom_tlsext()
* parses custom extensions
ssl_check_clienthello_tlsext_late()
* calls status callback
I would argue that ALPN data should be saved in ssl_scan_clienthello_tlsext()
and processed in ssl_check_clienthello_tlsext_early() - after the servername
callback
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
