Skip to Content
Personal Insights

Focus on Privacy: Defending Against Deep Packet Inspection

We live in interesting times. On one side, we have organizations and officials who want to know what other people are talking about. On the other side, there are citizens who want to defend their privacy rights and do not want to share info related to their correspondence and web surfing. However, this post is not about society. It is about technology.

These days technical literacy of many people is constantly growing. Several years ago, the words like Proxy or VPN were known only to IT professionals. Now we can say that a lot of people know what a VPN is, moreover – they use these technologies on a daily basis.

Some recent news pieces are very interesting. For example, VPNs and similar services for traffic encryption are forbidden in China. You can even be imprisoned for it. Venezuela government blocks direct connections to Tor. Russia closed access to many Western websites and services (at some point Google, Amazon and Microsoft IPs were partially blocked.)

Let’s try to figure out in which direction the measures to limit communication can move further.

As to ACL filters, everything is clear. ACL filters already work. It is very difficult to struggle with this.

As to DPI – Deep Packet Inspection, things become a bit more interesting.

Methods of identifying traffic types using DPI can be divided into two groups:

  • Signature analysis. This boils down to sorting out each and all packets and comparing the headers and structure to known existing samples, thus determining packet nature and purpose. A lot of tunnels can be detected this way. For example, SOCKS, OpenVPN, L2TP/IPSec.
  • Conducting a preliminary analysis of traffic exchange patterns. Namely analyzing the ratio of incoming and outgoing traffic volumes as well as the frequency of requests and responses, and using some other criteria, allows separating real protocol traffic from a tunnel that tries to disguise itself.

Let’s break protocols\technologies into several groups and try to forecast how interested parties can start blocking\filtering\monitoring them.

  1. Well known VPN protocols, proxies, tunnels. Such things can be automatically blocked, as it already happing in Venezuela and China. As to proxies, it is even easier. HTTP and SOCKS transmit data in clear text. It is possible to selectively cut requests and intercept all transmitted information.
  1. Technologies of dual-use nature like SSH. After the session is established, the Internet speed can be significantly reduced.
  1. Specific protocols such as game clients, messengers, etc.
  1. Connection types that cannot be determined.
  1. SSL, TLS, HTTPS. Complete blocking is impossible here as it means blocking the entire Internet. Pattern analysis also does not make sense, since HTTPS is aimed at secure web surfing.

It is possible to use whitelists for points 3 and 4. Those who are not in whitelists may expect the fate of those from point 1 and 2.

Of all points above, TLS/SSL using port 443 looks the most unsuspicious and reliable option.

Therefore, let’s try to move it this option.

Below are several techniques\technologies to mask your connections and traffic.

AnyConnect/OpenConnect. This is an open source version of the AnyConnect SSL protocol. When establishing a connection, TLS (TCP) and DTLS (UDP) are visible. But if provider cuts the UDP traffic, AnyConnect switches back to TCP and it looks like TLS. Even the authentication inside the encrypted tunnel works as in HTTP.

Shadowsocks. This is an encrypted SOCKS proxy. Actually, if strongly desired, it can be identified, but there are a lot of plugins that mask it to look like HTTPS.

Wireguard. It has strong encryption and secure session setup mechanism. However, the exchange happens via UDP. Wireshark defines packet types as something completely incomprehensible. It is yet unclear what opinion\conclusions about your connections will be made by еру third-party DPI.

obfs3, obfs4. Obfuscate packets so that from the outside they look completely random set of values. That is, falls under point 4 of the list above.

SoftEther. It looks like HTTPS, but with one exception. In addition to TLS over TCP itself, it actively sends UDP packets. UDP can be used to speed up data transmission (in case it is not being cut by the firewall).

SSTP. This is a VPN protocol from Microsoft. Natively supported by Windows, auxiliary software needed to make it work with Linux. From the outside, it looks like HTTPS, and even Wireshark fully confirms this.

Suppose you are building a VPN server on a host and set it to listen to port 443. It seems that everything is good, but there is one big BUT – if you pretend to be HTTPS, it is still possible to find what exactly “hangs” on port 443. Anybody can test this port with a browser. This method is used in China.

Therefore, we need to have the most ordinary and standard web server on port 443. And here comes an interesting issue. None of the above technologies/services do not list in their documentation description of how to implement a port sharing.

Some geeks suggest using the Server Name Indication (SNI) which is a TLS extension. It allows to specify the hostname, and then use sniproxy, HAProxy to spread connections across different services.

The problem is that in current TLS implementations, the hostname specified when using SNI is transferred in plain text and can also be eavesdropped.

WebSocket may help

One of the best ways to hide a tunnel inside an HTTPS is to utilize popular tools. Modern web has long been using a solution for establishing a connection over TCP between the server and the browser, it is called the WebSocket protocol (RFC 6455).

The client creates a special HTTP request to which the server must respond in a special way. After a quick handshake, you can start sending data over the same TCP connection. Everything looks like regular HTTPS from the outside.

There are numerous WebSocket implementations, you can even find a Haskell variant. I am using wstunnel created using nodejs. You can connect to a SOCKS proxy OpenVPN or Dante over the tunnel.

This method has one small problem. Besides the VPN or SOCKS client itself, you have run a wstunnel client too. That can be problematic on smartphones.

1 Comment
You must be Logged on to comment or reply to a post.
  • Cool story but what does this have to do with SAP?

    Also – “even housewives”, really? Housewives are not more stupid or less educated than other people. Please stop propagating ridiculous sexist stereotypes.