Engineering

SSL Decryption without PAC files

/ securlyinc / Leave a comment

ee0ddc_00bc58c839464978bc251e28edd6d777.jpg_srz_634_310_85_22_0.50_1.20_0.00_jpg_srz

If you have endured the pain of deploying Proxy Auto-Configuration (PAC) files, get ready to jump for joy! Beginning May 30th, Securly is pleased to announce the “Death of PAC Files”.

As you may know, Securly was founded on the premise of a simple 5-minute deployment. A web filter for schools that IT admins can truly set and forget. As we have evolved as a company, a major impediment to the realization of this vision has been the use of PAC files for those of our customers who deploy Securly for in-school (DNS based) filtering.

To understand how we ended up here, its helpful to trace through our technical evolution:

  • We first started off as a DNS-to-proxy web-filter. Simply put, we use DNS queries to selectively proxy domains that need to be filtered. In slightly more technical terms, when our DNS server receives a query for a domain like google.com or facebook.com, we “lie” to the client about the resolution and instead point to the IP address of one of our proxies.
  • Our core backend engine uses the industry standard – tried and tested Squid open-source web-proxy. Needless to say, we have had to heavily modify Squid over time to get it to perform all of the magic (Google SSO, per policy filtering, etc) that our customers have come to rely on. An essential and early innovation we introduced on the Squid side was industry-first transparent HTTP and HTTPS proxying. Out of the box, Squid relies on the configuration of an explicit proxy at the browser level. The core Squid engine had to be modified to accept unproxy-ed HTTP and HTTPS traffic.
  • Very soon, we ran into the need to decrypt HTTPS traffic due to the following reasons (i) web-sites that YouTube and Yahoo that need HTTP header/cookie insertion to enforce Safety Mode (ii) web-sites like Facebook and Twitter that needed to be allowed for staff, but blocked for students.
  • We tried and failed very early on to achieve transparent HTTPS decryption (which is quite different from transparent HTTPS proxying). However, the numbers spoke for themselves (500 support tickets over one year re: PAC files alone) when it came to the pain our customers were going through as a result of these PAC files.
  • Although the use of PAC files has becomes the industry norm, we realized that to reduce friction for customers (and to make the product easier to support), we simply had to solve this problem. We engaged the services of a industry leading crypto expert who build transparent HTTPS decryption for us. We are in the process of integrating his work back into our technology.

We believe that completely getting rid of PAC files while retaining SSL decryption abilities is nothing short of magic and are thrilled to announce that our customers will experience this for themselves very soon. 

Should you have any questions about this change, please do not hesitate to contact us at support[AT]securly.com.