enforce ALPN overlap?

[Tomas Mraz]

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.]