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.