summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls13_lib.c
diff options
context:
space:
mode:
authortb <>2021-09-10 09:25:29 +0000
committertb <>2021-09-10 09:25:29 +0000
commitc9e7d5c2a853445ab5e839eb581700a7def5be3b (patch)
tree2fcdf6ff9ae24aab6ae8fc69b1f46e80b647dd92 /src/lib/libssl/tls13_lib.c
parent94aeb3e2fd2aa6f535f045b0ee734b5d1742522f (diff)
downloadopenbsd-c9e7d5c2a853445ab5e839eb581700a7def5be3b.tar.gz
openbsd-c9e7d5c2a853445ab5e839eb581700a7def5be3b.tar.bz2
openbsd-c9e7d5c2a853445ab5e839eb581700a7def5be3b.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/tls13_lib.c')
0 files changed, 0 insertions, 0 deletions