Introduction
Using a firewall to filter and block certain types of websites (often referred to as URL Filtering) is nothing new, but it has become increasingly difficult in the past years due to the growth of encryption used on the internet with the rise of the HTTPS protocol.
In my testing, I have been using the R80.30 and R80.40 software versions.
The basic premise of URL Filtering is that all the websites of the internet are divided into different kinds of categories. “News Sites” is one category, “Media Streams” is another, and “Sport Sites” is a third. Most organizations tend to block access to some categories, mainly the ones that are not work-related (for example, pornographic sites).
Some years ago, firewalls could simply take a look at the content of the web packets passing through it and then determine if the packet should be allowed to continue in or out of the network, but since encryption is now used on over 90% of internet traffic, we are unable to simply see what is inside the packets.
The Problem
The go-to solution to this issue is a feature called HTTPS Inspection, and the simple explanation of this feature is that the infrastructure (usually the firewall) performs a Man-in-the-Middle (MITM) attack on the packets traversing the network to examine the content of it before passing it on to the end-user device trying to access the internet, or blocking the packet if it contains something that you don’t want going through your network at all.
However, HTTPS Inspection is rather tough to set up for a lot of organizations as you will need to have managed control of all client devices to make the experience smooth for the end-user, and it requires pretty beefy infrastructure hardware in general compared to just running normal firewall services on a firewall. While there are products whose only purpose is to perform HTTPS Inspection, you can quickly find yourself running out of money as they tend to be pretty pricey, and it's yet another box someone on IT has to manage and maintain.
The Solution
At least for Check Point firewalls, there is a decent workaround to getting a good URL Filtering process set up without the need for HTTPS Inspection.
By utilizing a part of the TLS protocol (which is used in HTTPS) called Server Name Indication, or SNI, the URL Filtering can be done based on the resource (website name) that a user is trying to access.
The SNI field in the TLS protocol is commonly used in scenarios where a server with a single IP address is hosting multiple different websites and need to know which website the user is actually requesting to view so that it can send it to them. Check Point firewalls can take advantage of this feature and use it to determine the name of the website because the SNI value is sent in clear text, it is not encrypted at all. Although the newer TLSv1.3 standards can encrypt the SNI value, it is currently not mandatory.
The image below shows a packet capture from when I visit my very own blog (which uses HTTPS):
Using SNI to find out which website is being accessed also solves another problem, which was using the CommonName in digital certificates to determine the name of a website, which Check Point firewalls used to do in earlier releases of its software. Nowadays, it is very common for websites to have their actual name in a field called the Subject Alternative Name, or SAN, and the CommonName could be something COMPLETELY different from the actual website's name. This allows one certificate to contain many different website names and to be used in different places.
Configuration Steps
Log onto your Security Management Server (SMS) and head over to Manage & Settings > Application Control & URL Filtering > Advanced Settings... and in the General tab, check the box Categorize HTTPS websites in the section called URL Filtering.
This enables URL Filtering based on SNI values. To enable the feature fully, make sure to Publish your change and Install Policy on your firewalls afterward, even if you haven't made any actual rule changes.
Make sure you are using Extended or Detailed Log on your rules permitting web traffic to display the full log entry and to view the URL of the website that the end-user is requesting.
Verification
After enabling this feature, you should be able to see your logs being filled with URLs and which categories those URLs (or websites) are classified as based on Check Point knowledge of them.
In the image below you can see the result of searching on the IP address of my lab-PC and hits that matches the URL Filtering blade when I visit different websites on the internet. In the columns called Application Name and Primary Category, you can now see the interesting data from the web browsing sessions.
Using this information, you can now create rules to permit, deny or redirect these websites as you wish.
While this method doesn’t replace HTTPS Inspection entirely, it is a good way to get more use out of your Check Point firewall without too much hassle. One of the key advantages of HTTPS Inspection is that you get to see the actual CONTENT of the packets, which can contain interesting data for other features in your firewall (viruses, sensitive data, malware, etc.).