What is SSL Decryption?
SSL Decryption (or Packet Inspection) is the process of breaking open an SSL connection in order to inspect the full 'requested' URI and not just the domain that the end-user browsed to. For a service like Netsweeper, this allows greater security for your end-users, as well as more accurate filtering and reporting, allowing us to filter and report on paths, queries, search engine requests and more.
Decrypting 'in Band' traffic
In normal environments that are not being decrypted, a client device negotiates a secure connection with a remote web server via TLS, and transmits HTTP data.
SSL inspection, (or HTTPS decryption as it’s sometimes called,) is commonly done in educational environments, where devices are fully managed and it’s easy to push additional Root Certificates to the device.
In environments where SSL inspection is done, a "man-in-the-middle" interception is performed in order to make the client connecting to the listening interceptor believe the interceptor is the destination web host, which then forges the remote web hosts SSL certificates and delivers the same data as though it were the remote web host. This requires two things:
The interceptor can forge or sign using a self-signed certificate that is pushed to the client device.
Both request and response data must be transmitted inline via a decrypting proxy. Netsweeper describes its high speed decryption proxy (NSProxy) in the following NSProxy Configuration Overview, as well as a number of implications of secure web filtering.
Preparing 'Out of Band' Deployments for Decryption
Architecturally, customers who are 'out of band' will need to re-architect their network to be inline. Given that both response and request data is needed to be processed, and this is typically a 10:1 ratio in most networks, this implies that a 10x hardware resource increase should be expected. Given that this deployment must be inline and proxy decryption is computationally expensive, some latency increase should also be expected due to increased processing time, and possible queuing of packets. Lastly, load-balancing can be more complex, since generally one cannot simply filter out required packets, and instead load-balancers must be used to balance TCP flows of request and response data to your Policy Servers, as opposed to tapped ether channels that are often used with 'port-mirroring' (out of band) deployments.
Certificate Management
Finally, certificate management is likely a significant challenge that will not be easily overcome. SSL Inspection requires either using a Root CA certificate to forge user requests (there are only 60 of these in the world and generally these are protected very heavily,) or a self-signed certificate. It is generally not possible to do this with the Root CA Certificates that are available in common client device browsers (Mozilla, Chrome etc.), and operators will need to install a self-signed Certificate to client devices, which is typically infeasible at an Internet Service Provider scale.
Additional Considerations
Even assuming one can get past all these hurdles, operators can risk discontent from their users who will typically detect this.
Please reach out to your Netsweeper Account Manager, or to our sales team at sales@netsweeper.com to discuss this topic further.