TLS inspection and how it works

TLS Inspection allows you to decrypt TLS traffic so that it can be inspected.

The TLS protocol allows applications to communicate across a network in a way designed to ensure the confidentiality and integrity of the communications. HTTPS uses the TLS protocol to secure HTTP connections. When a browser connects to a server that uses HTTPS, the server sends a certificate to the browser. The certificate contains the server's public key and a digital signature from a certificate authority that verifies the server's identity. The browser and the server negotiate an encryption algorithm, which is used to create the encrypted connection.

The TLS Inspection feature consists of server protection and client protection. Server protection inspects incoming connections to servers in the protected network. Client protection inspects TLS outgoing connections initiated by clients in the protected network. TLS Inspection requires two separate secure connections: one from the client to the firewall and one from the firewall to the server. You can use client protection alone, server protection alone, or client and server protection together.

When a server in the internal network is the destination of an incoming TLS connection, the engine uses the server's credentials to decrypt and re-encrypt the traffic.

When a client in the internal network initiates a TLS connection to an external server, the firewall checks whether the server’s certificate was signed by a certificate authority that is considered trusted. If the certificate was signed by a trusted certificate authority, the engine makes a new certificate that matches the server's certificate. From the point of view of a user in the internal network, the process is invisible: the connection is established in the same way as a TLS connection made directly to the server.

When a server’s certificate is self-signed or has not been signed by a trusted certificate authority, the engine cannot trust the server certificate. In this case, the engine makes a new self-signed certificate. This certificate is presented to the user in the internal network. The user’s browser shows the same warning that it would show if it received a self-signed certificate directly from a server. In this case, the user must decide whether to accept the certificate.

In both cases, the engine adds a Netscape Certificate Comment to the Extensions in the certificate to indicate that the certificate is a dynamically created certificate for SSL/TLS deep inspection. Substituting the original server certificate allows the firewall to decrypt and re-encrypt the traffic.

After decrypting the traffic, normal HTTP inspection and optionally malware scanning are applied. If the traffic is allowed to continue, it is re-encrypted before it is forwarded.

Limitations

TLS inspection has the following limitations:
  • TLS inspection for client protection cannot be done for traffic picked up through Capture interfaces.
  • TLS inspection for server protection can be done for traffic picked up through both Capture interfaces and Inline interfaces.
    Note: Due to security features of the TLS protocol, TLS decryption for traffic picked up through Capture interfaces can only be done when RSA key exchange negotiation is used between the client and the server.
  • TLS inspection is not supported on Single IPS engines or on Single Layer 2 Firewalls if the engines are deployed alongside a Firewall Cluster that uses dispatch clustering.
  • Default Trusted Certificate Authority elements are automatically added to the SMC from dynamic update packages and cannot be edited or deleted.
  • TLS inspection is not supported on Master NGFW Engines.

What do I need to know before I begin?

Consider these things before configuring TLS inspection:
  • Traffic that uses TLS might be protected by laws related to the privacy of communications. Decrypting and inspecting this traffic might be illegal in some jurisdictions.
  • The TLS communications mediated by the engine are decrypted for inspection, and the private keys of the servers are stored unencrypted in the TLS Credentials elements on the Management Server and on the engine. For these reasons, you must carefully consider security precautions when using TLS inspection. The following recommendations are general guidelines for ensuring the security of the engine and the SMC:
    • Run the Management Server on a hardened operating system.
    • Disable SSH access to the engine’s command line.
    • Make sure that the engine’s Control IP address is in a protected network.
    • Save Management Server backups as encrypted files.
  • When a certificate for client or server protection has been uploaded to the engine, it is possible to unintentionally enable TLS decryption for all traffic in one of the following ways:
    • Adding a Network Application that allows or requires the use of TLS to an Access rule
    • Enabling the logging of Application information in the Access rules
    • Enabling Deep Inspection in an Access rule with the Service cell of the rule set to ANY
  • Strict TCP inspection mode is automatically applied to TCP connections when TLS Inspection is used.