FortiOS 6.0 Security: Why you should use SSL inspection

Most of us are familiar with HTTPS and how it protects a variety of activities on the Internet by applying SSL encryption to the web traffic. 

Using HTTPS provides the benefit of using 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 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 make sure that all 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 another application, which will likely maintain its own certificate repository. For more information about this, see "Preventing certificate warnings" for your FortiOS version: 5.2 | 5.4 | 5.6 | 6.0

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 Online Help. Also, check the Fortinet Knowledge Base for these technical notes:

• How to Enable SSL inspection from the CLI and Apply it to a Policy
• How to block web-based chat on Gmail webmail using App Sensor + SSL inspection

SSL certificate inspection

The FortiGate also supports a second type of SSL inspection, called SSL certificate inspection. When certificate inspection is used, the FortiGate inspects only 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 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. However, 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 may get certificate errors for blocked websites, due to your FortiGate attempting to display a replacement message for that site using HTTPS. To prevent these errors, you must install the certificate that the FortiGate uses for encryption in your browser. By default, this is the same certificate used for SSL inspection.

For more information, see Preventing certificate warnings (5.2 | 5.4 | 5.6 | 6.0).

Troubleshooting

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

Recipes are available concerning how to prevent these errors. Select the recipe for your FortiOS version and (if applicable) the type of certificate used for SSL inspection.

• FortiOS 5.2
• FortiOS 5.4
• FortiOS 5.6:

• default certificate
• self-signed certificate
• CA-signed certificate

• FortiOS 6.0:

• default certificate
• self-signed certificate
• CA-signed certificate

Because all traffic needs to be decrypted, inspected, and re-encrypted, using SSL inspection can reduce the overall performance of your FortiGate. 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 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.