Security measures during initial validation

[LoSc]

Hi all,

as part of a research project for an academic conference paper we are currently assessing security properties of various CAs during domain validation. We previously contacted Let’s Encrypt’s security team with our findings and have been redirected here for a public discussion.

Our threat model assumes an attacker with man-in-the-middle capabilities between the CA and the domain owner’s infrastructure. The attacker initiates the certificate issuing process and spoofs domain validation requests. It corresponds to the “active attacker on the validation channel” discussed in the security considerations of draft-ietf-acme-acme-12.

For Let’s Encrypt we performed domain validation via HTTP, DNS (both in Oct. 2017) and TLS-SNI (Nov. 2017) for a dedicated DNSSEC-enabled domain and analyzed the resulting traffic.

We observed all DNS queries to be secured by DNSSEC (DNSSEC OK flag and an associated DNSKEY query) and therefore to be secure against a network level attacker.

For challenges relying also on an application level protocols (i.e. HTTP and TLS-SNI) we didn’t observe countermeasures suited to mitigate such an attacker. Plain HTTP allows an attacker to inject the token in the TCP stream and the self-signed certificate required for TLS-SNI can be created by the attacker if he is identical to the ACME client.

For both affected validation methods we suggest to use DANE to prevent this kind of attack. Before a TLS-SNI validation takes place, DANE records should be queried and checked accordingly. HTTP-based validation should take place via HTTPS with the same DANE checks. HTTP should only be used if prior HTTPS validation failed (i.e. due to operational reasons) and there is no DANE-indication of HTTPS support.

These approaches prevent this attack for security aware domain owners while still maintaining compatibility with users not willing or able to deploy additional DNS records.
For these users, we share draft-12’s recommendation of performing requests (DNS/HTTP/TLS) from multiple vantage points to mitigate this attack.

We understand that in the meantime TLS-SNI has been deprecated in favor of TLS-ALPN. However, this change doesn’t address the man-in-the-middle vulnerability which causes TLS-ALPN to be affected as well.

[cpu]

Hi @LoSc, thanks for taking the time to evaluate ACME and Let's Encrypt. We appreciate it!

@LoSc

as part of a research project for an academic conference paper we are currently assessing security properties of various CAs during domain validation.

Please let us know when you have a draft of your paper

@LoSc

we didn’t observe countermeasures suited to mitigate such an attacker.

As you noted, your attacker/threat model corresponds to the ACME protocol's threat model for the "active attacker on the validation channel" case.

Knowing that, Section 10.2 of the ACME security considerations specifically says:

An active attacker on the validation channel can subvert the ACME process, by performing normal ACME transactions and providing a validation response for his own account key.

You are not seeing countermeasures because the security properties of ACME have never made any guarantees against protection for this attacker in the ACME threat model.

If you start with a different threat model than the one defined in the protocol you are investigating you will certainly find discrepancies. I would definitely encourage you to operate under the well defined threat model from the specification and be explicit when you are giving your adversary powers that are beyond those the protocol intends to address (as in this case).

@LoSc

HTTP-based validation should take place via HTTP S with the same DANE checks. HTTP should only be used if prior HTTP S validation failed (i.e. due to operational reasons) and there is no DANE-indication of HTTPS support.

I don't think this recommendation is practical. Focusing on just the HTTPS portion of your recommendation I have to note that the HTTP-01 challenge is required to use HTTP not HTTPS for the explicit reason mentioned in Section 8.3:

Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.

There is also fairly substantial discussion of this in the ACME working group mailing list history. How does your suggestion interplay with the 'default SNI' attack that was the basis of requiring HTTP-01 operate on port :80 instead of :443? It seems at face value that recommending this would address one problem while re-introducing another.

@LoSc

These approaches prevent this attack for security aware domain owners while still maintaining compatibility with users not willing or able to deploy additional DNS records.

If users are not willing or able to deploy additional DNS records why would they be willing or able to deploy DANE? Oops! I misunderstood. You're intending this DANE approach be used by "security conscious users" while maintaining compatibility with users that don't want to/can't deploy additional DNS records. My apologies for misunderstanding.

For this case, would it be fair to say a simpler solution for security power users would be to deploy ACME-CAA records specifying validationmethods=dns-01 and pinning to a specific ACME account ID with a accounturi restriction? (note: this is of course presently only possible in the staging environment)

@LoSc

For these users, we share draft-12’s recommendation of performing requests (DNS/HTTP/TLS) from multiple vantage points to mitigate this attack.

Great! Glad to hear that your team agrees that the on-going work in this area will be helpful.

@LoSc

However, this change doesn’t address the man-in-the-middle vulnerability which causes TLS-ALPN to be affected as well.

That's correct. TLS-ALPN-01 wasn't meant to address this vulnerability because it is outside of the ACME threat model. The protocol acknowledges an active man-in-the-middle attacker on the validation channel is able to subvert the authorization process.

I hope that helps clarify our stance. Thanks again!

[LoSc]

Thank you for your comprehensive answer, @cpu!

@cpu

Please let us know when you have a draft of your paper

Sure, I will provide a draft once it is available.

@cpu

You are not seeing countermeasures because the security properties of ACME have never made any guarantees against protection for this attacker in the ACME threat model.

Of course, our threat models differ. Sorry if I didn't make that clear. We based our study on the question what a rogue ISP or state-level attacker has to do to pass domain validation challenges. To be able to compare results we applied the same model to all CAs.

@cpu

For this case, would it be fair to say a simpler solution for security power users would be to deploy ACME-CAA records specifying validationmethods=dns-01 and pinning to a specific ACME account ID with a accounturi restriction?

Yes, definitely! Even pinning the validation method alone should be enough to prevent this kind of attack as all data is DNSSEC protected. Thank you for pointing out the current Let's Encrypt deployment state, we will consider this

@cpu

How does your suggestion interplay with the ‘default SNI’ attack that was the basis of requiring HTTP-01 operate on port :80 instead of :443?

That's a valid point, default SNI configurations were not part of our threat model. Checking DANE records first and making a decision for HTTP or HTTPS based upon this would take this into account. However, if Let's Encrypt is currently pursuing the CAA/validationmethods approach there is no need for this - admittedly - more complex solution.

Thanks again for your reply and for providing this great service to the public