Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement TLS-ALPN-01 challenge and standalone TLS-ALPN server #5894
Thanks for the PR @mdebski.
We'll try and fully review this in the next couple weeks, but it looks like some tests are failing when trying to use older versions of our dependencies. We unfortunately have to keep support for some pretty old packages to allow for distro packaging in places like EPEL. In particular, we need to support
As for how to accomplish this, we don't plan on using the TLS-ALPN challenge in Certbot anytime soon and I doubt other users of our ACME library are going to either. With this in mind, I think it's OK if you make the implementation of the TLS-ALPN-01 challenge pretty bare bones here. Implementing functionality similar to the other challenge types would be nice, but assuming this is pretty hard with the ancient version of
I tried working around this, but unfortunately it failed:
Anyway, how should I implement your proposal to fail alpn on old pyopenssl? Should I just make sure everything that worked before still works, and possibly raise an exception in the new stuff? What about tests? Make alpn tests conditional on version, and simply do not run them on older?
referenced this pull request
Apr 27, 2018
I think what's going on is cryptography didn't support making certs with custom extensions until cryptography 1.3. This isn't documented in their changelog, but this seems to be suggested by pyca/cryptography#2747.
I'd like to avoid bumping our cryptography requirement higher than 1.2.3 though. This is the version in Ubuntu Xenial and we've been working to get a new version of Certbot shipped there for a long time now. Getting an update to a crypto library used by many other projects is a much harder sell than just updating Certbot itself.
Pretty much. I haven't dug into it so it might already work this way, but we shouldn't raise an exception if the CA includes a TLS-SNI-01 challenge in the authorization object regardless of the version of our dependencies. Instead, I'd like us to only raise an exception when trying to perform/verify the challenge.
That works. If you're feeling ambitious, you could also add tests that mock out the libraries so the code is still tested when run with the older libraries. I don't think that's totally necessary though.
I've managed to work around missing support for custom extensions, and in fact only use pyopenssl for that. For the other problematic issue - alpn support - I just disabled the test if required feature in pyopenssl is missing.
Travis should be all green, I'd say this is fully ready now.
@sydneyli, this is a larger PR, but if you think you would have time to get to it in the next couple days, taking it would help me out. If not, I can take it.
If you decide to review it, please take care when reviewing the public interfaces added here (which we have to live with for the foreseeable future) and that we handle TLS-ALPN when run with old versions of our dependencies gracefully. You can see the discussion above about the latter.
bmw left a comment
Other than my comment about changing the parameters to
The TODO Sydney asked me to take a look at also seems fine to me. Unless I'm missing something, I think we're doing the best we can with our libraries available to us.