In our previous blog, we discussed how not all Secure Service Edge solutions (SSEs) can prevent SNI fraud, risking connections to malicious servers or sites. In this post, we take a deeper look at what SNI fraud is and how it can be prevented.
Let’s reverse roles and, for a minute, imagine that bad guys use tricks to avoid detection, much like Obi Wan Kenobi tricking Storm Troopers into not trusting what they see is real.
Introducing the Server Name Indication (SNI) Field
In the HTTP protocol, the Server Name Indication, , or SNI, field indicates the web server you, as the client browser, are trying to connect to. Some Secure Service Edges (SSEs) “trust” the user is legitimately trying to connect to the server set in the SNI field. But in fact, they can actually connect to another server entirely and evade proper categorization by a URL Filtering policy; one of the most basic and widely used access control technologies.
In our SNI Jedi Master meets Storm Trooper analogy, the conversation goes like this:
Storm Trooper: “Halt, who goes there?”
SNI Jedi Master packet connecting to [insert bad-site here]: “I am going to [insert a trusted-site here].”
Storm Trooper: “This is a trusted site. Let them through.”
Secure Web Gateways and integrated Next Gen Firewalls with similar feature sets are found in on-premises and virtual solutions as well as cloud-based Firewall-as-a-Service (FWaaS) and SSE offerings. In this blog we will review how some fall short when categorizing web traffic.
What is the SNI field used for?
The SNI field is used as part of the SSL/TLS handshake to facilitate large scale TLS operations within virtual hosting environments, such as those that take place in public clouds and other hosting services. Since a single IP address may be associated with several different virtual servers or sites, then how does a virtual hosting service know which certificate should be provided to the client? For this exact purpose, the client uses the SNI field to indicate which server or virtual host it is trying to connect to, and it does this by presenting the virtual host’s fully qualified domain name, for example, https://www.hxxps://www.exampledomain.com. The virtual hosting service can then provide the client with the correct digital certificate to start an SSL/TLS handshake in which the server authenticates itself to the client.
(For asymmetric encryption neophytes, this SSL/TLS-based authentication works using PKI, or, public key infrastructure: The client uses the public key on the digital certificate of the target host to encrypt an alphanumeric string, called a challenge. If the target server correctly decrypts the challenge using its private encryption key, then authentication is successful, the handshake is complete, and encrypted communications can proceed.)
Why is SNI used for URL Filtering?
It’s common knowledge that we’re moving away from the less secure HTTP web protocol to the HTTPS (HTTP Secure) web protocol where the packet contents are encrypted, and certificates establish trust. Trust is achieved by authenticating websites via digital certificates that are signed by a trusted third party. Hence, HTTPS is used to authenticate target servers or sites, encrypt data in transit for privacy, and also to ensure data integrity. For HTTPS to work, a trusted third party, such as a Certificate Authority, issues and signs digital certificates that each contain a public-private key pair.
In HTTPS web traffic, the host header is encrypted, so SSEs cannot access this information before finishing a TLS handshake. In other words, getting the host header requires a Man-in-the-Middle decryption of the packet by the SWG. One strategy that allows categorization of the web request without doing a MitM interception is to inspect the Server Name Indication (SNI) field value which is not encrypted. The clear-text SNI within the Client-Hello message is checked to see if the server name is in a category that is blocked or allowed. (You can read more here)
Why is HTTPS Traffic Filtering based on SNI Inspection Flawed?
As we have learned above, the SNI value is set by the client. For instance, this can easily be done using a Firefox extension. And herein lies the problem. It is simple to bypass a URL Filtering policy that blocks gambling by setting the SNI value to a site usually trusted by policy, for example a banking site.
How Check Point Implements SNI-based Filtering
Check Point also checks the SNI field set by the client. However, Check Point’s SSE, Harmony Connect, which includes its integrated cloud SWG and FWaaS, Harmony Connect Internet Access, checks to make sure that the hostname in the Subject Alternative Names found in the certificate presented by the responding web server in the TLS Server-Hello matches—preventing SNI bypass techniques. It also goes one step further and records this in the log of the connection event as seen below.
Watch these proof of concept video below, showing how some SWG vendor solutions are bypassed.
Learn how to Secure Internet Access for Branch and Remote Users
With the move to hybrid work, securing internet access for both remote and office workers using a single security stack delivered from a global cloud service allows you to be more scalable, flexible and efficient.
Harmony Connect Internet Access offers an integrated cloud SWG and branch FWaaS that boasts:
- Full internet traffic inspection across ALL ports and ALL protocols
- Granular access control to consumer web apps, including consumer VPNs, peer-to-peer applications and anonymization services
- Unparalleled threat prevention with 30+ AI engines combined with big data threat intelligence.
To learn more about secure internet access from Harmony Connect, check out these resources:
- Secure Internet Access Buyer’s Guide
- SD-WAN Security Buyer’s Guide
- Personal Demo – Harmony Connect Internet Access
- Expert Session Demo Video