Fortinet black logo

Cookbook

Why you should use SSL inspection

Copy Link
Copy Doc ID 4d801240-7ccc-11e9-81a4-00505692583a:605938
Download PDF

Why you should use SSL inspection

HTTPS provides protection by applying SSL encryption to web traffic. However, the risk is that encrypted traffic can get around your normal Internet defences.

For example, in an e-commerce session, you might download a file containing a virus, or you might receive a phishing email containing a seemingly harmless file that, when launched, creates an encrypted session to a 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 encrypted protocols such as SMTPS, POP3S, IMAPS, and FTPS.

Full SSL inspection

To ensure all encrypted content is inspected, you must use full SSL inspection (also known as deep inspection). With full SSL inspection, FortiGate impersonates the recipient of the originating SSL session, then decrypts and inspects the content. 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 FortiGate re-encrypts the content, it uses a certificate stored on FortiGate. The client must trust this certificate to avoid certificate errors. Whether this trust exists depends on the client which can be the computer’s OS, a browser, or another application, which likely maintains its own certificate repository.

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 applies to outbound policies where destinations are unknown, that is, normal web traffic.
  • Uses address and web category whitelists which 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 applies to inbound policies to protect servers available externally through Virtual IPs.
  • Since this is typically deployed “outside-in” (clients on the Internet accessing servers 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 FortiGate. This avoids client applications generating SSL certificate errors due to certificate mismatch.

See details in the FortiOS Online Help and the Fortinet Knowledge Base for these technical notes:

SSL certificate inspection

FortiGate supports a second type of SSL inspection called SSL certificate inspection. With certificate inspection, FortiGate inspects only the header information of packets. Certificate inspection verifies the identity of web servers and ensures HTTPS is not 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. Since only the packet header is inspected, this method does not introduce certificate errors and can be a useful alternative to full SSL inspection when web filtering is used.

When using SSL certificate inspection, you might get certificate errors for blocked websites due to FortiGate trying to display a replacement message for that site using HTTPS. To prevent these errors, install the certificate that the FortiGate uses for encryption in your browser. By default, this is the same certificate for SSL inspection.

For more information, see:

Troubleshooting

The most common problem with SSL inspection is users receiving SSL errors when the certificate is not trusted, because by default, FortiGate uses a certificate that is not trusted by the client. The way to fix this depends on whether you are using FortiGate’s default certificate, a self-signed certificate, or a CA-signed certificate.

Best practices

Because all traffic needs to be decrypted, inspected, and re-encrypted, using SSL inspection can reduce FortiGate's overall performance. To avoid using too many resources for SSL inspection, do the following:

  • Know your traffic – Know how much traffic is expected and what percentage of the traffic is encrypted. You can also limit the number of policies that allow encrypted traffic.
  • Be selective – Use whitelists or trim your policy to apply SSL inspection only where it is needed.
  • Use hardware acceleration – FortiGate models with the CP6 or CPU processor have an SSL/TLS protocol processor for SSL content scanning and SSL acceleration. For more information, 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.

Why you should use SSL inspection

HTTPS provides protection by applying SSL encryption to web traffic. However, the risk is that encrypted traffic can get around your normal Internet defences.

For example, in an e-commerce session, you might download a file containing a virus, or you might receive a phishing email containing a seemingly harmless file that, when launched, creates an encrypted session to a 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 encrypted protocols such as SMTPS, POP3S, IMAPS, and FTPS.

Full SSL inspection

To ensure all encrypted content is inspected, you must use full SSL inspection (also known as deep inspection). With full SSL inspection, FortiGate impersonates the recipient of the originating SSL session, then decrypts and inspects the content. 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 FortiGate re-encrypts the content, it uses a certificate stored on FortiGate. The client must trust this certificate to avoid certificate errors. Whether this trust exists depends on the client which can be the computer’s OS, a browser, or another application, which likely maintains its own certificate repository.

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 applies to outbound policies where destinations are unknown, that is, normal web traffic.
  • Uses address and web category whitelists which 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 applies to inbound policies to protect servers available externally through Virtual IPs.
  • Since this is typically deployed “outside-in” (clients on the Internet accessing servers 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 FortiGate. This avoids client applications generating SSL certificate errors due to certificate mismatch.

See details in the FortiOS Online Help and the Fortinet Knowledge Base for these technical notes:

SSL certificate inspection

FortiGate supports a second type of SSL inspection called SSL certificate inspection. With certificate inspection, FortiGate inspects only the header information of packets. Certificate inspection verifies the identity of web servers and ensures HTTPS is not 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. Since only the packet header is inspected, this method does not introduce certificate errors and can be a useful alternative to full SSL inspection when web filtering is used.

When using SSL certificate inspection, you might get certificate errors for blocked websites due to FortiGate trying to display a replacement message for that site using HTTPS. To prevent these errors, install the certificate that the FortiGate uses for encryption in your browser. By default, this is the same certificate for SSL inspection.

For more information, see:

Troubleshooting

The most common problem with SSL inspection is users receiving SSL errors when the certificate is not trusted, because by default, FortiGate uses a certificate that is not trusted by the client. The way to fix this depends on whether you are using FortiGate’s default certificate, a self-signed certificate, or a CA-signed certificate.

Best practices

Because all traffic needs to be decrypted, inspected, and re-encrypted, using SSL inspection can reduce FortiGate's overall performance. To avoid using too many resources for SSL inspection, do the following:

  • Know your traffic – Know how much traffic is expected and what percentage of the traffic is encrypted. You can also limit the number of policies that allow encrypted traffic.
  • Be selective – Use whitelists or trim your policy to apply SSL inspection only where it is needed.
  • Use hardware acceleration – FortiGate models with the CP6 or CPU processor have an SSL/TLS protocol processor for SSL content scanning and SSL acceleration. For more information, 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.