Why you should use SSL inspection

Most of us are familiar with Hypertext Transfer Protocol Secure (HTTPS) and how it protects a variety of activities on the Internet by applying Secure Sockets Layer (SSL) encryption to the web traffic. 

The benefits of HTTPS are obvious, as encryption keeps your private data safe from prying eyes. However, there are risks associated with its use, since encrypted traffic can be used to get around your normal defenses. 

For example, you might download a file containing a virus during an e-commerce session.  Or you could receive a phishing email containing a seemingly harmless downloader file that, when launched, creates an encrypted session to a command and control (C&C) server and downloads malware onto your computer. Because the sessions in these attacks are encrypted, they might get past your network’s security measures.

To protect your network from these threats, SSL inspection is the key your FortiGate uses to unlock encrypted sessions, see into encrypted packets, find threats, and block them. SSL inspection not only protects you from attacks that use HTTPS, but also from other commonly used SSL-encrypted protocols, such as SMTPS, POP3S, IMAPS, and FTPS.

Full SSL inspection

To make sure that all SSL encrypted content is inspected, you must use full SSL inspection (also known as deep inspection). When full SSL inspection is used, the FortiGate impersonates the recipient of the originating SSL session, then decrypts and inspects the content. The FortiGate then re-encrypts the content, creates a new SSL session between the FortiGate and the recipient by impersonating the sender, and sends the content to the sender.

When the FortiGate re-encrypts the content it uses a certificate stored on the FortiGate. The client must trust this certificate to avoid certificate errors. Whether or not this trust exists depends on the client, which can be the computer’s OS, a browser, or some other application, which will likely maintain it’s own certificate repository. For more information about this, see the recipe Preventing certificate warnings.

There are two deployment methods for full SSL inspection:

1. Multiple Clients Connecting to Multiple Servers:

  • Uses a CA certificate (which can be uploaded using the Certificates menu).
  • Typically applied to outbound policies where destinations are unknown (i.e. normal web traffic).
  • Address and web category whitelists can be configured to bypass SSL inspection.

2. Protecting SSL Server

  • Uses a server certificate (which can be uploaded using the Certificates menu) to protect a single server.
  • Typically used on inbound policies to protect servers available externally through Virtual IPs
  • Since this is typically deployed “outside-in” (clients on the Internet accessing server(s) on the internal side of the FortiGate), server certificates using the public FQDN of the server are often purchased from a commercial Certificate Authority and uploaded to the FortiGate. This avoids client applications generating SSL certificate errors due to certificate mismatch.

More detail is available in the FortiOS Handbook. Also, check the Fortinet Knowledge Base for these technical notes:

SSL certificate inspection

FortiGates also supports a second type of SSL inspection, called SSL certificate inspection. When certificate inspection is used, the FortiGate only inspects the header information of the packets.

Certificate inspection is used to verify the identity of web servers and can be used to make sure that HTTPS protocol isn’t used as a workaround to access sites you have blocked using web filtering.

The only security feature that can be applied using SSL certificate inspection mode is web filtering. However, since only the packet is inspected, this method does not introduce certificate errors and can be a useful alternative to full SSL inspection when web filtering is used.

Troubleshooting

The most common problem with SSL inspection is users receiving SSL errors when the CA certificate is not trusted. This is because by default the FortiGate uses a certificate that is not trusted by the client. There are two ways to fix this:

  1. All users must import the FortiGate’s default certificate into their client applications as a trusted certificate.
  2. Configure the FortiGate to use a certificate that is already trusted by your clients. For example, a certification signed by a CA that your clients already trust.

The first method can be more labor intensive because you have to distribute a certification to all clients. This can also be an ongoing problem as new clients are added to your network. The second method is usually less work but may require paying for a CA. Both of these methods are covered in the recipe Preventing Certificate Warnings.

If you choose to install the certificate on client applications, this can be done with greater ease in a Microsoft Active Directory domain environment by using Group Policy Objects to install the certificate on domain members. Check that the Group Policy has propagated to all computers by opening Internet Explorer on a workstation PC, opening Tools > Internet Options > Content > Certificates >Trusted Root Certification Authorities, and ensuring that the FortiGate’s certificate is present.  

For corporate-owned mobile devices, MDM solutions like AirWatch, MobileIron, or Fiberlink, use Simple Certificate Enrollment Protocol (SCEP) to ease certificate enrollment.

Best practices

