Over the past few years more websites have been adopting HTTPS over HTTP. Traditionally, HTTPS was used only for sites where sensitive information such as credentials and credit card details were transferred. But now, sites, institutions and individuals are requiring better privacy control, and a new movement has emerged to encourage HTTPS everywhere.
There are many reasons why HTTPS everywhere is a good thing, from protecting your credentials when using coffee shop wifi to helping web masters protect their own sites.
The HTTPS everywhere movement has so far been quite successful with most of the major web properties adopting HTTPS/SSL, including Google (and all Google properties such as Gmail, Google Drive, and YouTube), Facebook, Twitter and Yahoo!
Google feel so strongly about HTTPS that they have introduced HTTPS as a ranking factor for websites in its search results.
Issues with HTTPS for Corporate and Enterprise Web Security
We now live in a world where 25% of all web traffic is encrypted over HTTPS, and this trend is increasing and accelerating.
One of the problems we face as companies who need to ensure security for our corporate Internet users is that Malware and viruses are encrypted with the rest of the traffic This means you can have malware scanning enabled on your proxy, but if the download is over HTTPS, your malware would simply pass through the proxy, safely encrypted and land on the end user’s device.
Web filtering and web activity logging and reporting is also affected. As SSL encrypts everything running in the application layer, web proxies only have visibility into the domain a user is visiting, not the full page URL. Site filtering or blocking is therefore less accurate and less effective.
Many web security devices implement some form of Application control enabling granular control within web applications, such as allowing Facebook but blocking Facebook chat for example. Unfortunately this level of application control does not work for encrypted sites like Facebook.
The Importance of SSL Inspection
Fortunately most modern web security devices implement SSL Inspection, allowing you to gain visibility into the encrypted traffic and protect your organization, and improve logging and reporting capabilities.
As you can see, to make full use of your UTM or web security device’s advanced capabilities, you need SSL Inspection enabled, and the need for it increases all the time as the concept of HTTPS everywhere continues to gain momentum.
How SSL Inspection works
With HTTPS, the site you connect to is verified by the site’s certificate, which is used in a key exchange to set up encryption between the client web browser and the web server.
When browsing through a corporate web proxy, the proxy intercepts and forwards your traffic. It does this by terminating the conversation from the user’s browser and starting a separate conversation from the proxy to the web site.
We refer to these two connections as the client side conversation between the user and the proxy, and the server side conversation between the proxy and the web server.
There are two conversations, so there needs to be two HTTPS tunnels. In the server side conversation, the proxy verifies the site and sets up the crypto. The traffic from the webserver is then decrypted on the proxy and can be forwarded back to the client.
The catch is, it needs to be re-encrypted for the client side conversation, and that means it needs to be resigned. Since the only entity that has the original website’s private key is the website itself, the proxy cannot use the same certificate. The proxy therefore needs to sign it with its own certificate. The user will see that the traffic is encrypted, but if they look at the certificate being used, they will notice it is the proxy’s certificate, not the original site’s certificate.
Deploying SSL Inspection with Sophos UTM
Sophos UTM is one such web security device that includes a comprehensive HTTPS/SSL Inspection feature. One of the great features about Sophos UTM’s SSL Inspection is that you can deploy it selectively for certain categories or sites. It’s also easy to setup:
Install Sophos UTM’s Certificate on client devices
Since Sophos UTM will be signing connections using its own certificate, this certificate needs to be trusted by the client systems and browsers. If this it not done, users will see a warning for every site that is being inspected.
Note: Many sites such as Google are now requiring SHA-2 certificates. The default certificate you can download from Sophos UTM (shown below) is only SHA-1 and may result in HTTPS warnings on certain sites. If possible, obtain or create a SHA-2 certificate and upload it to the UTM in Web Protection | Filtering Options | HTTPS CA’s.
To access the Sophos UTM’s certificate:
- Log into the UTMs Web Admin interface, then go to Web Protection | Filtering Options | HTTPS CA’s
- The Signing CA at the top of the page is the Sophos UTM’s certificate.
- Click Download | Export as PEM | Download
Note: You can also download the certificate directly via the following URL when the UTM is configured as your proxy. https://passthrough.fw-notify.net/cacert.pem
This certificate now needs to be installed on your system in the Trusted Root Authority Certificate store. This process is different between Windows and MAC OS, and Firefox has its own method as well. For the scope of the article, we’ll go through installing the certificate on a single Windows machine.
- Run MMC as Administrator (Start | Run | runas /user:[email protected]computername mmc)
- Press Ctrl + M to open the Add Remove Snap Ins Dialog
- Select the Certificates Snap in and click Add. Select the Computer account and click Next, then select the Local computer option and click Finish.
- Expand Trusted Root Certification Authorities, then right-click the Certificates folder and select All Tasks | Import
- Select the certificate downloaded earlier from the Sophos UTM. Place it in the Trusted Root Certification Authorities store and finish the wizard.
This Windows machine will now trust any connection signed by your UTM.
You can also deploy the certificate to all devices using Active Directory Group Policy. For more information on deploying certificates to devices and browsers, see the following Sophos article: Installing the Sophos-Generated Certificate Authority in your Users’ Browsers (note, the article refers to the Sophos Web Appliance, not the UTM, but the methods of deploying the certificate are the same).
Enable the HTTPS/SSL Inspection Feature on Sophos UTM
SSL Inspection is configured on Sophos UTM using web filter profiles. This gives you the flexibility to deploy it for different devices and user groups. For this article, we will apply SSL Inspection to the default Web Filtering profile.
Note: Enabling these steps will affect your users if the proxy certificate has not been imported, so keep this in mind when testing.
- Back in the UTM’s Web Admin interface, select Web Protection | Web Filtering | HTTPS
- Change the radio button from “URL filtering only” to “Decrypt and Scan the following:“
- Click Apply and you are now ready to start testing.
The Scan these categorized websites section shows the web categories that will be decrypted and scanned. The default list omits categories like Business (banking) and Health. It is a good place to start.
Testing with Chrome
Browsers indicate and show certificates a little differently from one another. For the scope of this article we will use Chrome. I am using Gmail as a test because I know it is included in our list of categories to decrypt and scan.
You will notice:
- The https:// in the address bar is green
- The connection indicates that the site has been verified by the Sophos UTM’s certificate.
- Clicking on the certificate information will further show that the signing authority is indeed the UTM and not The Google Internet Authority.
Affects on Logging and Filtering
As mentioned earlier, HTTPS works in the application layer (layer 7) of the OSI network model. Because everything in the application layer is encrypted, the proxy cannot read it unless SSL Inspection is enabled. To see how this affects logging and filtering, take a look at the image below.
Without SSL Inspection, only the domain is logged. That is because everything in the payload, including the rest of the URL is encrypted. When SSL Inspection is not enabled, the UTM’s URL Filtering can only apply to the domain, nothing more than that. For a URL such as https://www.website.com/gambling/casinogames, only ‘website.com’ would be passed to the URL filtering engine.
With SSL Inspection enabled, the UTM now has full visibility into the complete URL. This additional amount of detail means URL filtering will be significantly more accurate and effective. As mentioned earlier, this level of visibility is is required for Application filtering on most sites (facebook vs facebook chat for example).
Affects on Reporting
As with logging, your reports on HTTPS inspected traffic are going to be far more detailed and accurate.
A great example of this is reporting on YouTube videos. With HTTPS/SSL Inspection enabled, the full URL details are logged, allowing you to report on the YouTube videos being watched by a user.
Fastvue’s Site Clean feature is also more accurate when the full URL is logged, as it can distinguish between real browsing to facebook.com vs a facebook ‘like’ button on another web page for example.
A note on privacy and policy
In most organizations, users sign an “Internet Usage Policy” which outlines the company’s guidelines for acceptable Internet usage.
With HTTPS, users have a reasonable expectation of privacy, so your Internet usage policy should explicitly state that HTTPS traffic will be inspected and reported on.
- Video: Google I/O 2014 – HTTPS Everywhere (https://www.youtube.com/watch?v=cBhZ6S0PFCY)
- Survey of the SSL Implementation of the Most Popular Web Sites (https://www.trustworthyinternet.org/ssl-pulse/)
- Is TLS Fast Yet (https://istlsfastyet.com/)
- HTTPS as a Ranking Signal (http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html)
- Protecting data for the long term with forward secrecy (http://googleonlinesecurity.blogspot.com/2011/11/protecting-data-for-long-term-with.html)
- Gradually sunsetting SHA-1 (http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html