On Wed, 2021-06-09 at 12:32 -0400, Jan Schaumann via openssl-users wrote: > Hello, > > Based on https://alpaca-attack.com/, I was looking at > how a TLS connection with ALPN set to e.g., "banana" > by the client to a server that has ALPN set to "h2" > would behave. For example: > > $ openssl s_server -www -accept 443 -alpn h2 \ > -key /tmp/key.pem -cert /tmp/cert.pem > > and > > $ openssl s_client -connect localhost:443 -alpn banana > > It seems that OpenSSL will simply not negotiate ALPN, > but leave the connection open: > > [...] > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 > Server public key is 2048 bit > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > Early data was not sent > [...] > --- > read R BLOCK > > In Go, a recent commit changed their behavior to > enforce ALPN overlap: > https://github.com/golang/go/commit/90d6bbbe42c15d444c1da0a1c293192d6f735a8e > > > Is there any plan or consideration to follow that > approach? The OpenSSL library allows the alpn application callback to decide. Please see https://github.com/openssl/openssl/issues/2708 Also in the master branch the callback in the s_server application is already changed to reject the connection in such case. https://github.com/openssl/openssl/pull/11415 But even in 1.1.1 this is very well possible in 3rd party servers. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
