Best Practices for Enabling SSL Decryption

Nov 01, 2018
3 minutes

Throughout this series, I have covered the case for decryption, including why, where and what you should consider when purchasing technology for your organization’s needs. However, enabling SSL decryption is not just about having the right technology in place. A triad of people, process and tools must align and work together toward the same goal.

With an agreement between teams and a handle on the appropriate processes and tools, you can begin decrypting traffic. I recommend following these best practices for optimum results and to avoid common pitfalls.

  1. Determine the sensitive traffic that must not be decrypted: Best practice dictates that you decrypt all traffic except that in sensitive categories, such as Health, Finance, Government, Military and Shopping.
  2. Add exclusions to bypass decryption for special circumstances: You will need to bypass decryption in certain circumstances, such as for traffic that breaks upon decryption, specific users who need to bypass decryption for legal reasons, or partner websites that may be allowed to bypass strict certificate checks. Make sure you create such exclusions only when warranted, and keep them to a minimum.
  3. Set up verification for certificate revocation status: To verify the revocation status of certificates, the NGFW uses OCSP and/or CRLs. Make sure that certificates presented during SSL decryption are valid by configuring the firewall to perform CRL/OCSP checks.
  4. Configure strong cipher suites and SSL protocol versions: Consult your security governance team to find out what cipher suites must be enforced and determine the minimum acceptable SSL/TLS protocol version. For example, your security team may want to use the DHE or ECDHE key exchange algorithms to enable perfect forward secrecy, or PFS, along with TLS 1.2 protocol. Alternatively, the team may want to block use of vulnerable SSL/TLS versions, such as TLS 1.0 and SSLv3, and avoid weak algorithms, such as MD5, RC4, SHA1 and 3DES. Enforce your security team’s recommendations on your NGFW.
  5. Deploy the decryption certificate from your enterprise root certificate authority: Deploy this certificate on your NGFW so that your end users do not see SSL certificate warning messages.
  6. Decrypt SSH in addition to SSL: SSH is required for some applications, but can be misused, as mentioned earlier. For this reason, it is recommended that you allow SSH to be used only for applications and users that need it in addition to enabling SSH decryption.


For more information on SSL Decryption, please take a look at our on-demand webcast and SSL Decryption Whitepaper.


Subscribe to the Blog!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.