Support ALPN negotiation

[Lukasa]

I'd like to do ALPN to negotiate HTTP/2 like basically everyone else does, but I can't because the standard library doesn't support it.

PyOpenSSL might be my best bet here.

[Lukasa]

Hmm, PyOpenSSL doesn't even support NPN, let alone ALPN. Maybe worth an enhancement?

[radix]

I filed this: pyca/pyopenssl#79

[Lukasa]

Excellent! Thanks for that! I'll see how hard it's likely to be to implement this in PyOpenSSL. =)

[alekstorm]

I'm not sure how much this helps, but I've forked the Python 2.7.6 ssl module as ssl2 and backported NPN support from 3.3. It is likely buggy, but hey, apparently hyper is too :). Let me know if you find it useful; if it gets traction, I'll certainly maintain it, and probably backport more features.

[Lukasa]

There's a crossover between this and PyOpenSSL. I prefer the interface from the stdlib's ssl module, but PyOpenSSL has the advantage of working on non-CPython interpreters. There's an open PyOpenSSL issue (pyca/pyopenssl#79) that's had some work done so far. I'm honestly not sure which is the better route to go. Thanks for the backport though! (Side note: are you aware of the draft PEP466? Might be worth letting Nick Coghlan know that you've already done some of this work. =) )

[alekstorm]

I was not aware of PEP466, and let me assure you, it's a big relief. Since the changes to be backported are evidently the entire ssl module modulo a few functions, I doubt my little ssl2 module will be much use (in particular, Python 3.4 hangs the NPN-related functionality off the new SSLContext class, which I imagine will be copied wholesale and then patched up to conform to the 2.x CPython API).

Python 3.5 is still in development, although I'm not sure if the new-feature window is still open; perhaps I'll implement ALPN support therein. In the meantime, I suppose a compatibility layer could be written that exposes PyOpenSSL as a Python 3.4 ssl-like API, along with dependency injection. I'm not sure which way to go either.

[alekstorm]

Ah, I now realize hyper only supports Python 3.3+. What are your feelings on supporting 2.7 as well?

[Lukasa]

I've had this discussion with Nick and Donald, and the basic gist is that adding ALPN in 3.5 won't get it backported to 2.7.

As for supporting 2.7, I'd like to do it, but it requires either a backport of the ssl module (aka PEP 466) or moving to PyOpenSSL (being progressed above). It also requires a bit of a rewrite, I'm depending on some fun 3.3 things.

[Lukasa]

This is no longer a WIBNI, it's mandatory, because ALPN is mandatory in the spec.

This is a gigantic pain in the ass. Some options:

• Wait for OpenSSL to support ALPN. 1.0.2 is in beta and has support, but I have no idea when it's scheduled for release. I'll then need to plumb it through cryptography and PyOpenSSL, which based on prior experience will take a few months. PyOpenSSL will then become mandatory for all currently-supported platforms. This will also require that basically everybody upgrade their copy of OpenSSL, which is going to be really painful on Windows. Maybe I bite the bullet and bundle a copy?
• Switch to GnuTLS, which appears to already contain support. I haven't found any Python bindings that support ALPN though, so I'll either have to contribute them myself or create a new set of bindings (who has the time?). I then also require that every platform download and compile the new bindings and have a copy of GnuTLS, making this even more of a pain in the ass than the OpenSSL plan.
• No idea. Seriously, these seem like the only two.

What a nightmare.

[dimaqq]

+1 for openssl. develop wth beta now, check python mailing list / issues wrt. exposing openssl features to python-land.

[public]

I'll then need to plumb it through cryptography and PyOpenSSL, which based on prior experience will take a few months.

We're planning 0.5 to be out in the next week or two so if there's any new bindings you need for ALPN now's a good time to get them in :)

This will also require that basically everybody upgrade their copy of OpenSSL, which is going to be really painful on Windows. Maybe I bite the bullet and bundle a copy?

We are ever so slowly coming round to the idea that maybe we should just statically link (or at least bundle) OpenSSL for Windows in cryptography. Seems a bit mad for you to have to do that upstream and you aren't the first downstream dependency who's faced this issue.