Chain of trust. CC BY SA 4.0
SSL traffic inspection (SSL/TLS decryption, SSL or DPI analysis) is an increasingly hot topic of discussion in the corporate sector. The idea of ββdecrypting traffic seems to contradict the very concept of cryptography. However, the fact is that more and more companies are using DPI technologies, explaining this by the need to check content for malware, data leaks, etc.
Well, if we accept it as a fact that such technology needs to be implemented, then we should at least consider ways to do it in the most secure and well-managed way. At least not rely on those certificates, for example, that the DPI system supplier gives you.
There is one aspect of implementation that not everyone knows about. In fact, many people are really surprised when they hear about it. This is a private certificate authority (CA). It generates certificates to decrypt and re-encrypt traffic.
Instead of relying on self-signed certificates or certificates from DPI devices, you can use a dedicated CA from a third party CA such as GlobalSign. But first, let's do a little overview of the problem itself.
What is SSL inspection and why is it used?
More and more public websites are moving to HTTPS. For example, by , at the beginning of September 2019, the share of encrypted traffic in Russia reached 83%.
Unfortunately, traffic encryption is increasingly used by attackers, especially since Let's Encrypt distributes thousands of free SSL certificates automatically. Thus, HTTPS is used everywhere - and the padlock 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 injected 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 an inspection engine 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
In order for the SSL inspection device to decrypt and re-encrypt packets before sending them to end users, it must be able to issue SSL certificates on the fly. This means that it must have a CA certificate installed on it.
It's important to the company (or other person-in-the-middle) that these SSL certificates are trusted across browsers (i.e., don't cause dreaded warning messages like the one below). Therefore, the CA chain (or hierarchy) must be in the browser's trust store. Because these certificates are not issued from publicly trusted CAs, you must manually push the CA hierarchies to all end clients.
Warning message for self-signed certificate in Chrome. Source:
On Windows computers, you can use Active Directory and Group Policies, but for mobile devices, the procedure is more complicated.
The situation becomes even more complicated if you need to support other root certificates in a corporate environment, for example, from Microsoft, or based on OpenSSL. Plus protection and management of secret keys so that one of the keys does not expire unexpectedly.
Best Option: Private, Dedicated Root Certificate from XNUMXrd Party CA
If multi-root management or self-signed certificates don't appeal, then there's another option: you can rely on a third-party CA. In this case, certificates are issued from private a CA that is linked in a chain of trust to a dedicated, private root CA 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. Only one private root authority can be used here for all internal PKI needs with any number of intermediate CAs. For example, the diagram above shows a multi-level hierarchy where one of the intermediate CAs is used to verify/decrypt SSL and the other is used for internal computers (laptops, servers, desktops, etc.).
In this scheme, it is not necessary to host a CA on all clients because the top-level CA is hosted by GlobalSign, which solves private key protection and expiration issues.
Another advantage of this approach is the ability to revoke the SSL inspection CA for any reason. Instead, a new one is simply created that binds to your original private root and can be used immediately.
Despite all the controversy, enterprises are increasingly implementing SSL traffic inspection as part of an internal or private PKI infrastructure. Other use cases for private PKI are issuing certificates for device or user authentication, SSL for internal servers, and various configurations that are not allowed in public trusted certificates as per the CA/Browser Forum.
Browsers fight back
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 enable DoH protocol (DNS-over-HTTPS) by default in one of the following browser versions in Firefox. The DoH protocol hides DNS requests from the DPI system, making SSL inspection difficult.
About similar plans September 10, 2019 Google for Chrome browser.
Only registered users can participate in the survey. , you are welcome.
Do you think a company has the right to inspect the SSL traffic of its employees?
-
Yes, with their consent
-
No, it is illegal and/or unethical to ask for such consent
122 users voted. 15 users abstained.
Source: habr.com