Every Solution You Can Imagine – and More
What cybersecurity solution do you need? From Zero Trust to ADR, IAM, risk/privacy, data protection, AppSec and threat, securing digital transformation, to resiliency and remediation, we can build the right program to help solve your challenges.
A Single Partner for Everything You Need
Optiv works with more than 450 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv
Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner.
However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
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.
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.
Let us know what you need, and we will have an Optiv professional contact you shortly.