My question is: should user deal with this kind of stuff themselves? If some ciphers are blacklisted in HTTP2 shouldn't this be handled somewhere in Twisted?
As others have already said, this should work out of the box, and I'm not sure why it isn't for you, especially that you've gone to the extra trouble of building a Docker image and retrieving recent enough versions of every relevant layer of the stack.
However, to answer this question generally: this should absolutely be handled by Twisted. In fact, even if we're doing the right thing already except in your one configuration, we should go a step beyond and provide tooling and logging to clearly explain to system operators why they won't get HTTP/2 if their dependencies are out of date.
This turns out to be trickier than you’d expect.
PyOpenSSL does not expose any of the APIs for us to programmatically detect what ciphers are available to the OpenSSL we have installed. Cryptography exposes only one: SSL_get_ciphers. This is not really the one we want, because it lists all *possible* ciphers, rather than the ones that are actually enabled for a given connection. This makes it very difficult for us to conclude that we’d want to use HTTP/2 but we cannot because of a lack of cipher support.
So pyOpenSSL/Cryptography doesn't have SSL_get_current_cipher anywhere?
Now, Twisted *could* add code to introspect the HTTP/2 TLS configuration and optionally terminate the connection in the same manner that Chrome does. Currently I’ve not done that because it’s not been hugely needed, but we could do that. The reality is, though, that Twisted can’t unconditionally not use those ciphers because it needs to support HTTP/1.1 as well as HTTP/2, and HTTP/1.1 does not have those same restrictions.
The main interest I think we have is to placate Chrome, to ensure it can speak HTTP/2 if it's possible, and to explain why it's not possible, if it's not.
What would be looking for here? Out of the box, Twisted should do the very best it can, but right now it seems like the only thing we could do is detect when HTTP/2 is literally impossible to support (e.g. when there is no TLS 1.2 support). With that said, those versions *completely* overlap with the versions where OpenSSL doesn’t support ALPN.
In the same way that we complain about service_identity perhaps we should complain about OpenSSL?
Regardless, Twisted’s default cipher ordering is appropriate for HTTP/2 (it prefers ECDHE AES GCM, which is what is required). So I’m not sure what more we could do.
Yeah, I'm curious why the OP was having this problem.