What Is SSL Web Inspection and Where Should It Occur? (Part 1)

Note: For the purposes of this blog series, the terms “SSL” and “TLS” will be used interchangeably.

SSL inspection is the process of “proxying” a SSL session in order to decrypt the traffic and monitor/inspect it against various controls. Network traffic is increasingly going over encrypted channels, and the investments organizations have made in network security and monitoring solutions are becoming less and less effective since they can’t see inside an encrypted payload. Consequently, network and security teams are becoming increasingly more blind to what is on, coming into and leaving the network. Companies are using endpoint solutions to provide protection and visibility, but that is only half of the solution. There are things that an endpoint technology will not see that require network-based SSL inspection.

SSL inspection means different things to different organizations, so let’s start there. SSL inspection can mean any protocol over any port (SPDY, IMAPS, FTPS, POP3S) or just the HTTP protocol. Depending on what you want to do will help determine which vendors to consider, as well as sizing. Most organizations only focus on HTTP, so that will be the focus of this series. Please note that web traffic does not have to use the HTTP protocol. Therefore, it may not be applicable for SSL inspection (e.g. Google uses the quic protocol between Chrome browsers and Google services).

Inspecting SSL traffic requires CPU, memory, code to support cipher strings and sessions. Basically, it requires hardware to do the math and track the sessions, but hardware is only one component an organization needs to consider. Others are placement, operational overhead, existing PKI infrastructure, etc. Some of these factors aren’t easily quantifiable because they are variables that differ between organizations. Hardware, software and the computational cost associated with inspecting SSL is a little easier to decipher.

A major pre-requisite for SSL inspection—which often is overlooked—is a functional PKI infrastructure. While PKI is not the focus of this discussion it is worth mentioning some basic concepts that need to be met. At a minimum, a secure Certificate Authority (CA) hierarchy and browsers/applications configured to trust those CAs are needed. This creates the trust between the browser and inspection device (discussed below). Typically, organizations create one or more Subordinate CAs and Issuing CAs while the Root is stored offline.

All versions of the SSL protocol are no longer considered secure and TLS is recommended as the replacement. TLS is the framework that encryption, authentication and integrity of the payload work within. TLS/SSL sit on top of the HTTP protocol, and the sole purpose of SSL inspection, regardless of equipment, is to ‘strip’ away SSL/TLS to see the HTTP packet. SSL/TLS traffic is made up of a handshake and payload (transport layer). The handshake contains cipher negotiation, compression methods, certificate exchanges (server and client) and certificate verification. Client and server authentication via certificate happens during this phase. Client authentication via certificate makes SSL inspection very hard to implement and typically is exempt from inspection. The most common method of authentication is done on server.

During the SSL/TLS handshake the server is authenticated via a certificate. Simply put, the server’s certificate is presented to the client, which confirms that: 1) the server name in the certificate matches the server name in the URL; 2) the certificate has been digitally signed by a trusted CA; 3) the certificate has not expired; and 4) the certificate has not been revoked by the CA. If all these conditions are not met, the user is presented with a warning message that the certificate is not valid. (Note that there are other requirements, such as cipher strength, hash algorithm, etc., that can cause a certificate to be invalid. We are just listing the most common ones here for brevity.) Certificate Revocation List (CRL) and Online Certificate Status Protocol (OSCP) have mixed use depending on the browser, but most SSL inspection devices do not enable OSCP or CRL checking by default. The primary factor for this is due to the latency revocation checking introduces.

After the certificate is validated the payload encryption cipher is negotiated, and symmetric keys are exchanged. Once this occurs, a new encryption session is created for the payload portion.

In order for these things to work the device doing the inspection must support the ciphers enabled on the browser and server. Modern browsers will typically support a wide range of ciphers within TLS 1.x. Below is a brief review of common ciphers and cautions.

Encryption:

• AES GCM 128
• AES GCM 256
• AES CCM 128
• AES CCM 256
• ChaCha20-Poly1305
• 3DES is still supported by browsers but insecure because its effective strength is 112 bits
• RC4 is available in SSL, but prohibited by TLS
• Null should not be supported because it does not provide any encryption Authentication:
• TLS_DH_anon and TLS_ECDH_anon do not provide authentication
• TLS_DHE and TLS_ECDHE provide forward secrecy

Integrity:

• AEAD is supported in TLS 1.2 and used for GCM and CCM ciphers
• SHA1 is still widely used, but browsers will stop supporting this algorithm in 2017
• SHA2 is the recommended successor to SHA1

In the second post of this blog series, I’ll dive deeper into how SSL inspection solutions work and metrics that can be put in place to measure effectiveness.