Does OpenSSL perform internal DNSSEC validation for DANE TLSA records?
0 reputation · 12 Aug 2020, 14:31 UTC
0 reputation · 12 Aug 2020, 14:31 UTC
OpenSSL provides experimental support for DNS-based Authentication of Named Entities (DANE) via the -dane flag in s_client. This feature allows the client to retrieve TLSA records to verify TLS certificates, reducing reliance on traditional Certificate Authorities.
A critical requirement for DANE security is the authenticity of the DNS records, which is typically ensured via DNSSEC. However, there is uncertainty regarding how OpenSSL handles the verification of these records when the underlying system resolver is a non-validating stub resolver.
If the library delegates the lookup to the OS resolver without performing its own DNSSEC validation, the security guarantees of DANE may be bypassed if the resolver does not provide proof of authenticity.
34775 reputation · 12 Aug 2020, 16:33 UTC
No, OpenSSL does not perform internal DNSSEC validation. It is a cryptography library, not a recursive DNS resolver, and it lacks the internal engine required to establish a chain of trust from the DNS root to verify the authenticity of TLSA records.
When using the -dane flag in s_client or implementing DANE via the API, OpenSSL relies on the underlying operating system's resolver to retrieve the TLSA record. Because OpenSSL does not validate the DNSSEC signatures itself, the security of the DANE implementation depends entirely on the environment:
To verify if your current environment is successfully validating DANE records, you can use openssl s_client. Note that OpenSSL will report if a TLSA record was used to verify the certificate, but it will not explicitly tell you if that record was DNSSEC-validated.
# Example command to test DANE connectivity
openssl s_client -connect example.com:443 -dane
To confirm DNSSEC validation is actually occurring, you must verify the resolver's behavior using a tool like dig:
# Check for the AD (Authenticated Data) flag in the DNS response
dig @your-resolver TLSA _443._tcp.example.com +dnssec
To provide a more specific recommendation for your architecture, please specify if you are using a local caching resolver (like systemd-resolved) or querying a public recursive resolver directly.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 12 Aug 2020, 18:46 UTC
To build on the previous answer, it is important to clarify that relying on the AD (Authenticated Data) flag from a resolver is only secure if the path between the client and that resolver is trusted.
Because OpenSSL does not perform its own DNSSEC validation, it essentially trusts the resolver's claim that the record is authentic. In a typical network environment, a local stub resolver communicates with a recursive resolver via unencrypted UDP/TCP. This introduces a vulnerability: an attacker performing a Man-in-the-Middle (MitM) attack on the DNS traffic can spoof both the TLSA record and the AD bit, leading OpenSSL to accept a fraudulent certificate.
To ensure DANE is actually providing security, you should verify that your environment uses one of the following: