Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
ssl_inspection [2018/07/11 14:35]
mnantel
ssl_inspection [2018/07/11 14:35] (current)
mnantel
Line 1: Line 1:
 ==== Fortinet SSL Inspection ==== ==== Fortinet SSL Inspection ====
 +
 +This page presents references for SSL inspection on the FortiGate platform.
  
 == Design & Best Practices == == Design & Best Practices ==
Line 14: Line 16:
  
  
-As with any security feature there are numerous options available for the configuration of SSL Deep Inspection, with the configuration determining the amount of traffic that is decrypted for security inspection. Clients using the feature will need to determine which configuration level they wish to deploy, in order to balance performance and ease of management vs. the risk of not decrypting all traffic. 
- 
-With the rapid rise in the percentage of Internet traffic the SSL encrypted a large security gap has been created in many organizations,​ where their security appliances have lost visibility into the content entering and leaving the organization. With TLS traffic making up between 60-80% of all traffic it is critical that this traffic still be subject to security inspection in order to maintain an acceptable security posture. Gartner predicts that in 2018 we’ll see that 50+% of attacks will use encrypted channels. With free certificate authority services now becoming available, this percentage is expected to grow further. 
-Many modern security appliances have incorporated the ability to perform SSL Inspection, by proxying the sessions and decrypting & re-encrypting all sessions as they traverse the appliance. 
-To make sure that all SSL encrypted content is inspected, one 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. 
-However with the increasing ciphers and key lengths the resource requirements to process a significant amount of TLS pose a significant challenge to existing deployments. Fortinet leverages specialized ASICs to assist with this decryption, but it is also taxing on that ASIC and the same ASIC is used for security inspection functionality,​ so while the performance impact of SSL inspection on a FortiGate appliance is not as drastic as on purely CPU-based firewalls, it is still a very significant impact on overall processing capacity. 
-The help clients maximize their investment in the FortiGate appliances Fortinet also offers the ability to do external SSL inspection on hardware accelerated FortiADC appliances. With a full forward SSL proxy feature the FortiADC can be used to do the SSL decrypt/​encrypt with its ASICs and pass the unencrypted traffic through the FortiGate, which can use its ASICs for security inspection. This allows correctly sized FortiGates to continue to be used with a much lower expense of adding a FortiADC component. 
- 
-===== Fortinet SSL Full Inspection ===== 
- 
- 
-To make sure that all encrypted content is inspected, you must use full SSL inspection (also known as deep inspection). FortiGate appliances support the decryption and re-encryption of passed SSL/TLS sessions to provide visibility into encrypted traffic flow. This feature greatly increases the security posture of the protected network since TLS traffic is leveraged to carry many attacks, however, it also increases the complexity of the deployment. 
-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. 
- 
-The FortiGate does SSL inspection using one of two engines, the WAD daemon for Proxy and the IPS engine for Flow. These engines operate in different modes towards the same purpose, the decryption of TLS traffic for inspection by other engines, however, since one is proxy and the other flow, their capabilities differ. Additionally,​ the IPS engine on the FortiGate is updated more often as it is decoupled from the firmware upgrade process, hence it can respond more quickly to changing threats as well as changes in TLS. 
-TLS inspection does take significantly more resources on an appliance when enabled and this additional performance load needs to be considered when enabling this feature. The load has also changed over time as the TLS ciphers, extensions and key lengths have changed, generally for more complex and longer ones, requiring more compute power to decrypt/​re-encrypt. 
-The FortiGate supports two modes for SSL full inspection, one for outbound inspection of traffic going to servers that are not owned by the organization and are out on the internet, and one for inspecting traffic, generally inbound, to a server owned by the organization. These two options are presented in the SSL/SSH inspection profile in the FortiGate configuration. 
- 
-**Option 1: Multiple Clients Connecting to Multiple Servers:** 
-This is the typical mode used to protect users surfing HTTPS sites or using TLS protected applications where the destinations are unknown. It uses a CA certificate (which can be uploaded using the Certificates menu) and address and web category whitelists can be configured to bypass SSL inspection for trusted sites as well as sites known to break SSL inspection due to the caveats discussed below. 
- 
-**Option 2: Protecting SSL Server** 
-This mode uses an actual server certificate (which can be uploaded using the Certificates menu) to protect a single server (or load-balanced virtual server). It is 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. 
- 
-===== Fortinet SSL Certificate Inspection ===== 
- 
-It should be noted that FortiGates also supports a second type of SSL inspection, called SSL certificate inspection. When certificate inspection is used instead of Full Inspection, 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. This leverages the Server Name-Identifier (SNI) field of the certificate,​ to obtain the FQDN name of the server being targeted. 
-It is important to realize that in this mode the only security feature that can be applied using SSL certificate inspection mode is web filtering. This form of inspection does not have access to neither the full request URL nor any packet payload/​content. Therefore it does not greatly increase the security posture of the organization,​ with the main benefit being the ability to do FQDN level FortiGuard category based filtering – for instance blocking HTTPS-based sites that fall in the Malicious site category. 
-However, since only the packet is inspected, this method does not introduce certificate errors and can be a useful alternative to full SSL inspection when web filtering is used. This would be the bare minimum option to enable even if one is not able to or desire to perform SSL Inspection, however, the recommendation is to leverage full SSL Inspection. 
- 
-====== SSL Full Inspection Caveats ====== 
- 
-This section describes limitations to full SSL inspection, describing conditions that make the use of it impossible. 
- 
-===== Client-Side certificates ===== 
- 
-Typically in a TLS session only the server has a certificate that it uses to present to the client. The client itself does not have a certificate. However, TLS does support both sides having a certificate. If client-side certificates are in use SSL full inspection cannot work. If the client shows a certificate and uses his private key as part of a CertificateVerify message (as described in the SSL/TLS standard, section 7.4.8), and the server validates the client certificate with regards to a set of trust anchors which does not include an hostile or incompetent root CA, then the server has a guarantee that it is talking to the right client (the one identified by the client certificate). 
-This means that a client certificate indeed protects against the specific scenario of a MITM CA injected in the client trust store. In that scenario, the FortiGate succeeded in making the client trust a specific root CA that is organization controller, allowing the FortiGate to run a MitM TLS inspection by creating on- the-fly a fake certificate for the target server. However, such MitM breaks client certificate authentication,​ because what the client signs as part of a CertificateVerify message is a hash computed over a lot of data, including the server certificate -- in the MitM scenario, the client does not see the "​right"​ certificate and thus computes a wrong signature, which the server detects, and the TLS connection fails. 
-Hence applications using client side certificates cannot be used with full SSL inspection. 
- 
-===== Certificate Pinning ===== 
- 
-Typically in a TLS session the client will trust/​accept certificates that are generated with a trusted certificate chain, by any CA that is in the client’s trusted certificate store. Some applications employ Certificate Pinning to prevent man-in-the-middle attacks. This means that the certificates and CA that the FortiGate uses for TLS inspection will not be accepted by these applications. This is common for applications like the IOS and Android app stores and desktop applications that use TLS but are not browser based, like the dropbox client. Pinning leverages knowledge of the pre-existing relationship between the user and an organization or service. Therefore it is not used by general web sites that use generic clients like a browser. It is recommended to use the passthrough feature in order to prevent the FortiGate from intercepting traffic for these specific applications. 
-And so the rule of thumb is if you want to MITM an app you are going to need to force your users to use the browser version of the app (i.e box using a browser vs the box app). 
-From a deployment and control perspective,​ using the Application control rules, what you can do is deny these apps with a policy and then allow the web or https version of these application (using FQDN or other pointers) through instead. Then the MITM can be applied and then SSL Inspection policies can be applied to those connections 
- 
-===== QUIC ===== 
-Browsers like Chrome now uses QUIC by default (a UDP based encapsulation/​encryption comm) when accessing most if not all Google sites. No way to MITM this at all, you need to block this port on the FW (we have this defined in our services today) and it will then force Chrome to revert back down to TLS 1.2 or TLS 1.1 depending on the site being accessed. FireFox and IE does not have this issue and therefore you will generally find better experiences MITM these connections without any policy additions. 
- 
-===== ChromeBooks ===== 
- 
-Many organizations are deploying Chromebooks for internal usage. Google’s strict implementation of certain features on the chrombook (like HSTS) makes it difficult for full SSL inspection to be done on them. HSTS is HTTP Strict Transport Security, which is a web security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking. Google states in its documentation that the configuration will support authorized MITM (full inspection),​ but only in a proxied-configuration,​ and not in a transparent,​ or in-line proxy setup. Therefore if you have a large population of Chromebooks that required SSL full inspection, you will need to use Fortinet’s explicit proxy feature with SSL full inspection for them. Please see https://​support.google.com/​chrome/​a/​answer/​3504942?​hl=en 
- 
-===== TLS 1.3 ===== 
- 
-TLS 1.3 was originally drafted in 2014, and became an official draft on March 21, 2018. It’s aim is to improve security and various browsers and servers have supported pre-draft TLS 1.3 for over a year. However, it introduces challenges in SSL full inspection, (ie. using a unique key for each session), and since it was still changing due to its pre-draft status, currently FortiOS bypass full SSL inspection for TLS1.3. 
- 
-====== SSL Full Inspection Configuration ====== 
- 
-===== Trusted Signing Certificates ===== 
- 
-When enabling full SSL Inspection the first important and fairly complex piece of the configuration is the generation and deployment of the CA certificate that will be used by the FortiGate to present to clients. 
-There are two options here, one is to use the built-in SSL Inspection certificate that comes with eachFortiGate. These are built-in for this purpose, but in order to be used without generating browser errors they need to pushed out to all users devices and placed the the trusted CA certificate stores. This can be accomplished using various methods inlcuding MDM, WUSS, Domain Policies, etc. This will ensure users do not get browser error warning of an untrusted certificate authority, as below. 
- 
- 
-{{wiki:​certtrustissue.png?​nolink&​400 |}} 
- 
-The second option is to leverage an already trusted internal CA used by the organization. Since the CA certificate required needs to have wildcard signing authority (ie. sign for any domain), such a certificate cannot be purchased from certificate providers, as it would allow attackers to use SSL interception. Therefore an internal CA for the organization needs to be used to generate this certificate. The benefit of this option is that the certificate authority will be trusted by internal users already since it is the organization’s CA. Since this certificate also offers more controls in terms of dates and expiry and is internal to the organization,​ this is the recommended approach if an organization has a CA. 
-To see the details of this aspect of the configuration please see: 
-http://​cookbook.fortinet.com/​preventing-certificate-warnings-cacert-56/​ 
-Certificate status passing 
- 
-Another important configuration aspect is the correct passing of certificate status to the user. With SSL inspection the client receives the certificate from the FortiGate and does not see the true target server certificate. If the target server certificate is invalid or untrusted it is important to pass that message to the user. The FortiGate can be configured to do this with via the use of multiple certificates and the use of an internal CA trusted certificate store on the FortiGate. The organization needs to ensure that the certificate authorities trusted by the FortiGate are the same as those that are trusted by the organization and its users. 
-When configuring full SSL inspection in the GUI you have the option to Allow or Block untrusted certificates,​ as well as enabling or disabling Invalid SSL Certificates. These can be done on a per protocol basis in the CLI (ie, for HTTPS, FTPS, IMAPS, etc. individually if needed). Generally using the same setting across all protocols is recommended for visibility and simplicity. 
- 
-Client-Side Certificates 
-In the CLI configuration for SSL inspection you can also set if you want to block or bypass connection that have a client-side certificate components. As mentioned in the caveats above this can often break full SSL inspection, hence the default setting is to bypass those connections from SSL inspection so they can continue. You can set that to block in high-security environments if you know that no client-side certificates should be used with the applications that are authorized. 
- 
-Untrusted Certificates 
-The FortiGate maintains a Trusted CA List (which is editable in the GUI SSL/SSH Profile). This is the same CA bundle used by the browser Mozilla Firefox. It is used by the FortiGate to check is the original destination server certificate was issued by a trusted certificate authority, present in this list. 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. 
-If the certificate is deemed untrusted and the setting of Allow Untrusted Certificates is set to block – the connection is blocked. If the setting is set to allow, the FortiGate will sign the page to the client using its “Untrusted CA Certificate”. This will ensure that the user will see the certificate warning and will know that the site has an untrusted certificate. 
- 
-Invalid Certificates 
-The FortiGate performs validity checks on server certificates,​ and then depending on the condition and the inspection method does the following actions. The table below lists the validity checks done by the FortiGate. 
- 
- 
-{{wiki:​tablecert.png?​nolink&​400 |}}}} 
- 
- 
-Certificates with an invalid signature or passed expiration date are then considered to be invalid by the FortiGate. It will then perform the action based on the SSL profile setting for allowing invalid certificates for that connection. 
- 
-Log SSL Inspection Anomalies 
-This setting should be enabled to ensure that any seen sessions with invalid or untrusted certificates are logged as an SSL anomaly for easy analysis and reporting. 
-Inspecting All-Ports 
-By default the FortiGate inspects the standard ports for each protocol (HTTP – TCP/443, etc.). This applies to the SSL inspection profile to determine which ports to try to decrypt with full SSL inspection. In high-security environments it is recommended to inspect all ports to see if any non-standard ports are being used for SSL/TLS traffic. This option requires more resources as an IPS engine pre-processor then scans all traffic on all ports looking for TLS protocol exchanges and based on the packet content determining the protocol. If it sees HTTP traffic and a TLS Client Hello on port 4443, it will then pass that session to the SSL inspection engine for processing. 
- 
- 
-SSL Full Inspection Bypassing 
-When enabling full SSL Inspection another important aspect is the configuration of the SSL inspection bypass options. Full SSL inspection has significant resource consumption implications that increase with the volume of SSL traffic inspected, therefore enabling the inspection of all SSL traffic will have a large impact on the performance of the FortiGate. To balance security and performance aspects without deploying new hardware bypassing can be used to limit the amount of traffic being SSL inspected. Additionally,​ as described above certain sites and applications need to be bypassed in order to work correctly. At that point it is a decision that needs to be made of usability versus security, as those applications that cannot operate with SSL full inspection can pose a risk to the organization since they bypass threat inspection. 
-Bypass on the FortiGate can be configured in three ways, described below. 
-Reputable Sites 
-This is a simple on/off bypass. Enabling it allows the operator to automatically bypass all websites identified by FortiGuard as reputable from SSL inspection. The IP reputation feature can be enabled from the Feature Visibility section of the GUI, and when enabled the user can input any FQDN or IP into the query box to see what reputation FortiGuard assigns that IP. However, the operator does not have fine grained control over the sites being exempted, as the list includes all sites rated as reputable by FortiGuard. This will include the websites of most Fortune 500 companies. These sites are validated on a regular basis by Fortinet’s FortiGuard web rating system. 
-Web Categories 
-This section allows the additional exemption from SSL inspection using FortiGuard web categories as the factor for exemption. Using category based exemptions allows for further tailoring of what traffic will end up being SSL inspected, based on organization requirements and risk tolerance. By default in a full SSL Inspection profile the categories of Finance and Banking, Health and Wellness, and Personal Privacy, have been added as these are one that are most likely to have applications that will require a specific certificate. These are often also mandated for exemption by many companies’ privacy policies, although 
- 
- 
-the FortiGate does re-encrypt the traffic after threat inspection. However, certain features, like DLP, SSL packet mirroring, etc. could be configured to keep some information from sessions that are SSL Inspected. 
-Addresses 
-The address section allows the use of address objects for specific exemptions. These can be any of the Address objects that have an interface of “Any” in their configuration. Address objects include IPs, IP subnets, FQDNs and Geo-Addresses (Countries) as well as wildcard FQDNs (ie. *.windowsupdate.com). All these object types can be used to perform very fined-grained SSL full inspection exemptions. However, this type of exemptions should be limited to very specific needs as managing a large list of individual site exemptions gets cumbersome as well as impractical. 
-Log SSL Bypass 
-If using SSL full inspection exemptions, it is strongly recommended to enabling the logging of SSL inspection bypass sessions and run regular reports against these logs to see the amount and type of traffic being exempted from SSL inspection to ensure it is aligned with organization risk tolerance and security policies. 
- 
-SSL Full Inspection Bypassing 
-SSL Full Inspection Levels 
-The above sections explained various aspects of SSL Inspection and its high-level configuration. This section outlines 4 SSL Inspection configuration levels, that each provide a successive higher level of security, while requiring more resources on the appliance and more management of specific exemptions. Note unless otherwise mentioned all the profiles below have the “client-cert-request” option set to bypass, to ensure that any applications that use a client side certificate are successful. 
-Level 0 - SSL Certificate Inspection Only – high risk exposure 
-The most basic and fundamental level of SSL Inspection would be the inspection of certificates for SNI and hostname information. This allows the Webfiltering to inspect the all certificates and at least be able to do category blocking to block known malicious categories. This is the baseline configuration that should be in place if no SSL full inspection is possible. Also, please note, savvy users can bypass SNI filtering, by removing or modifying the SNI field using specific tools or plugins and most servers are currently configured to proceed with the handshake even if no SNI information is sent by the user. 
- 
-{{:​sslprofile.png?​nolink|}} 
- 
-Please note the Untrusted SSL Certificates are blocked to ensure that if a site is not reporting the correct SNI to avoid category-based blocking, it will be blocked. This will cause issues with sites (usually internal) using self-signed certificates,​ and a policy without this profile may have to be created for internal websites (such as management dashboards) that use self-signed certificates. 
-Level 1 - SSL Full Inspection – Limited Scope – medium risk exposure 
-Level 1 is the first level in which SSL inspection is enabled, however the scope is very limited through the use of category-based whitelisting to only inspect a small subset of sites. Please note that this is not limited to sites blocked by web-content filtering categories, since those blocked sites based on the certificate inspection already. Hence this is more important for sites that are not blocked on category, but rather need to be inspected for content, and hence need to be SSL decrypted. 
-In this case we’ll only be inspecting a few categories known for commonly being higher risk due to the large amount of file transfers from those sites. Note, this still leaves a large blind spot for millions of sites that could have been compromised with drive-by downloads and malware, but focuses on eliminating the riskiest aspects of the internet, while limiting the amount of traffic decrypted. 
-Additionally,​ please note that if you are already blocking some of the categories to be decrypted, there is no need to inspect/​decrypt them since they will be blocked by the webfilter by their category regardless. 
- 
- 
-However, since the GUI is used to whitelist, not blacklist inspection, you need to add all the categories except the ones above to the whitelisting configuration under Web categories. 
-Additionally,​ enable the whitelisting of reputable websites. 
-Also in this case you can enable the permission of untrusted certificates,​ since certificate status will be passed on to the user, using the resigning with an untrusted certificate,​ so they can see the risk. 
-For audit purposes you’ll want to enable the logging of the bypasses and invalid certificates via the SSL/SSH profile.