{"id":38110,"date":"2019-10-31T22:21:42","date_gmt":"2019-10-31T19:21:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut\/"},"modified":"2019-10-31T22:21:42","modified_gmt":"2019-10-31T19:21:42","slug":"dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut","title":{"rendered":"DPI (SSL inspection) contradicts the essence of cryptography, yet companies are implementing it","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DPI
\nChain of Trust. CC BY-SA 4.0 Yanpas<\/a><\/noindex><\/i><\/p>\n

SSL Traffic Inspection (SSL\/TLS decryption, SSL analysis or DPI) is becoming an increasingly hot topic 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 it as a necessity for checking content for malware, data leaks, etc.<\/p>\n

Well, if we accept as a fact that such a technology needs to be implemented, we should at least consider ways to do it in the safest and most manageable way. At the very least, we shouldn\u2019t rely on those certificates provided by the DPI system vendor.<\/p>\n

There is one aspect of implementation that not everyone is aware of. In fact, many are truly surprised when they hear about it. This is a private certificate authority (CA). It generates certificates for decrypting and re-encrypting traffic.
\n<\/a><\/noindex>
\nInstead of relying on self-signed certificates or certificates from DPI devices, you can use a dedicated CA from a third-party certificate authority, such as GlobalSign. But first, let's take a brief overview of the problem itself.<\/p>\n

What is SSL inspection and why is it used?<\/h2>\n

\nAn increasing number of public websites are transitioning to HTTPS. For example, according to Chrome statistics<\/a><\/noindex>, at the beginning of September 2019, the share of encrypted traffic in Russia reached 83%.<\/p>\n

\"DPI<\/a><\/noindex><\/p>\n

Unfortunately, traffic encryption is increasingly being used by malicious actors, especially since Let's Encrypt distributes thousands of free SSL certificates automatically. As a result, HTTPS is used everywhere \u2014 and the padlock in the browser's address bar is no longer a reliable indicator of security.<\/p>\n

From these positions, DPI solution manufacturers promote their product. They are implemented between end-users (i.e., your employees browsing the web) and the Internet, filtering out malicious traffic. Today, there are a number of such products available in the market, but the processes are essentially the same. HTTPS traffic goes through a checking device, where it is decrypted and checked for malware.<\/p>\n

After the verification is completed, the device creates a new SSL session with the end client for decrypting and re-encrypting content.<\/p>\n

How the decryption\/re-encryption process works<\/h2>\n

\nFor 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 a trusted CA certificate must be installed on it.<\/p>\n

It is crucial for the company (or any middleman) that these SSL certificates are trusted in browsers (i.e., do not trigger alarming warning messages like the one below). Therefore, the CA chain (or hierarchy) must be present in the browser's trust store. Since these certificates are not issued by public trusted certificate authorities, it is necessary to manually distribute the CA hierarchies to all end clients.<\/p>\n

\"DPI
\nWarning message for a self-signed certificate in Chrome. Source: BadSSL.com<\/a><\/noindex><\/i><\/p>\n

On Windows computers, Active Directory and group policies can be utilized, but the process is more complex for mobile devices.<\/p>\n

The situation is further complicated if there is a need to support other root certificates in a corporate environment, such as those from Microsoft or based on OpenSSL. Additionally, the protection and management of private keys is essential to ensure that none of the keys expire unexpectedly.<\/p>\n

The best option is to have a private, dedicated root certificate from a third-party CA.<\/h2>\n

\nIf managing multiple roots or self-signed certificates is not appealing, there is another option: you can rely on a third-party CA. In this case, the certificates are issued from a private<\/b> certification authority, which is linked in the trust chain with a dedicated, private root certificate authority created specifically for the company.<\/p>\n

\"DPI<\/a><\/noindex>
\nSimplified architecture for dedicated client root certificates.<\/i><\/p>\n

This configuration alleviates some of the issues mentioned earlier: it at least reduces the number of roots to manage. Here, one private root CA can be used for all internal PKI needs, along with any number of intermediate CAs. For example, the diagram above shows a multi-tier hierarchy where one of the intermediate CAs is used for SSL validation\/decryption, while another is for internal computers (laptops, servers, desktops, etc.).<\/p>\n

In this scheme, there is no need to host the CA on all clients because the top-level CA is hosted at GlobalSign, which resolves issues related to securing the private key and its validity period.<\/p>\n

Another advantage of this approach is the ability to revoke the SSL inspection CA for any reason. Instead, a new CA is simply created, bound to your original private root, and can be used immediately.<\/p>\n

Despite the controversies, businesses are increasingly implementing SSL traffic inspection as part of internal or private PKI infrastructure. Other use cases of private PKI include issuing certificates for device or user authentication, SSL for internal servers, and various configurations that are not permitted in public trusted certificates according to CA\/Browser Forum requirements.<\/p>\n

Browsers resist<\/h2>\n

\nIt should be noted that browser developers are trying to counter this trend and protect end users from MiTM. For example, just a few days ago, Mozilla made the decision<\/a><\/noindex> to enable the DoH (DNS-over-HTTPS) protocol by default in one of the upcoming versions of the Firefox browser. The DoH protocol hides DNS queries from DPI systems, making SSL inspection more difficult.<\/p>\n

On similar plans, on September 10, 2019, announced<\/a><\/noindex> Google announced for the Chrome browser.<\/p>\n

\"DPI<\/a><\/noindex><\/p>\n

Only registered users can participate in the survey. Please log in<\/a><\/noindex>, please.<\/p>\n

Do you think the company has the right to inspect its employees' SSL traffic?<\/h2>\n