HTTPS Interception – How To Use It Without Concern

April 11, 2017 — by Lior Rozen0



HTTPS Interception – How To Use It Without Concern

April 11, 2017 — by Lior Rozen0

Network privacy is making its way more and more into the news these days. As much as we are eager to share and get responses to our personal moments on social media, we are even more eager to protect our private data. The privacy concern has become even stronger ever since we discovered as part of the Snowden revelations that the U.S. government (as well as others) is actually inspecting all internet communication.

Keeping privacy poses a challenge for organizations, who try to balance their employees’ privacy and corporate security. Privacy is very important. Protecting an organization’s intellectual property is also important, and so is the need to detect malware and data leakages. In many cases, such balance is achieved by inspecting some of the encrypted communication of the organization’s employees to the internet. The inspection is done automatically by security tools, which are designed to detect malwares without saving or checking the application content. Recently, this technique got a hit from US-CERT (United States Computer Emergency Readiness Team), advising that such inspection, also called HTTPS interception, is weakening security.

In this post, I would like to examine the benefits of HTTPS interception, as well as the risks it introduces. We will see that HTTPS interception gives a lot of power to the organization that deploys it, and quoting Spiderman’s uncle Ben – “with great power comes great responsibility.” However, much like in the Marvel world, we would like the good guys to have this power, and bear the responsibility, for the common good.

HTTPS interception allows the organization that uses it to look at the encrypted data sent in and out of the organization. Such inspection is very important – It allows the organization to detect and prevent malware infection and other security breaches. By inspecting the communication, the organization can detect Command and Control communications, and prevent malware from spreading and doing harm. Even if the malware is installed, the HTTPS interception can ensure that no important data is leaving the company to the wrong destination, which is also important in preventing espionage and other malicious acts. A complete eco-system of outbound data inspection was developed to prevent such problems. The ecosystem includes Data-Loss-Prevention devices, Firewalls, IPSes and more, all of which can be bypassed without the HTTPS interception.

Given all the above benefits, why would US-CERT advise against HTTPS interception? US-CERT does have a very good point. In order to explain it, I will first explain how HTTPS interception devices work. The HTTPS interception device is located at the edge of the organization, and it intercepts all HTTPS connections between the organization’s network and the internet. Recent technology improvements, specifically, the usage of perfect-forward-secrecy encryption (PFS), do not allow interception devices to be out-of-band from the connection. The HTTPS interception device has to be a full proxy – in order to look at the communication it has to first terminate the connection from the internal user, and decrypt the data. the HTTPS interception device then sends the decrypted data to the outbound data-protection devices. After the data is verified to be legitimate, the HTTPS interception device re-encrypts the traffic and initiates another connection to the server in the internet. It then sends the encrypted data to the server.

[You might also like: DNS Reflective Attacks]

Now for the problem that US-CERT has raised– people want to protect their privacy, and attackers are constantly trying to get personal data from web surfers. The HTTPS protocol, relaying on SSL and TLS, is evolving quickly, making old encryption techniques vulnerable for cracking. For example – the move from SSL to TLS, and the current discussion on TLS 1.3 is a big part of these evolvements on the encryption side. On the authentication side we have Google Chrome, who recently stopped considering SHA1 certificates as secured, and other browsers are quickly following. Using a modern browser allows the user to be warned about using old or weak encryption or authentication, but the encryption and authentication that the browser can monitor and verify are a point-to-point privacy, and not an end-to-end privacy. The browser sees its secured connection to the next point. Usually this next point is the internet server, but if the organization is using an HTTPS interception device, this device terminates the connection, and opens another separate connection between itself and the internet server. Here lies the problem – the secured connection between the browser and the interception device is usually private and within the organization network. The risk, as US-CERT sees it, comes from bad security on the connection to the internet server – a connection the browser is not even part of, and has no way of checking or verifying.

However, US-CERT discussion is ignoring a well-known fact in security. The most vulnerable part of the security ecosystem is the one sitting in front of the computer – the user. The user is prone to click “next” on any error message, especially if he/she does not really understand it. People are trained by life to ignore repeated warnings and giving the responsibility to the user is not always the best approach. Another concern exists when a malware hits the user’s computer. Such malware can steal private information, usernames and passwords, as well as the organization’s IP. The organization has the right and even the obligation to stop this malware. If the malware is allowed to communicate securely, it will evade detection and cannot be stopped.

If the organization chooses to use a well-configured HTTPS interception device, it can reduce all these risks. A good device will simply refuse connecting to a poorly configured server (or maliciously configured ones). No “next” or “override” options for the user can actually ensure good security – not bad security. The organization should know what to inspect and what not to inspect (health data, banking, etc.) and a good device should give an option to bypass inspection on private data. A good HTTPS-interception device should also block fraudulent URLs and protect the user even further.

Like any technology, the organization needs to know how to use it in order to make it work well. The technology by itself is not “good” or “bad” – the usage is what makes a difference. Using an up-to-date HTTPS interception device, with a strong security company behind it, and a good understanding of its configuration, allows the organization to provide security to both itself and to its individual employees. It allows the employees to share what they want to share, and keep their privacy on their intimate data, while protecting them from malwares and weak security. The HTTPS interception device can strengthen the security if configured correctly, or weaken it if configured incorrectly. Our concern should be on enhancing the knowledge of how to use the technology, and not on warning against it.


Read the 2016–2017 Global Application & Network Security Report by Radware’s Emergency Response Team.

Download Now

Lior Rozen

Lior Rozen is the Director of Technologies for Radware. With over a decade of experience, he is a cyber-security expert, architecting innovative cyber security solutions and deployments tailored for Radware’s customers’ needs. Before taking his current position, Lior was the director of R&D for Radware’s DefensePro, managing all R&D aspects of this DDoS-protection market-leader technology. Lior led the shift to virtualized-ready software architecture, while promoting partnerships with leading security companies. Lior writes about network security and technology.

Leave a Reply

Your email address will not be published. Required fields are marked *