DPI (SSL inspection) contradicts the meaning of cryptography, but companies are implementing it

Chain of trust. CC BY-SA 4.0 Yanpas



SSL traffic inspection (SSL / TLS decryption, SSL or DPI analysis) is becoming an increasingly hot topic in the corporate sector. The idea of ​​decrypting traffic seems to contradict the very concept of cryptography. However, a fact is a fact: more and more companies are using DPI technologies, explaining this by the need to check content for malware, data leaks, etc.



Well, if you accept the fact that it is necessary to introduce such a technology, then you should at least consider ways to make it the most secure and well-managed way. At least not rely on those certificates, for example, which the DPI system provider gives you.



There is one aspect of the implementation that not everyone is aware of. In fact, many are really surprised when they hear about him. This is a private certification authority (CA). It generates certificates for decrypting and re-encrypting traffic.



Instead of relying on self-signed certificates or certificates from DPI devices, you can use a dedicated CA from a third-party certification authority such as GlobalSign. But first, let's do a short review of the problem itself.

What is SSL inspection and why is it used?

More and more public websites are switching to HTTPS. For example, according to Chrome statistics , in early September 2019, the share of encrypted traffic in Russia reached 83%.







Unfortunately, cybercriminals are increasingly using traffic encryption, especially since Let's Encrypt automatically distributes thousands of free SSL certificates. Thus, HTTPS is used everywhere - and the lock in the address bar of the browser has ceased to serve as a reliable indicator of security.



From these positions, manufacturers of DPI solutions promote their product. They are deployed between end users (i.e. your employees browsing the web) and the Internet, filtering out malicious traffic. There are a number of such products on the market today, but the processes are essentially the same. HTTPS traffic passes through a validation device, where it is decrypted and scanned for malware.



After verification is complete, the device creates a new SSL session with the end client to decrypt and re-encrypt the content.

How the decryption / re-encryption process works

For an SSL inspection device to decrypt and re-encrypt packets before sending it to end users, it must be able to issue SSL certificates on the fly. This means that the CA certificate must be installed on it.



For a company (or another person in the middle), it is important that these SSL certificates are trusted in browsers (i.e. do not cause scary warning messages like the one below). Therefore, the CA chain (or hierarchy) must be in the browser trust store. Because these certificates are not issued from publicly trusted certificate authorities, you must manually transfer the CA hierarchies to all end clients.





A warning message for a self-signed certificate in Chrome. Source: BadSSL.com



On computers with Windows, you can use Active Directory and group policies, but for mobile devices, the procedure is more complicated.



The situation is even more complicated if you need to support other root certificates in the corporate environment, for example, from Microsoft, or based on OpenSSL. Plus, protecting and managing private keys so that one of the keys does not expire unexpectedly.

Best option: Private, dedicated root certificate from a third-party CA

If managing multiple roots or self-signed certificates is not attractive, then there is another option: you can rely on a third-party CA. In this case, certificates are issued from a private certification authority, which is linked in a chain of trust with a dedicated, private root certification authority created specifically for the company.





Simplified architecture for dedicated client root certificates



This setup eliminates some of the problems mentioned earlier: at least it reduces the number of roots that need to be managed. Here you can use only one private root center for all internal PKI needs with any number of intermediate certification authorities. For example, the above diagram shows a multi-level hierarchy in which one of the intermediate certification authorities is used to verify / decrypt SSL, and the other is used for internal computers (laptops, servers, desktop computers, etc.).



In this scheme, you do not need to place the CA on all clients, because the top-level CA is hosted by GlobalSign, which solves the problems with protecting the private key and the validity period.



Another advantage of this approach is the ability to revoke the SSL certificate authority for any reason. Instead, it simply creates a new one that binds to your original private root, and you can use it immediately.



Despite all the contradictions, enterprises are increasingly implementing SSL traffic inspection as part of PKI's internal or private infrastructure. Other options for using a private PKI are issuing certificates for authenticating devices or users, SSL for internal servers, and various configurations that are not allowed in public trusted certificates in accordance with the requirements of the CA / Browser Forum.

Browsers resist

It should be noted that browser developers are trying to counter this trend and protect end users from MiTM. For example, a few days ago, Mozilla decided to include the default DoH protocol (DNS-over-HTTPS) in one of the following browser versions in Firefox. The DoH protocol hides DNS queries from the DPI system, making SSL inspection difficult.



Similar plans were announced on September 10, 2019 by Google for the Chrome browser.