Diagnosis: Blocking Hotspot Shield


Introducing our unique anti-spoofing technology that allows Iceni to block the Hotspot Shield VPN.


Schools are required by law to have online safety systems to protect their students. Blocking pornography is the most obvious thing, but these days there are numerous other requirements. For example, flagging concerning behaviour to allow early intervention when it comes to bullying, self harm, radicalisation, etc.

Whilst there are legitimate uses for virtual private networks (VPNs), they can allow the school's online safety system to be bypassed and it is therefore not appropriate for them to be used on school networks. As well as installing filters, schools should ensure that staff and students are aware that VPN software is prohibited. This is usually accomplished by ensuring that users sign an acceptable use policy (AUP) with clear sanctions for any breaches. It is also important for schools to discuss their AUP with the users and to discipline users who are found in breach of it, rather than it just being a piece of paper that is signed and then forgotten about.

Whilst no filtering system can hope to block all VPNs, it is important for us to do our best to help schools to enforce their AUP, which we achieve through a combination of blocking and reporting.

The Hotspot Shield VPN application developed by AnchorFree has recently become a topic of concern, as it does its best to disguise its traffic and evade detection. This makes it very difficult for system administrators to ensure that users are adequately protected by the school's systems. This article discusses the technical detail of how Hotspot Shield attempts to evade detection.


When the application initiates a connection, we see the following traffic:

  • The client makes a DNS lookup for a fairly innocuous looking domain, such as easternarmenia.us. This produces the IP address of one of the Hotspot Shield servers for the client to connect to.
  • The client connects to the Hotspot Shield server and sends a TLS client handshake with the server name indication (SNI) set to the name of a common web site, such as wikipedia.com, paypal.com, etc.
  • The server returns a server handshake that contains what appears to be a valid certificate for the domain that the client's SNI proported that it was connecting to.
  • The client and server exchange keys.
  • A bidirectional encrypted data stream begins, carrying the VPN traffic.

If there is an Iceni proxy performing active HTTPS interception on the traffic, the server fails to successfully negotiate a TLS session with the proxy and the client drops the connection as soon as the proxy presents its forged TLS certificate. After such a failure, the client tries again but with a different server name indication. Unfortunately, as some software is incompatible with HTTPS interception, Iceni must avoid intercepting some domains and eventually Hotspot Shield tries an unintercepted domain and successfully connects. Since the certificates being used are valid, to an outside observer such as the Iceni proxy, the traffic is indistinguishable from legitimate traffic.

You might do a double take at the suggestion that the Hotspot Shield server is presenting a valid certificate for a fake domain. However, it is certainly possible for it to do so, with the cooperation of the client.


Whilst we haven't dissected the client in enough detail to prove how it is presenting apparently valid TLS certificates for third party servers, we have a reasonable theory:

We believe that a number of TLS sessions were negotiated with real third party servers and the traffic recorded. When the client connects to the Hotspot Shield server, it picks one of those sessions at random and sends the recorded TLS client handshake to the server. Upon receiving the handshake, the server uses it to identify which recorded session the client has selected and sends the appropriate recorded server handshake, which includes the valid third party certificate. The client and server send their recorded key exchange messages.

In a real TLS session, the data that follows the key exchange would be encrypted with those keys, which would be impossible in this case since there is no way for the original server key to have been retrieved from the third party server. However, an external observer can't check that the data have been encrypted with the negotiated keys, so the encrypted traffic could be anything. Hotspot Shield can forget about the keys that were exchanged in the recorded data and encrypt data using different keys.

It is worth noting that the replayed data are not identical each time it tries to connect, which leads us to believe that it has a large number of recorded sessions to select from.

In fact, it would be possible to perform a similar attack without recorded data:

The Hotspot Shield client can make a connection to the Hotspot Shield servers and send a legitimate TLS client handshake. The Hotspot Shield server can then connect to a third party system, such as Wikipedia, and act as a relay whilst the client negotiates a real TLS session with Wikipedia. Once the key exchange has taken place, the connection between the Hotspot Shield server and Wikipedia can be dropped and then taken over to exchange VPN traffic with the client.

However, we suspect that this latter method is not being used: real TLS clients do not appear to be able to negotiate sessions with the Hotspot Shield servers, and actively utilising third party servers without permission could well cause legal problems for AnchorFree.

Detection and blocking

As Hotspot Shield's traffic is practically indistinguishable from legitimate traffic, most filtering systems are unable to block it. However, we have developed sophisticated anti-spoofing technology and have identified some patterns in the behaviour of Hotspot Shield. This twin approach allows Iceni to both block Hotspot Shield connections in real time, and to build a database of the Hotspot Shield servers that can be blocked by our Anonymisers / Proxies category.

After successful beta testing by selected schools, the anti-spoofing technology was released to all Iceni Webproxy customers on Tuesday April 4th 2017.