On 11 Jul 2016, at 22:04, Paweł Miech <pawelmhm@gmail.com> wrote:

This seems to suggest that Ubuntu 16.04 (the system I'm testing) does not support ciphers required by HTTP2. But nginx article about HTTP2 lists ubuntu as only linux like system that is able to support HTTP2 over ALPN which is required by Chrome: https://www.nginx.com/blog/supporting-http2-google-chrome-users/

Sorry. To be clear, I was not responding to your specific needs but discussing Glyph’s wider point about alerting when bad configuration is present.

I decided to verify tnginx statements and I tried to set up nginx with HTTP2 on ubuntu 16.04. It turns out this is possible and it works ok. I just followed this article here: https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-with-http-2-support-on-ubuntu-16-04 This means that in principle Ubuntu 16.04 should be able to support HTTP2 and it has required TLS ciphers. 

So the problem here is not about lack of OS support.

Looking into this nginx article they recommend two things that are part of manual setup which (maybe?) are required?

1) They say ciphers should be set to ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; 

This long string does not mean much to me, but reading email from Amber again I see it differs slightly from what she says Twisted uses. But one thing I'm wondering about is how do you guys know which ciphers are set in Twisted? Looking into source code of DefaultOpenSSLContextFactory I see context is created here: https://github.com/twisted/twisted/blob/3455a902fb15e732ee43b59f4d82a66b105351ba/twisted/internet/ssl.py#L107 I dont see any point where there is a call that sets ciphers. Maybe this is done somewhere else? I tried grepping source for string mentioned by Amber but cant find it. 

Ok, this is your problem.

DefaultOpenSSLContextFactory should have been deprecated a long time ago. It’s insecure, and in particular does not set a cipher string, so it uses DEFAULT. That will have all kinds of messed up priorities. For that reason, you should adjust your code to use OpenSSLCertificateOptions or, even better, use the TLS endpoint directly.

The TL;DR is: yes, it seems that DefaultOpenSSLContextFactory produces a context that is genuinely unacceptable for HTTP/2.