> On Jul 11, 2016, at 3:35 AM, Cory Benfield <c...@lukasa.co.uk > <mailto:c...@lukasa.co.uk>> wrote: > >> >> On 11 Jul 2016, at 01:45, Glyph Lefkowitz <gl...@twistedmatrix.com >> <mailto:gl...@twistedmatrix.com>> wrote: >> >> >>> On Jul 9, 2016, at 10:30 AM, Paweł Miech <pawel...@gmail.com >>> <mailto:pawel...@gmail.com>> wrote: >>> >>> 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. -glyph
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