Because all traffic needs to be decrypted, inspected, and re-encrypted, using SSL inspection can reduce overall performance of your FortiGate. To make sure you aren’t using too many resources for SSL inspection, do the following:

  • Know your traffic – Know how much traffic is expected and what percent of the traffic is encrypted. You can also limit the number of policies that allow encrypted traffic.
  • Be selective – Use white lists or trim your policy to apply SSL inspection only where it is needed.
  • Use hardware acceleration – FortiGate models with either the CP6 or CPU processor have an SSL/TLS protocol processor for SSL content scanning and SSL acceleration. For more information about this, see the Hardware Acceleration handbook.
  • Test real-world SSL inspection performance yourself – Use the flexibility of FortiGate’s security policy to gradually deploy SSL inspection, rather than enabling it all at once.
Victoria Martin

Victoria Martin

Technical Writer & Head Cookbook Chef at Fortinet
Victoria Martin works in Ottawa as part of the FortiOS technical documentation team. She graduated with a Bachelor's degree from Mount Allison University, after which she attended Humber College's book publishing program, followed by the more practical technical writing program at Algonquin College. She does need glasses but also likes wearing them, since glasses make you look smarter.
Victoria Martin

Latest posts by Victoria Martin (see all)

Share this recipe:

Facebooktwittergoogle_pluslinkedin

Leave a comment:

