Encrypted internet traffic is on an explosive upturn. According to the Google® Transparency Report: “Users load more than half of the pages they view over HTTPS and spend two-thirds of their time on HTTPS pages.”[1] At the same time, encrypted traffic carried nearly 3.5 million unique malware samples in 2017. In this series, we’ll dive into the case for decryption, including where and how you should enable it to meet your company’s needs.
In my last post, I covered Next-Generation Firewall buying criteria for your decryption needs. Lately there has been discussion on the internet about whether decryption performed by network security devices enhances or compromises security. In other words, if encryption is supposed to be good for data privacy and security, why decrypt? This may be an open question in your mind as you evaluate whether to decrypt traffic. Alternatively, if you have made the decision to decrypt, your executives or end-users may ask you this question.
In this post, I am going to answer this question for you by using a popular report as an example. The University of Michigan, University of Illinois Urbana-Champaign and others published a 2017 study called “The Security Impact of HTTPS Interception” that examines the prevalence and impact of HTTPS interception by network security devices. The findings indicate that nearly all interceptions reduce connection security, and many introduce severe vulnerabilities.
The paper indicates several reasons why interceptions reduce connection security:
- The default configuration for many of these network security devices weakens security, for example, by using RC4-based ciphers.
- Many devices have broken certificate validation.
- The installation process for many devices is convoluted and crash-prone.
- Device configuration is confusing.
However, when decryption is performed correctly, it enhances security. It prevents adversaries from misusing encrypted traffic to attack your organization. To ensure that decryption enhances security and does not weaken it, it is critical to confirm that your NGFW:
- Does not enable RC4-based ciphers by default. The recommended best practice security policy is to avoid weak algorithms, such as MD5, RC4, SHA1 and 3DES.
- Blocks invalid certificates by default, including sessions with expired certificates, untrusted issuer certificates and unknown status certificates.
- Blocks sessions with unsupported versions. The recommended best practice security policy blocks use of vulnerable SSL/TLS versions, including TLS 1.0 and SSLv3.
- Uses Online Certificate Status Protocol and/or certificate revocation lists – OCSP and CRLs – to verify the revocation status of certificates.
- Does not store decrypted traffic on disk. The details must be only stored in memory, meeting security and regulatory requirements.
In summary, decrypting traffic alone can weaken security, but given due diligence while buying an NGFW, and if you follow best practices, decryption will not only provide you the necessary visibility into all traffic, but also protect you from adversaries that hide threats in encrypted tunnels.
In my next and final post of this series I will cover best practices for enabling SSL decryption. In the meantime, please take a look at our recent on-demand webcast and SSL Decryption Whitepaper.