The Conflict

Everyone wants privacy for themselves, but few really have much respect for anyone else’s. Privacy-aware individuals will take steps to guard their own even when at work. Businesses are concerned about their own confidentiality and implement interception to preserve it, arguably at the expense of individual privacy.

Interception technology is an essential component for many businesses when maintaining their confidentiality and guarding against data exfiltration. Needless to say, this doesn’t go over well with staunch individual privacy advocates.

It doesn’t help that the same technologies are in used for both authorized and unauthorized interception, especially when “authorization” is subjective.

MITM and TIA: Attacks and Policy Enforcement

Man-in-the-middle (MITM) and TLS intercept application (TIA) systems terminate Transport Layer Security (TLS) sessions with a certificate that is, ideally, trusted by the client. They then establish a second TLS session to the actual host, allowing access to decrypted data by whomever runs the system.

From a technological standpoint, there’s no real difference between the two. It’s just a matter of legitimacy. MITMs are illegitimate and are therefore an attack on confidentiality. TIAs are authorized and are viewed, for the most part, as auditing tools that enforce policy.

This creates a difficult scenario when it comes to creating a solution to prevent attacks on confidentiality. How do we block the attacks while still permitting policy enforcement?

TIAs and Trusted Private CAs

TIAs are typically issuing dynamic certificates from trusted private certificate authorities (CAs). Ultimately, trust in any given secure destination is the client’s job, so if the client trusts the certificate chain being presented, it will be accepted as valid. It really doesn’t matter if the chain is completely different from the server’s actual certificate chain. The client’s interpretation of what is valid is ultimately what matters. TIAs have the advantage here because the dynamic certificates they issue are trusted by the clients.

MITMs and User Education

MITMs, on the other hand, are usually doing one of two things; they’re working in conjunction with malware that installs invalid entries into the client’s list of trusted certificates or they’re not even trying to make a pretense at legitimacy and are presenting completely invalid certificates and relying on user ignorance to get what they’re looking for.

Malware installations are an ongoing problem for most desktop support groups and require constant diligence, but often get installed due to inexperienced users placing trusting sites that they shouldn’t. Users accepting completely invalid certificates despite warnings fall into the same category. These are both addressable with education.

Hard-Pinned Certificates and DANE

Rightly or wrongly, there will still be those who want to ensure that traffic can’t be intercepted. MITMs and TIAs can both be defeated, but it still comes down to having the client determine what can’t be trusted.

One way to do this is to hard-pin the server’s certificate into the client application so that only that certificate is trusted. This causes the application to reject anything but the certificate that it knows is correct, including anything provided by MITMs and TIAs. Future updates to the application can include upgraded certificates, but it isn’t scalable.

More interesting, there is a new specification for DNS-Based Authentication of Named Entities (DANE) under RFC 6698. This establishes a new record that allows the client to verify the certificate itself via DNS, potentially rendering certificates provided by MITMs and TIAs invalid.


Idealism and Will

The justification for end-to-end encryption with no potential for intercept falls largely into the realm of individual idealism. Back at the beginning of this article, I wrote that the privacy of others isn’t really what we’re worried about. Software architects design applications with pinned certificates. Internet engineers propose standards like DANE.

The need for authorized interception comes out of business and legal requirements. The will to implement technologies that bypass this just isn’t significant. This is why applications that use certificate pinning are uncommon. This is why DANE isn’t present in any of the major web browsers.

The Whisper in the Wires

The encryption of network traffic starts with the need to keep sensitive information confidential. The requirement is the same whether we’re dealing with individual or business interests. Unfortunately, that’s where the commonality ends.

Businesses want to protect their confidential information from being exfiltrated, and they want an audit trail for legal purposes. Individuals (correctly or incorrectly) assert a right to privacy and want none of the above.

As long as there’s a conflict of interests between these groups, there’s going to be an escalating evolution of workarounds for both encryption and interception, but workarounds are the province of individuals and visibility is the realm of business. Much as I want to root for the underdog, the smart money is on the latter.

Originally published on the Aruba Blogs site.