SSL/SSH inspection

Individual deep inspection security profiles can be created depending on the requirements of the policy. Depending on the inspection profile selected, you can:

• Configure which Certificate Authority (CA) certificate will be used to decrypt the Secure Sockets Layer (SSL) encrypted traffic.
• Configure whether a specific SSL protocol will be inspected, blocked or bypassed.
• Configure which ports will be associated with which SSL protocols for the purpose of inspection.
• Configure which websites or website categories will be exempt from SSL inspection
• Identify how to treat invalid, unsupported or untrusted SSL certificates.
• Determine which inspection method will be applied to Secure Shell (SSH) / SSL traffic.

SSL inspection

Secure Sockets Layer (SSL) content scanning and inspection allows you to apply antivirus scanning, web filtering, FortiGuard Web Filtering, and email filtering to encrypted traffic. To perform SSL content scanning and inspection, the FortiGate unit does the following:

• intercepts and decrypts HTTPS, IMAPS, POP3S, SMTPS, and FTPS sessions between clients and servers (FortiGate SSL acceleration speeds up decryption)
• applies content inspection to decrypted content, including:
  • HTTPS, IMAPS, POP3S, and SMTPS Antivirus, DLP, and DLP archiving
  • HTTPS web filtering and FortiGuard web filtering
  • IMAPS, POP3S, and SMTPS email filtering
• encrypts the sessions and forwards them to their destinations.

FortiGate SSL content scanning and inspection packet flow

SSL inspection and privacy

Normally, SSL decrypted content is temporarily stored in system memory for content scanning. If Malware is found the infected content is deleted and a message is sent to the destination instead. If no Malware is found the content is re-encrypted and forwarded to its destination. Administrators are not able to access or view the decrypted content.

There are two exceptions that you should be aware of if you have privacy concerns:

• If Sandbox inspection is enabled, either with an on-premises FortiSandbox device or FortiCloud Sandbox, decrypted files can be sent to FortiSandbox or FortiSandbox cloud where they can be viewed by system administrators.
• For flow-based SSL inspection, if SSL mirroring is enabled it is possible to "mirror" or send a copy of the decrypted content to one or more FortiGate interfaces so that the content can be collected by a raw packet capture tool for archiving or analysis. This feature is only available if the inspection mode is set to flow-based.

Decryption, storage, inspection, and use decrypted content is subject to local privacy rules. Use of these features could enable malicious users with administrative access to your FortiGate to harvest sensitive information submitted using an encrypted channel.

For increased privacy of sensitive information, you can use the SSL inspection exemptions feature, described below, to exempt sensitive communication from decryption.

SSL inspection exemptions

When you are using a browser to visit SSL encrypted sites and are using a certificate that does not match the certificate of the site, you are presented with a warning message and the option of continuing with the untrusted certificate, or terminating the session. However, there are a number of applications that use SSL encrypted traffic. Some applications will not allow SSL traffic that isn't signed with a trusted certificate. These applications do not necessarily give the option to manually indicate that we trust the certificate or the site. If the option is available, the customer may choose to import needed SSL certificates into Local Certificates and configure a policy for communication for that application.

To assist in preventing loss of access to these sites while still enabling the SSL inspection of the rest of the internet traffic, a method of exempting either web categories or specific sites has been developed. To exempt a large group of sites, the SSL/SSH Inspection profile can be configured to exempt FortiGuard Categories. There are three preselected categories due to the high likelihood of issues with associated applications with the type of websites included in these categories.

• Finance and Banking
• Heath and Wellness
• Personal Privacy

Other more specific websites can be added to the exemption list by going to Security Profiles > SSL Inspection, selecting the appropriate profile, and adding addresses under Exempt from SSL Inspection.

When you create a custom web category and tell the inspection profile to exempt that category, you may find some URLs in that category are still inspected. As a best practice, use the Static URL filter "Exempt" option instead.

Your FortiGate unit has two pre-configured SSL/SSH Inspection profiles that cannot be edited: certificate-inspection and deep-inspection. You must clone and edit the pre-configured profiles or create a new profile to exempt any additional sites or FortiGuard categories.

Allow Invalid SSL Certificates

It might seem like a straightforward decision that the allowing of invalid SSL certificates must be bad and, therefore, should not be allowed. However, there can be some reasons that applying this feature should be considered.

At a purely technical level, a properly formed certificate will encrypt the data so that it can only be read by the intended parties and not be read by anyone sniffing traffic on the network. For this reason, people will often use self-signed certificates. These self-signed certificates are free and will encrypt the data just as securely as a purchased certificate. The self-signed certificates, however, are not likely to recognized by the CA certificate store so will be considered by any checks against that store as invalid.

On the other hand, one of the services the vendors provide is verification of identity of those that purchase their certificates. This means that if you see a valid certificate from a site that identified itself as being from “valid-company.com” that you can be reasonably sure that the site does belong to that company and not a false site masquerading as being part of that company.

You can allow invalid SSL certificates by going to Security Profiles > SSL Inspection, selecting the appropriate profile, and enabling Allow Invalid SSL Certificates.

During the SSL handshake, a number of checks are made to verify the validity of the certificate.

One source of the checks, is against a CA certificate store inside FortiOS. This is the same CA bundle used by the browser Mozilla Firefox.

Updates to the store are:

• With each new version of FortiOS
• Via internal FGD
• Possible with some builds via FTP

Details of the CA certificate store can be found at: https://curl.haxx.se/docs/caextract.html

The following checks are made for validity:

Validity Check	Description
Signature	One of the things being checked against the CA bundle is the certificate signature. These signatures are generated via directly signing by the CA's private key.
Expiration date	All certificates have an expiry date. The date, based on the devices clock/calendar is compared to the expiry date of the certificate.
Revoked list	Periodically, certificates are revoked. If a certificate has been revoked it is put on a list. Whenever a certificate is being verified, it is checked against this list.
Self signed certificate	In the case of self-signed certificates, the IPS engine and proxy have different handling. IPS engine will keep and use the certificate self-signed certificate, but the public key will be replaced so that SSL inspection can take place. The proxy engine will re-sign the certificate with the untrusted CA certificate. The mechanics are similar but the net effect for the user is similar. The user will get warnings from browsers. The users can choose to remember the self-signed certificate in some browsers, but cannot do the same thing with the certificate re-signed with the untrusted CA.
Intermediate CA with a weak hash algorithm, such as MD5, SHA1	Some browsers like Chrome or Firefox will give a warning because of a weak signature algorithm (visit https://sha1-intermediate.badssl.com to test). In the IPS Engine, in order to convey the weak intermediate CA back to client, the signature hash algorithm is downgraded in the re-signed server certificate to the weakest algorithm used in the original certificate chain. In the Proxy Engine - In the case of a weak signature algorithm, the Proxy engine will treat the connection as untrusted, and re-sign the server certificate with the untrusted CA. The final user experience is different. Instead of a warning like "NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM” that you would get in Chrome, you will get a warning that the certificate couldn’t be verified (because of the signing CA is not trusted or imported into the user’s web browser).

Flow-based behaviour

In flow-based mode, a certificate will be considered as invalid if it has expired.

In addition, a certificate will be considered as untrusted if one or more of the following conditions are met:

• If the chain is broken or incomplete.
• If it is part of the CRL.
• If the CA certificate was not imported to the FortiGate, or it is not in the FortiGate CA certificate store.