Before commenting, please read the site's comment policy. Only questions related to documentation will be answered. For other concerns, please contact Fortinet support.

  • Vincent

    When the FortiGate initiates a new HTTPS sessions to the web server after content scanning.
    Does it control the CA certificate (with a trusted CA list) that signed the certificate of the web server ?
    Without this check, trust chain is broken.

    • Bruce Davis

      Not entirely sure that I exactly understand the question, the FortiGate does not initiate HTTPS sessions, that is usually done by a browser or some other software on someones computer, but when a new HTTPS session is initiated the verification process is gone through again regardless of whether or not there was a session before.
      A number of variables such as which interfaces are being used, the source and destination addresses, the services being used etc. will determine which security policy the traffic is going through. Each policy can have an SSL/SSH
      inspection profile associated with it and in that profile a specific certificate is chosen.
      There is something that is called “pinning” which checks and verifies that a certificate for a website is issued by a specific Certificate Authority but that is a feature of some browsers. The FortiGate does allow the use of this function to pass through so there is not problem there.

      • Vincent

        Sorry, maybe I am not using the righ words.
        What I want to say:

        Without Deep Inspection:
        -> My web browser cheks the certificate of the web server thanks to trusted CA list.

        With Deep Inspection:
        The CA that signed the certificate of the web server is no more checked because the Fortigate does not have a list of trusted CA such as VeriSign, Thawte, …

        I think it is a real security problem and that is why I am a little bit reluctant to use SSL inspection.

        I am not talking about “certificate pinning”; a mechanism adapted to mobile Platform.

        • telbar

          Hi Vincent,
          With Deep Inspection enabled, the FortiGate always check the certificate of the web server with “ssl-ca-list” feature. Here is an example:

          Assuming that http://www.example.com uses a certificate signed by a subCA of “DigiCert Global Root CA”

          In your SSL/SSH Inspection profile:

          config firewall ssl-ssh-profile
          edit deep-inspection
          set server-cert-mode re-sign //Multiple clients connecting to multiple servers.
          config https
          set allow-invalid-server-cert disable
          set ssl-ca-list enable
          end
          end

          When you browse to http://www.example.com:

          1. If “DigiCert Global Root CA” is NOT loaded to the FortiGate:
          => The traffic will fail with an error message “The Connection is Untrusted”

          2. If you load “DigiCert Global Root CA” into the FortiGate:
          => The FortiGate verify the certificate chain and pass traffic.

          You can verify the traffic flow using following commands:
          diag debug enable
          diag debug app ssl -1

          Let me know how it goes.
          Taher.

          • Vincent

            Hi Taher,

            Thank you for the tip, I did not know this option.

            (I have opened a ticket on this topic and I got a slightly different answer.)
            Nevertheless, it seems pretty restrictive to manually manage a cert store.

            It is better than nothing, it should be possible to retrieve a list of trusted CA Certificate from Firefox for instance. To maintain, it will be a little more complicated.
            Thank you very much.

  • Bruce Davis

    Not entirely sure that I exactly understand the question, the FortiGate does not initiate HTTPS sessions, that is usually done by a browser or some other software on someones computer, but when a new HTTPS session is initiated the verification process is gone through again regardless of whether or not there was a session before.
    A number of variables such as which interfaces are being used, the source and destination addresses, the services being used etc. will determine which security policy the traffic is going through. Each policy can have an SSL/SSH inspection profile associated with it and in that profile a specific certificate is chosen.
    There is something that is called “pinning” which checks and verifies that a certificate for a website is issued by a specific Certificate Authority but that is a feature of some browsers. The FortiGate does allow the use of this function to pass through so there is not problem there.

  • Santosh Sharma

    Victoria

    your cookbook documents are superb. you read the mind of reader and put everything in just 2 pages.

  • Tom

    Regarding “Protecting SSL server”:

    I have added a cert I have purchased from a CA, but under Policy > SSL/SSH Inspection I am unable to select the CA cert as a “Server Certificate”.

    I am therefore unable to add the cert into the policy.

    Is this something you are familiar with or shall I log a support ticket?

    Thanks,

    Tom

  • Net

    Hi Victoria,

    Great article! Just wanted to know if you have an idea with what I encountered.

    To give you a background, the set-up that we have here with regards to the policies for users
    access to internet, each one is applied with granular inspection using
    Web Filtering and Application Control and with that, we used deep
    inspection for SSL/SSH. Given the conditon, we installed
    Fortinet_CA_SSLProxy.cer to all workstation so they will not experience
    SSL error due to deep-inspection when they are browsing. However, some
    of the users complain of slowness in accessing some sites (not all),
    when we isolated all possible causes, only thing we found out is that
    they have duplicate(more than one) Fortinet certificate installed in the certmgr.msc
    >> Trusted Root >> Certificates. Upon deleting one of these
    cert, users access went normal.

    What is the behavior of these cert and the FortiGate as well when it sees duplicate certificate in the user?

    Thanks,
    Net

    • Victoria Martin

      Hi Net,

      I just wanted to let you know that I am looking into this and trying to figure out why your issue has happened.

      If you require a more immediate answer, I would recommend getting in touch with Support. Before you do that, though, please check out our article about working with support: http://cookbook.fortinet.com/how-to-work-with-fortinet-support/

      • Net

        Hi Victoria,

        Thanks for your attention on this matter and for the recommendation.

        Actually, I do have an open ticket with the support but unfortunately, the representative cannot reproduce the scenario in his end.

        I am also attaching here screenshot of the actual duplicate FortiGate CA we’ve found, in case you need more view about my case. We found out that the certificates were installed by different login
        accounts to the PC. First installation is done by the IT admin (IT
        log-in) and the rest is done using the user log-in.

        Thanks,
        Net

        https://uploads.disquscdn.com/images/a3ee321534ebce2d815a162740abfb4c9a720d583dfc5615932b3f82dec54bad.jpg

  • Billy

    Hi Victoria, good info. Please confirm:

    “Address and web category whitelists can be configured to bypass SSL inspection”

    Where do we manage the whitelists?

    Thanks,
    B

    • Victoria Martin

      Hi Billy,

      You can manage the whitelists in your SSL inspection profile. We have a recipe that specifically looks at exempting/whitelisting Google from inspection that can help: http://cookbook.fortinet.com/exempting-google-ssl-inspection/

      • François Blanchon

        Hi Victoria,
        Do you known if web categories (the 3 default) in the SSL inspection exception profile, apply as well to IPS filtering ? And if it requires a web filter license ?
        My idea is simply to apply IPS check for HTTPS traffic (SSL inspection mandatory) but bypass IPS check when traffic destination is ebanking portals for instance ? And webfiltering is already done elsewhere :-).

        Thank you,
        Regards,
        François

        • Victoria Martin

          Hello François,

          Because the SSL inspection profile uses the FortiGuard web categories, you will need a web filter license in order to use them. However if you have a license, the exemptions will be applied to all security profiles that are applied in the same firewall policy, including IPS.

  • Mariano Sanchez

    Hello Victoria i like your shapes for network topology drawings! Where can i get them?!

  • James Otieno

    Great Stuff, helps me with my technical write ups. Thank yous

  • pdisme

    Hello, I use this setup, and am wondering if there’s a way to do a decrypted packet capture on the FortiWeb side? I’m trying to troubleshoot an issue and would like to see the decrypted http request. I have things set up where a public name points at an ‘external’ VIP defined on the FortiWeb (using it as an ADC for https requests), FortiWeb is serving the recognized SSL cert, decrypts, does inspection, then makes a proxied request to one of the real servers behind the scenes on the ‘private’ side.

    If I use the standard FortiOS diagnose network sniffer method to capture the packets, but it’s just showing me the same thing I’d get on the client or web server side using tcpdump, which is just seeing the encrypted data. Is there a way to let me see the http request in motion when the FortiWeb has it decrypted in between?