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

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

Architecture

Note: This is not focusing on the ‘security effectiveness’ of different solutions.

Hardware will vary between vendors and even different models within a vendor’s catalog. Some models/vendors will offload complex CPU tasks (decryption/encryption) to dedicated CPUs while some models/vendors will use software, but they rely on the same hardware that non-encrypted traffic shares. That being said, cloud content filtering solutions remove the need for sizing equipment to decrypt SSL traffic since the inspection is done within the provider’s environment.

All-in-one security appliances (NGFW) typically provide performance metrics that do not factor SSL inspection and, if applicable, use a fast-path architecture. Since SSL traffic is prevalent on the networks today, vendors are providing specific SSL metrics outside of the other performance metrics. Once SSL inspection is factored performance metrics decrease and any fast path architecture is negated. Primarily throughput (CPU), SSL session table size and transactions/second are factored into any sizing effort.

Purpose-built solutions, or solutions that focus on manipulating SSL, leverage dedicated hardware components that concentrate on decrypting/encrypting SSL traffic. Dedicated SSL ASICs that handle the handshake and payload decryption/encryption are almost always found since SSL creation and termination are very resource intensive. In addition to dedicated ASICs, these devices are designed (software and hardware) to be a proxy.

Cloud providers simplify sizing and PKI but can complicate the architecture somewhat. The discussion becomes less about ‘how much can I afford to decrypt’ and more of ‘how do I get my traffic to the provider.’ This can be handled in traditional ways of a proxy by using PAC files, hard coding the browser, or by using agents. There also is traffic forwarding via IPSEC tunnels, proxy-chaining or policy-based forwarding.

How It Works

In order for a solution (purpose-built, all inclusive or cloud) to do web SSL inspection it must be able to do a few basic functions:

• Categorize web traffic to know what to decrypt and what to pass through
• Support cipher strings and key sizes used by the internal organization and public destination (discussed above)
• Have a certificate to decrypt the packet to make the traffic HTTP
• Recreate sessions between the end user and the device as well as the device to the destination (proxy)

Certificate inspection is basically the first bullet point mentioned above. It will look at the handshake and try to align that with a URL filtering profile. Since the full URL is not visible, the device will need to look at certificate Common Name (CN), Subject Alternative Name (SAN), SNI, domain name, and/or destination IP address and attempt to match that to a web category. This inspection does have some limitations:

• It is only applicable for HTTP traffic.
• It isn’t 100 percent accurate (think wildcard certs and FQDN mismatch).
• There is no payload inspection.
• Granular control within a web application is very limited.

If the organization’s requirements are only applying a basic URL filtering profile to HTTPS traffic there is no need to look at purpose-built hardware. All-inclusive devices can do this with little impact to performance, because it is only looking at the server certificate and does not process anything else beyond the handshake session. Payload inspection is not in scope. Cloud providers will do this by default and will not require additional licensing.

Another consideration within this approach is certificate exclusion. Certificate exclusion is a list of hostnames found in the certificate CN or SAN that you do not want inspected. The use case for this approach is applications that do not function if they are SSL inspected, or are against company policy due to sensitive information being processed within it.

For full SSL inspection, the device will act as a proxy (MITM). The device will act as a server to the end user as well as a client to the destination server, so for every client connection to an encrypted site, the device will create two sessions at a minimum.

The device will need to be able to generate trusted certificates for every URL that is being visited. To accomplish this, the device will need to be a trusted CA for all clients. Also, the device must be able to create and sign these SSL/TLS certificates (subordinate CA) in “real time,” which can be computationally expensive. With the transition to 2048-bit keys, devices can do 1/5 the transactions per second as before with 1024-bit keys. You can create 1024-bit keys internally, but this is no longer a best practice or a long-term solution for sizing. Packet size will also determine the capacity of transactions per second as well as throughput. Smaller packet sizes allow more transactions per second, but reduce the overall throughput through the device. The inverse is true for larger packet sizes. In summary, full SSL inspection has a computational “cost” on hardware, but is dependent on an organization’s traffic types and patterns.

Cloud providers alleviate the need for sizing and supporting on-premise equipment, but require the organization to either 1) install the provider’s certificate to all browsers so the provider is a trusted CA, or 2) provide a subordinate CA certificate to the provider to use. Most organizations choose to distribute the provider’s certificate to browsers. Also, most cloud providers require additional licensing for full SSL inspection. Some cloud providers have limited ability to inspect SSL traffic payloads or only provide a subset of ‘grey’ list sites where it is even possible.

Metrics

All-in-one devices will have very different numbers of overall throughput (no SSL inspection) vs. SSL inspected throughput. A misconception is to reduce the overall throughput by half and that will get close to SSL inspected throughput, but that has not been consistent. The other inspections being done by the device, Transactions Per Second (TPS), and packet size are the primary reasons for this not being true. As mentioned above, small packets will allow more TPS, but requires more compute for SSL handshakes as well as other inspections configured. An overlooked metric, but probably one of the most important to consider, on all-in-one devices is the SSL session limit. In the simplest example, each inspected connection consumes two sessions at a minimum. Once this limit is reached, SSL connections will either be dropped or passed through uninspected.

Purpose-built devices will have varying metrics as well, but it primarily depends on the deployment model being used. This has more to do with Tx and Rx numbers, TPS, how the connected device is deployed (active vs. passive), than total packet throughput of the chassis (e.g. 5Gbps total packet throughput of chassis, but 1Gbps SSL inspection throughput). Since the device does not inspect the payload of a packet the size is not as relevant. However, packet size due to fragmentation will directly affect the TPS metric.

In summary, throughput calculations should be collected and tested from the vendors in scope, as they vary by manufacturer as well as deployment mode.

In the third and final post of this blog series, I will discuss the benefits and downsides of SSL inspection, and how to put a plan in place for your organization.