Fortinet black logo

Handbook

Why use SSL inspection

6.0.0
Copy Link
Copy Doc ID 4afb0436-a998-11e9-81a4-00505692583a:646647
Download PDF

Why 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. However, there are risks associated with its use, since encrypted traffic can be used to get around your network's 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:

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 allowlists 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 Fortinet Knowledge Base. Check 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.

You can apply the following security features when using SSL certificate inspection mode: web filtering and application control. With web filtering, SSL certificate inspection does not introduce certificate errors and can be a useful alternative to full SSL inspection. With application control, SSL certificate inspection can use the common name in the server certificate to identify an application by certain signatures; however, most signatures require deep inspection.

Application control and certificate inspection can check the server name indication (SNI), and then common name (CN).

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.

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 allowlists 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 Hardware Acceleration.
  • 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.

Why 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. However, there are risks associated with its use, since encrypted traffic can be used to get around your network's 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:

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 allowlists 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 Fortinet Knowledge Base. Check 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.

You can apply the following security features when using SSL certificate inspection mode: web filtering and application control. With web filtering, SSL certificate inspection does not introduce certificate errors and can be a useful alternative to full SSL inspection. With application control, SSL certificate inspection can use the common name in the server certificate to identify an application by certain signatures; however, most signatures require deep inspection.

Application control and certificate inspection can check the server name indication (SNI), and then common name (CN).

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.

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 allowlists 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 Hardware Acceleration.
  • 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.