It is quite common that organizations use some kind of TLS decryption to have a look at the client traffic in order to protect against malware or evasion. (Some synonyms are SSL/TLS interception, decryption, visibility, man-in-the-middle, …) Next-generation firewalls as well as proxies implement such techniques, e.g., Palo Alto Networks or Blue Coat. To omit the certificate warnings by the clients, all spoofed certificates are signed by an internal root CA that is known to all internal clients. For example, the root CA is published via group policies to all end nodes.
But what happens if the DNS-based Authentication of Named Entities (DANE) is widely used within browsers? From the CA perspective, the spoofed certificates are valid, but not from the DANE perspective. To my mind we need something like an on-the-fly TLSA record spoofing technique that works in conjunction with TLS decryption.
I won’t discuss the pros and cons of TLS decryption here. I want to deal with the fact that some customers heavily rely on such features. Actually, we do not have a problem these days, since neither DNSSEC validation nor DANE within browsers is widely used.[Note that we also have a similar problem with Public Key Pinning Extension for HTTP (HPKP, RFC 7469, Wikipedia) if TLS decryption is used. If so, the browser knows which certificate to expect and will not connect to a specific site if the certificate is exchanged by an intermediate device.]
But what are appropriate solutions if one day DNSSEC validation at the internal DNS servers, as well as DANE validation within the web browsers is used anywhere? With only DNSSEC we won’t have any problems because the clients are still connecting to the correct IP addresses. But DANE will (correctly) interrupt the connection to the HTTPS server if the certificate is NOT as expected from the TLSA record.
Of course, an easy solution would be the deactivation of DANE at the DNS servers, e.g., block (do not forward) all TLSA records. Or to disable the TLSA check at the browser. But this in turn would disable some good and new security features that are welcome, e.g., for remote users working with their notebooks on the road.
In the same way as the whole TLS certificate chain is spoofed by the firewall, TLSA records must be spoofed, too. With the internal root CA, an island of trust is built for TLS. Similar, an island of trust must be built with DNSSEC for signing the modified TLSA records.
- A DNSSEC signing server must build its own (partial) DNS tree, beginning with an own trust anchor, i.e., an island of trust.
- For each TLS certificate which is intercepted by the firewall, the DNSSEC server must add the appropriate TLSA record with the hash of the public key from the spoofed certificate. <- This is the actual requirement.
- The internal DNSSEC validation server (which must not be the same as the signing server!) must integrate the anchor of trust for “.” from the signing server.
- Note that the actual problem to solve is not the DNSSEC validation, but the TLSA validation. But since TLSA relies on DNSSEC, the only approach is to exchange the TLSA within its own DNSSEC chain of trust.
- If an end user opens a TLS secured website, the firewall will intercept the connection and will use its own spoofed certificate. The browser of the client will compare the TLSA record for this website, which will be correct since the DNSSEC server placed the corresponding public key into the TLSA record.
Searching for a Thesis?
To my mind, this is enough stuff for at least two master theses. The first one would be a feasibility study which shows which connections would work or not with such techniques. Which TLSA records should be used (DANE-TA, DANE-EE, …), etc. The second one would implement this technique in order to spoof TLSA records in real-time.
If you are a student and searching for a thesis, please contact me!
Featured image “A choice” by Garrett Coakley is licensed under CC BY-NC 2.0.
3 thoughts on “Idea: On-the-Fly TLSA Record Spoofing”
> If so, the browser knows which certificate to expect and will not connect to a specific site if the certificate is exchanged by an intermediate device.
This statement is not entirely true. If the certificate is signed by a *user-added* CA – that is, a CA that is not in the OS/browser trust store by default – , Firefox and Chrome will essentially disregard HPKP. In other words, user-added CAs are considered special and overrule pinning. If I’m not mistaken, the same solution/workaround would also work for DANE and would cover (almost?) all legitimate use cases.
mhils is correct in that x.509 certificates that chain up to a *user/admin added* trust anchor (CA x.509 certificate) are *not* validated against a HPKP pin — bypassing HPKP.
From Chromium FAQ at https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-
“Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.”
(Firefox has same behavior.)
More discussion (read: anger) on the behavior:
There is one important requirement. The endpoint has to use the spoofing DNS only if the traffic is also spoofed.
What’s if other services (SMTP, IMAP, …) using the same certificate but your FW/Proxy isn’t spoofing it.
I would say, removing the DANE records for intercepted Domains is the better (read functional but less secure) approach. No need for the client to spend CPU cycles on fake data. The FW/Proxy should do it on behalf on the “right” side of the traffic.