summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls1.h
diff options
context:
space:
mode:
authortb <>2021-09-10 09:25:29 +0000
committertb <>2021-09-10 09:25:29 +0000
commit47a94cad06ffc8bf1c64c7870f0dc905ed8485e4 (patch)
tree2fcdf6ff9ae24aab6ae8fc69b1f46e80b647dd92 /src/lib/libssl/tls1.h
parentd17eb2a4cbcb7c76bb5dd38f9d1c26044d64118f (diff)
downloadopenbsd-47a94cad06ffc8bf1c64c7870f0dc905ed8485e4.tar.gz
openbsd-47a94cad06ffc8bf1c64c7870f0dc905ed8485e4.tar.bz2
openbsd-47a94cad06ffc8bf1c64c7870f0dc905ed8485e4.zip
Do not ignore SSL_TLSEXT_ERR_FATAL from the ALPN callback
As reported by Jeremy Harris, we inherited a strange behavior from OpenSSL, in that we ignore the SSL_TLSEXT_ERR_FATAL return from the ALPN callback. RFC 7301, 3.2 states: 'In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert.' Honor this requirement and succeed only on SSL_TLSEXT_ERR_{OK,NOACK} which is the current behavior of OpenSSL. The documentation change is taken from OpenSSL 1.1.1 as well. As pointed out by jsing, there is more to be fixed here: - ensure that the same protocol is selected on session resumption - should the callback be called even if no ALPN extension was sent? - ensure for TLSv1.2 and earlier that the SNI has already been processed ok beck jsing
Diffstat (limited to 'src/lib/libssl/tls1.h')
0 files changed, 0 insertions, 0 deletions