My earlier replies to this thread were pretty terse, so just to expand on it:
> On Jul 13, 2016, at 3:39 AM, Cory Benfield <c...@lukasa.co.uk> wrote: > > >> On 13 Jul 2016, at 10:00, Paweł Miech <pawel...@gmail.com >> <mailto:pawel...@gmail.com>> wrote: >> >> > Anyway, I’ll be spending my Twisted time on this for a while I suspect. >> > This will delay HTTP/2 client support, unfortunately. =( >> >> Isn't it better to get HTTP2 client support and just document things better >> for HTTP2? Or maybe even backport some features from CertificateOptions to >> factory? DefaultSSLContextFactory seems to work ok for cases outside HTTP2. It really doesn't. >> It is not evidently broken. For clients, it's horribly broken and provides no security whatsoever. For servers, it's badly configured enough that you will have problems with SSLLabs and other automated testing things. >> It is probably less secure than twisted.internet.ssl.CertificateOptions but >> is really broken beyond repair? Yes, it really is. The only reason we didn't just delete it immediately in a compatibility-breaking exception is that if you knew what you were doing, it was the only way to reasonably be secure in the past, and we did not want to punish those users who had done the best they could with what Twisted was giving them. It was possible to make something secure with it, if you absolutely knew what you were doing and you layered a bunch of things on top of it. > Generally speaking I’d say it isn’t better, for a couple of reasons. > > Firstly, it rarely works well to document one’s way out of a usability > problem. This is doubly-true when the *rest* of the documentation is contrary > to what your new documentation would say. For example, the Twisted Web howto > client documentation uses ClientContextFactory, which will be utterly > unsuitable for HTTP/2. Not to mention the fact that it provides no security. Client-side, anything other than optionsForClientTLS is probably completely unacceptable. Again… it was possible to add your own security to ClientContextFactory but that is the only reason we didn't delet it. > More generally, having two different ways to do TLS, one of which is > substantially less secure and powerful than the other, is a real problem. For > example, DefaultSSLContextFactory literally only works for HTTP/2 servers by > chance: it was never actually *designed* to work with ALPN and only managed > to do so because we refactored the implementation to have the > TLSMemoryBIOFactory apply the ALPN/NPN logic. In essence, by sheer bad luck > we managed to change the HTTP/2 implementation to accidentally work with the > old method, when it was never planned to do so. In fairness, the fact that random accidents like this happen is as much a fault of OpenSSL's ... idiosyncratic, shall we say, API, where promiscuous mutable data sharing is completely the norm, as it is a fault of Twisted's bad early misinterpretation of said API. > Worse, though, is that while the ContextFactory isn’t that bad for servers, > it’s *terrible* for clients. In particular, the ClientContextFactory does not > use SNI, does not validate hostnames, and generally speaking does not produce > secure TLS. That means I’d want to prevent the HTTP/2 client from using the > ClientContextFactory *anyway*: it’s really genuinely terrible and needs to be > burned with fire. TERRIBLE TERRIBLE TERRIBLE FOR CLIENTS DON'T USE IT > If you’re interested in speeding up the arrival of HTTP/2 client support, > then, the best way to do that is to help out with the deprecation effort. > I’ve got patches open for the majority of the docs problems, and will be > starting to work on the code problems over the next few days. All of these > patches will require review, and other people writing patches will also speed > things up. +1000 thank you for saying this. > Basically, I’m disinclined to want to prolong the lifetime of something that > was supposed to go away two years ago. Twisted has a lot of things in it that > were *supposed* to be deprecated but were never *actually* deprecated, and > that kind of soft deprecation ends up causing the kind of problem we’ve > bumped into here, whereby a lot of people have code that “works” with current > features, but new features are designed only with an eye to the best > practice. On a personal level, I want to push for Twisted to *actually* > deprecate things that are soft deprecated. That has the best long-term effect > on the project, by reducing the amount of code that needs to be maintained > and encouraging users to move towards features that function better. Basically I just wanted to chime in to make it clear that I _absolutely_ agree with _every_ part of this and we should _immediately_ move to implement all of these plans. Cory, I also really appreciate you going through and taking the time to clear up the messaging around these APIs in our documentation and our implementations to help users understand what's going on so you don't need to be a member of the Twisted cabal to get good security and modern protocol features. Thanks, -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
