Technical Note: Differences between SSL Certificate Inspection and Full SSL Inspection

[vrajendran]

Description
This article helps to decide the better content inspection to be used depending on the needs.


Scope


Solution
Background:

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communication security over the Internet. They use X.509 certificates and hence asymmetric cryptography to authenticate the counterpart with whom they are communicating, and to exchange a symmetric key. This session key is then used to encrypt data flowing between the parties.

As a consequence of choosing X.509 certificates, certificate authorities and a public key infrastructure are necessary to verify the relation between a certificate and its owner, as well as to generate, sign, and administer the validity of certificates.

Since protocols can operate either with or without TLS (or SSL), it is necessary for the client to indicate to the server the setup of a TLS connection. There are two main ways of achieving this.
One option is to use a different port number for TLS connections (for example port 443 for HTTPS).
The other is for the client to request that the server switch the connection to TLS using a protocol-specific mechanism (for example STARTTLS for mail and news protocols).

Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure.[6] During this handshake, the client and server agree on various parameters used to establish the connection's security:

1) The client sends to the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.

2) The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate.

3) The client uses the information sent by the server to authenticate the server—e.g., in the case of a web browser connecting to a web server, the browser checks whether the received certificate's subject name actually matches the name of the server being contacted, whether the issuer of the certificate is a trusted certificate authority, whether the certificate has expired, and, ideally, whether the certificate has been revoked.[7] If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to the next step.

4) Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher in use) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.

5) If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.

6) If the server has requested client authentication, the server attempts to authenticate the client. If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.

7) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).

8) The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.

9) The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.

The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.


SSL Certificate Inspection:

When using SSL Certificate Inspection, the SSL Handshake is not interrupted, but the FortiGate reads the CN part of the certificate. This CN part, has the URL for the certificate was signed to. This way, the FortiGate has an URL to check into its categories database. But the TLS/SSL content is not read in any way as explained in the background section. Once the SSL/TLS session is established, there's no way to read its content.

Full SSL Inspection:

When using this kind of inspection, the FortiGate unit takes place of the server (from the point of view of the client) and for the server, the client is the FortiGate, not the PC. In this schema, is clear that the SSL/TLS handshake is interrupted, and the FortiGate is required to present a certificate for the URL requested by the real client. This certificate is signed by the FortiGate itself. As the FortiGate is usually not a recognized Certificate Authority (CA) to sign certificates a warning message will be shown to the client stating that the signer of the certificate is not a recognized entity.

When using this inspection, the traffic flows from server to the FortiGate encrypted, and from the FortiGate to the client is also encrypted. The only part where the traffic is unencrypted is into the FortiGate for inspection purposes.

This is the purpose for Ful SSL Inspection, to inspect the downloaded content. While SSL Certificate Inspection inspects only the URL (which suites perfect for web filtering only), is not designed to identify attacks, viruses or applications. This features are available on Full SSL Inspection.

But it is needed to be clear that the Full SSL Inspection the certificate used to sign those sites (by default SSL_Proxy_Inspection into the FortiGate) is needed to be recognized as a valid CA. Otherwise, the warning message will be shown everytime an SSL/TLS connection is made.

This certificate (SSL_Proxy_Inspection) must be installed in each PC to be used by their Operating System and/or for browsers/applications (Mozilla Firefox or Java JRE) which has its own Certificate repository.

Conclusion:

If webfilter only is required, SSL Certificate Inspection is the correct option.
If webfilter, identify attacks, viruses and application control are required, then Full SSL Inspection is the best option.