Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert "Implement TLS-ALPN-01 challenge and standalone TLS-ALPN server (#5894)" #6100

Merged
merged 1 commit into from
Jun 13, 2018

Conversation

bmw
Copy link
Member

@bmw bmw commented Jun 13, 2018

This reverts commit 15f1405.

This was a clean revert with no conflicts.

The reason we're reverting this is in some versions of openssl, we're hitting issues where the challenge cert is used even if the CA requests the wrong protocol through ALPN. This is on top of the issues we were already aware of with using the challenge cert if ALPN isn't used. Since we can't provide a correct implementation and its only purpose is to help boulder with their testing, let's rip it out and have boulder implement the code for their tests.

@bmw bmw requested a review from ohemorange June 13, 2018 00:06
@bmw bmw added this to the 0.25.1 milestone Jun 13, 2018
@bmw bmw merged commit cf3568f into 0.25.x Jun 13, 2018
@bmw bmw deleted the no-alpn branch June 13, 2018 00:37
felixfontein added a commit to felixfontein/ansible-acme-test that referenced this pull request Jun 30, 2018
References:
 - ansible/ansible#41435
 - https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-01

I copied (and modified) code from Certbot's ACME library
(https://github.com/certbot/certbot/tree/master/acme)
since it is about to be removed (see
certbot/certbot#6100 and
certbot/certbot#6144). The code for
this is separated into acme_tlsalpn.py and comes with its
own license (Apache v2).
bmw pushed a commit that referenced this pull request Mar 12, 2020
This PR is the first part of work described in #6724.

It reintroduces the tls-alpn-01 challenge in `acme` module, that was introduced by #5894 and reverted by #6100. The reason it was removed in the past is because some tests showed that with `1.0.2` branch of OpenSSL, the self-signed certificate containing the authorization key is sent to the requester even if the ALPN protocol `acme-tls/1` was not declared as supported by the requester during the TLS handshake.

However recent discussions lead to the conclusion that this behavior was not a security issue, because first it is coherent with the behavior with servers that do not support ALPN at all, and second it cannot make a tls-alpn-01 challenge be validated in this kind of corner case.

On top of the original modifications given by #5894, I merged the code to be up-to-date with our `master`, and fixed tests to match recent evolution about not displaying the `keyAuthorization` in the deserialized JSON form of an ACME challenge.

I also move the logic to verify if ALPN is available on the current system, and so that the tls-alpn-01 challenge can be used, to a dedicated static function `is_available` in `acme.challenge.TLSALPN01`. This function is used in the related tests to skip them, and will be used in the future from Certbot plugins to trigger or not the logic related to tls-alpn-01, depending on the OpenSSL version available to Python.

* Reimplement TLS-ALPN-01 challenge and standalone TLS-ALPN server from #5894.

* Setup a class method to check if tls-alpn-01 is supported.

* Add potential missing parameter in validation for tls-alpn

* Improve comments

* Make a class private

* Handle old versions of openssl that do not terminate the handshake when they should do.

* Add changelog

* Explicitly close the TLS connection by the book.

* Remove unused exception

* Fix lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants