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.