How SSL inspection works
More and more traffic is being encrypted using SSL nowadays. For example, Google reports that 95% of the traffic destined to their web services is currently being accessed using HTTPS. In that same report, Google also indicates that 96 of the top 100 non-Google websites on the Internet, which account for 25% of the global web traffic, default to HTTPS when delivering content to users.
The boost in SSL utilization is due to the need for privacy. However, some attackers may also take advantage of SSL to prevent network security devices from detecting attacks. Because you want to ensure that the content accessed by your users conforms with your usage policy and does not represent a threat, then you should consider enabling SSL inspection on FortiGate. SSL inspection allows FortiGate to inspect traffic encrypted with SSL. As a result, enabling SSL inspection not only provides you with a better visibility of the increasingly number of SSL-based applications running on your network, but also allows you to detect attacks using SSL.
This post describes SSL inspection in FortiGate with a focus on TLS, which is the successor of the deprecated SSL protocol.
What is SSL Inspection?
SSL inspection enables FortiGate to inspect SSL traffic across the firewall at the application layer level. Depending on the SSL inspection mode in use, the inspection takes place at the SSL handshake stage, which is when some information is exchanged in clear-text, or after the SSL handshake is completed, which is when all application data is exchange encrypted.
The data inspected by SSL inspection is then used by security profiles such as web filtering, antivirus, application control, IPS and AntiSPAM, to identify websites, files, applications, patterns and any other traffic-related attributes that can be used for matching any of the security profile rules in place. Once a security profile rule is matched, then FortiGate performs an action on the corresponding traffic (allow, block, monitor, reset, etc).
Without SSL inspection, application data of SSL traffic wouldn't be inspected by FortiGate, which means that the forwarding decisions made by the firewall would be based on Layer 3 and Layer 4 information only.
TLS 1.0/1.1/1.2 Handshake
Before discussing SSL inspection further, let's first describe the TLS handshake prior to TLS version 1.3. Although SSL protocol is also supported by SSL inspection, we will focus on TLS because it has a much wider adoption than its predecessor. Knowing how the TLS handshake takes place will help us identify the stages where SSL inspection operates.
The image below displays a simplified four-step process of a common TLS handshake, which is enough for the purpose of understanding SSL inspection. For a more detailed explanation, take a look at this post from thesslstore.com.
1. Client Hello
The handshake begins with the client sending a client hello message to let the server know that it wants to negotiate a TLS connection. The information in the client hello message is sent in clear-text, and it includes the TLS version and ciphers suites that the client supports. The client, especially modern ones, may also include the Server Name Indication (SNI). The SNI is a TLS extension that indicates the hostname of the SSL server that the client wants to connect to.
2. Server Hello
The server replies with a server hello message that includes the agreed TLS version and ciphers, as well as other relevant information. The server will also send along its certificate in clear-text. The certificate contains the Common Name (CN) and any Subject Alternative Names (SANs) that may have been added to the certificate.
The CN represents the server name. Two examples of CNs:
The SANs are additional names that are associated with the certificate. It allows a single certificate to be used to secure multiple SSL sites instead of having a separate certificate for each SSL site. An example of a SAN:
3. Pre-master secret exchange
The client generates a pre-master secret, encrypts it with the server certificate's public key, and sends it to the server. The server decrypts the pre-master secret with its private key. At this point, both endpoints know the pre-master secret.
4. Master secret generation
The client and server derive the master secret from the pre-master by using cryptographic operations previously agreed upon by both parties. The client notifies the server that it will switch to using the newly negotiated master secret and cipher. From now on, all data exchanged between the endpoints by the underlying application (HTTP, FTP, LDAP, etc) is encrypted using the same master secret and cipher (symmetric encryption).
SSL Inspection Protection Modes
FortiGate supports two inspection protection modes: resign and replace.
config firewall ssl-ssh-profile edit <ssl-inspection-profile-name> set server-cert-mode re-sign|replace next end
This is the most common deployment type. FortiGate inspects the SSL connections against multiple SSL servers through the firewall. Because the servers that the clients may connect to cannot be anticipated, and therefore, their server certificates will vary, FortiGate has to perform a man-in-the-middle (MITM) attack to decrypt the SSL-protected data. The common use case for resign mode is when you have multiple users accessing multiple SSL servers on the Internet through FortiGate.
On the GUI, this protection mode is displayed as Multiple Clients Connecting to Multiple Servers, while on the CLI, it's shown as re-sign. It's called resign because FortiGate presents to the client a temporary certificate that contains the same CN as the one in the original certificate, except that it has been signed by FortiGate instead of by the original CA. The following diagram describes resign mode:
As seen in the image, FortiGate gets the original certificate from the server, but instead of forwarding the same certificate to the client, it creates a new one with the same CN but with different issuer and public key. The purpose is to trick the SSL client to think it is connecting to the intended server, although it is actually connecting to FortiGate.
The issuer of the temporary certificate matches the CN of the CA certificate configured on the SSL inspection profile. By default, the CA certificate is set to Fortinet_CA_SSL, which is a built-in CA certificate that comes with the firewall. The CN of Fortinet_CA_SSL is the serial number of FortiGate. To change the CA certificate that FortiGate uses to resign, run:
config firewall ssl-ssh-profile edit <ssl-inspection-profile-name> set server-cert-mode re-sign set caname <ca-cert> next end
In addition to changing the issuer and public key of the certificate, FortiGate also creates a private key for the temporary certificate. The private key is used during the SSL handshake to exchange the pre-master secret, from which FortiGate will derive the master secret used for exchanging encrypted traffic with the client.
FortiGate inspects SSL connections destined to known SSL servers. A common example is an SSL server that is protected by FortiGate from requests coming from Internet users. Unlike resign mode, FortiGate knows the destination of the SSL connection and therefore does not have to perform MITM. Instead, FortiGate behaves as a reverse proxy by presenting to the client a valid server certificate, processing the request, and responding to it on behalf of the actual SSL server. Because FortiGate has also been configured with the server's private key, it can decrypt the network traffic.
On the GUI, this protection mode is displayed as Protecting SSL Server, while on the CLI, it's displayed as replace. The following diagram describes replace mode:
In the diagram above, FortiGate has been configured with a copy of the certificate used by the SSL server, and therefore, both devices present the same certificate during the SSL handshake. Although this is a valid setup, the certificates don't have to be the same. What it's important is that the certificate installed on the FortiGate is trusted by the client. The certificate installed on the SSL server itself can be any, as it is only seen by FortiGate. To change the certificate that FortiGate uses, run:
config firewall ssl-ssh-profile edit <ssl-inspection-profile-name> set server-cert-mode replace set server-cert <server-cert> next end
SSL Inspection Methods (Resign Mode)
When SSL inspection in set to resign mode, FortiGate offers two inspections methods: SSL certificate inspection and full SSL inspection.
SSL certificate inspection
FortiGate identifies the SSL server name by inspecting the SSL handshake, specifically the client hello and server hello messages, both of which are exchanged in clear-text. In the client hello, FortiGate checks the SNI extension, while on the server hello, FortiGate looks at the CN and SAN. By looking at the SNI, CN and SAN values, FortiGate can identify the hostname of the SSL server. The hostname is then checked against the web filtering profile enabled in the matching policy to determine whether the website must be allowed or blocked. If the website must be allowed, FortiGate let the client and server complete the SSL handshake and exchange data through the SSL connection. However, if the website must be blocked, FortiGate performs MITM and presents the client a replacement message instead of the original website. The replacement message informs the user that the website has been blocked by web filtering. The following is an example of a replacement message:
In SSL certificate inspection method, the server certificate is resigned only when the website is blocked and thus MITM is performed by FortiGate. FortiGate does not perform MITM on allowed websites, which means that it does not have access to the
application data exchanged by the endpoints. In addition, FortiGate can only detect the SSL server hostname, which is why web filtering is the only security profile that benefits from SSL certificate inspection. Other security profiles (antivirus, application control,
IPS, etc) require access to the application data to make a decision. This means that, although you can enable different security profiles in a policy using SSL certificate inspection, only web filtering will be performed on SSL traffic.
In addition, because web filtering detection is limited to hostnames, if your web filtering profile is configured to match a URL that contains a path, such as checkthefirewall.com/pages/about, then FortiGate will be unable to detect the full URL if HTTPS is used.
Full SSL inspection
FortiGate first checks if the SSL server is exempted from full SSL inspection by obtaining the hostname from the SSL handshake and checking it against the SSL exemption list. If the server is not exempted, FortiGate performs MITM to inspect the application data. Application data is then checked by the matching security profiles to determine the action to take on the traffic (allow, block, reset, etc).
If the SSL server is exempted, FortiGate does not perform MITM and let the endpoints complete the SSL handshake and exchange data.
If web filtering is enabled, detection can be performed on full URLs because FortiGate has access to the HTTP header on the HTTP packets.
Because FortiGate performs MITM on all non-exempted SSL traffic (including encryption/decryption tasks), it is expected to see an increase in CPU and memory usage, especially if no full SSL inspection was being done previously. Remember, most of the web traffic is encrypted with SSL nowadays. So, don't be surprised if your FortiGate CPU and memory graphs show a steep spike just after you enable full SSL inspection on all your traffic.
As mentioned before, when FortiGate performs MITM for SSL inspection (resign mode), FortiGate creates a new certificate with the same CN as the one in the original website certificate but with different issuer and public key. The default issuer is the FortiGate serial number, which is the CN in the default CA certificate used in SSL inspection profiles (Fortinet_CA_SSL). Because the CA is not a public trusted CA, your browser will detect it as invalid and thus generate a warning similar to the image below when loading the website.
If the website does not use HTTP Strict Transport Security (HSTS), the browser offers you the option to proceed to view the site. Otherwise, the browser won't even offer that option to you. Because many websites use HSTS, including big content providers such as Google and Facebook, chances are that you won't be able to access some sites.
That said, to prevent the certificate error reported by the browser, you can import Fortinet_CA_SSL to your browser. Alternatively, you can create and import your own private CA to FortiGate, and then use it in your SSL inspection profile. Most administrators prefer to use their own private CA because they have an existing PKI infrastructure using a certification authority service such as Microsoft CA. Of course, you must also make sure that your private CA is trusted by your clients, which means that you may need to import your private CA certificate to the clients' browsers too, unless the issuer of your private CA (usually a root private CA) is already trusted by your browser.
In addition, when creating your private CA, you must ensure it includes the following X.509 extensions:
If the extensions above are not present in the CA, FortiGate will not allow you to select the certificate as the CA for your SSL inspection profile.
Also note that your own CA is always private, never public. Although technically you could have your CA signed by a public trusted entity such as Verisign or GoDaddy, that won't happen in practice. The reason is that if a public trusted entity signs your CA, then your CA becomes a public trusted intermediate CA. This means that all browsers will automatically trust the resigned certificates issued by FortiGate because the issuer (public entity) is already trusted. As a result, you could have your FortiGate perform SSL inspection on any network and the browsers would never complain about privacy. The latter would then defeat the purpose of SSL.
TLS 1.3 is the latest version of the protocol. It features faster and more secure negotiation. The TLS 1.3 handshake is also different. For instance, the server now sends its certificate encrypted instead of sending it in clear-text as it is the case for previous TLS versions.
Starting FortiOS 6.2, FortiGate supports SSL inspection for traffic encrypted with TLS 1.3. Per my tests in FortiOS 6.2.3, FortiGate can perform both SSL certificate and full SSL inspection. Like in previous TLS versions, web filtering is the only security profile that leverages the SSL certificate inspection method. Other security profiles require full SSL inspection for detection.
I have explained how SSL inspection works in FortiGate. Although enabling SSL inspection introduces potential certificate errors that can be resolved, it should be considered "a must" on most networks.
Presently, nearly all of the network traffic uses SSL for encryption. Not enabling SSL inspection means that your FortiGate device will perform decisions based on L3 and L4 information on most of the traffic, which prevents you from taking advantage of useful detection techniques that require application-level data for operation. The latter greatly reduces the ability to detect threats and prevent unacceptable use of resources on your network.
A Network Security Engineer based in Canada.