Tor 0day: Burning Bridges – The Hacker Factor Blog


The onion routing system, Tor, is designed to bypass censorship and evade surveillance. However, the Tor network and Tor Browser have significant limitations; neither lives up to this promise.

In my previous blog entry, I wrote about a couple of different zero-day exploits — vulnerabilities without patches or workarounds. These vulnerabilities impact the Tor Browser and Tor network. One of the issues (detecting the scrollbar width) permits a hostile service to track users; people who use the Tor Browser may be very distinct and not evading surveillance. The other exploit that I disclosed permits companies, service providers, and nation-states to block users from directly connecting to the Tor network; you may not be able to bypass censorship.

Direct connections to the Tor network are the most common type of connection. However, there are also indirect ways to connect to the Tor network. These indirect methods are called ‘bridges’. If someone could detect every bridge protocol, then every Tor user could be blocked from accessing the Tor network, or they can be directly surveilled. (If they know your real network address, then they know who you are, and they can monitor or censor your activities.)

In this blog entry, I’m going to disclose methods to identify Tor bridge network traffic. This includes two new zero-day (0day) exploits — one for detecting obfs4 and one for detecting meek.

Full disclosure: I’ve spent years trying to report security vulnerabilities to the Tor Project. Their reactions ranged from ignoring issues to closing high severity issues as ‘resolved’ but without actual fixes. Often, they are just dismissive. For now, I’ve given up trying to report security issues to them. Since the public should know how vulnerable Tor makes them, I am making these vulnerabilities public.

Note: This is an extremely technical blog entry. It has enough detail for other network developers to replicate my findings.

Tor Bridge Connections

According to the Tor Project, the first step toward evading censorship and surveillance requires users to connect to the Tor network. Many years ago, the Tor developers realized that service providers could block access to Tor just by downloading the list of Tor nodes and blocking all of them. In my previous blog, I showed that you don’t even need to download the list — you can just profile the Tor server’s TLS certificate.

The workarounds that the Tor Project developed are called ‘bridges’. A bridge is a Tor entry node (called a guard) that is not part of the public list. The intent is for people to use bridges when their direct connection is blocked.

To connect to the bridge, you use a non-Tor protocol, called a pluggable transport (PT). Rather than directly connecting to a guard, you would request a small list of bridges from the Tor Project. Each bridge record includes the PT protocol, PT server’s network address and port, and other parameters needed to communicate with the PT server. The PT works as a proxy:

  1. You configure a small set of bridges for use with your Tor Browser (or Tor daemon). Since these are not in a public list, censors will not recognize them as being Tor nodes. (At least, that’s the theory.)
  2. The network traffic from your Tor Browser goes to your local Tor daemon.
  3. Your local Tor daemon forwards the traffic to your local PT proxy.
  4. Your local PT proxy encodes the traffic so that it doesn’t look like Tor traffic. When done correctly, the traffic should appear innocuous and not related to Tor.
  5. The encoded traffic is sent across the Internet to the bridge’s PT proxy. If the censors don’t notice anything unusual, they will permit the traffic to cross the network.
  6. The bridge’s PT proxy receives the data and decodes the traffic.
  7. The decoded traffic is forwarded to the bridge’s Tor daemon.
  8. The bridges Tor daemon passes the traffic to the Tor network.

The key for circumventing censorship requires (1) the bridge to be unknown (not in a list of Tor nodes), and (2) the network traffic cannot be readily associated with Tor. The encoding method can be provided by a variety of pluggable transport protocols. However, many pluggable transport protocols are obsolete or seldom used. For example:

  • Format-Transforming Encryption (FTE): This protocol converts the Tor network traffic into something that appears like some other type of traffic. In theory, FTE could look like any kind of network traffic. In practice, the implementation focused on emulating HTTP traffic. The Tor Project dropped support for FTE about a year ago because FTE was “unmaintained and hardly used,” and not because it was trivial to detect (which it was).
  • OBFS: The family of obfuscated protocols include obfs, obfs2, obfs3, ScrambleSuit, and obfs4. These are described as “look-like-nothing pluggable transport” protocols. Each encrypts the network traffic.

    In theory, someone watching the network will just see random bytes that cannot be tied back to Tor. Most of these OBFS servers function as trojan protocols on ports with known-encrypted services (e.g., SSH and HTTPS). The theory is that an observer will see the binary data and think it is just part of the expected encryption. However, if an obfs4 server is running on 22/tcp (SSH), then a deep packet inspection system will immediately recognize that the first data packet does not contain an SSH header. As a trojan protocol (not using a well-known protocol on a well-known port), it can easily be detected.

    Ignoring the use of well-known ports with non-standard network traffic, there are statistic-based fingerprinting techniques that could identify obfs3, ScrambleSuit, and related network traffic. Due to cryptographic weaknesses, obfs, obfs2, obfs3, and ScrambleSuit have all become obsolete and replaced by obfs4.

  • Meek: This one protocol stands out as different because it uses domain fronting for camouflage. The data looks like TLS because it is TLS. The limitation is that it requires hosting at a popular cloud provider. A company (or nation-state or ISP) cannot block access to the meek server without blocking other services. For example, the meek instance in Microsoft’s Azure cloud (often called meek-azure) uses the same TLS server as ajax.microsoft.com. Blocking meek-azure means blocking access to the entire Microsoft content delivery network. (Losing access to Microsoft’s software updates is never a good idea.)

    Requiring a popular cloud service is a significant deployment limitation. Making matters worse, Google and Amazon both changed their services and disabled domain fronting. The only remaining meek server is hosted at Microsoft’s Azure cloud.

  • Others: There are a wide range of alternative PTs. Most just emulate other protocols (attempting to appear as something else) or rely on obscurity to avoid detection. (E.g., SnowFlake uses WebRTC. Castle encodes data as online video game commands.) It isn’t that these are necessarily hard to detect. Rather, they are used by so few people that it isn’t worth the effort to create a specific detector right now.

The Tor Browser has a built-in menu that helps users enable bridges. (I complain about a lot of things related to Tor, but this user interface for enabling bridges is really done well.) Currently, the built-in bridges only support obfs4 and meek. If you use the automated “Request a bridge” option or the web-based request form, then the Tor Project only provides obfs4 bridges. If you want to use any other type of bridge, then you need to acquire the bridge information yourself and type it into the Tor Browser preferences (“Provide a bridge I know”).

Blocking Tor Connections to obfs4

The Tor Project has standardized around obfs4 for bridges. This means that anyone who can detect and block obfs4 can stop nearly all Tor users from connecting to bridges. (Meek is the other option, but I’ll get to that in the next section.) In effect for bridge connections, the Tor Project has put all of their eggs in one basket.

Unfortunately, “someone” clearly knows some way of stopping obfs4, because obfs4 reportedly does not work from China. Researchers have found that the Great Firewall of China uses a combination of aggressive scanning and deep packet inspection to identify obfs4 bridges. However, I know of no public disclosure for detecting and blocking obfs4. Without the disclosure, developers won’t be able to identify and address the limitations that make obfs4 detectable.

Having said that, here’s the method that I use to detect obfs4 in real-time with stateful packet inspection.* (To reiterate, this is a very technical description. If you don’t know what the “TCP three-way handshake” means, then just assume I can detect all obfs4 connections and jump to the next section.)

  1. Exclude known protocols. obfs4 is a trojan protocol. It’s often found on 22/tcp or 443/tcp, even though it doesn’t use SSH or HTTPS. So if it exists on a port with a known protocol, rule out the known protocol first. For example, if the first data packet on 443/tcp lacks a TLS or SSL header, then it’s a trojan protocol because it isn’t using HTTPS.

    Some obfs4 servers exist on non-standard ports. If the port’s protocol is unknown, then just assume that it could be obfs4 and proceed to the 2nd item in this checklist.

  2. TCP PSH. When transmitting data over TCP, the recipient has a couple of options for reading n bytes of data from the network socket:
    • It can wait until n bytes arrive. (A blocking read.)
    • It can set a timer that either returns n bytes or waits until the timer expires and returns however many bytes (<n) are available.
    • It can do a non-blocking read and get whatever (≤n) is immediately available in the network buffer.

    However, there is a fourth option: the sender can transmit a block of data and set the TCP “PSH” (push) flag on the last data packet. PSH tells the recipient to immediately return that data to the receiving application, even if it is <n bytes.

    Most network services do not regularly use the PSH flag after every few packets. Having said that, obfs4 support is provided by obfs4proxy, which always uses the PSH bit. If the last data packet from the client-to-server (before the reply is sent from server-to-client) does not use PSH, then it isn’t obfs4.

  3. One Direction. With TCP, data can be transmitted from the client to the server (C→S) or from the server to the client (S→C). With many network protocols, you can see data going in both directions at the same time (full duplex). During the obfs4 handshake and tunneled onion routing (OR) initialization, data only travels in one direction at a time (half duplex). The data transmission direction goes hand-in-hand with the TCP PSH flag; the data transfer will not change directions until a PSH is transmitted.

    With these first three rules, we just excluded the vast majority of TCP traffic. Whatever is left could still be obfs4.

  4. Data transfer sizes. When the obfs4 client first contacts the obfs4 server, they exchange a few bytes of data. The first two packets exchange cryptographic parameters, and then it initiates the onion routing (OR) tunnel. The first data transfer goes from the client to the server (C→S). The second transmits data from the server to the client (S→C). Anything else isn’t obfs4.

    The folks at Fortinet worked out the packet sizes, including the variable-size random padding. The first C→S must be between 141 and 8192 bytes. This is followed by the first S→C with 109 to 8160 bytes.

  5. All remaining data transfers. After the introduction, obfs4 begins transmitting data. All data transfers must be between 21 and 8192 bytes. I’ve found that just checking the first 6 data transfers for these size ranges is plenty to rule out most non-obfs4 traffic.
  6. Parallel connections. Up to this point, this detection method is very accurate, but not 100%. It might miss 1 out of every 10 obfs4 connections (10% false negatives), and it is possible to mistakenly match other protocols. Fortunately, there is one more rule that can be used to mitigate these misses.

    The Tor Browser has three different ways for a user to select bridges.

    • Drop-down menu to select the default bridges. (You can see the default bridges by using about:config and searching for ‘bridges’ on the Tor Browser.) As soon as you select them, the browser sends out connections to each of them. You should see a burst of connections. (There are currently 14 default obfs4 servers on IPv4, and it will immediately connect to all of them.)
    • You can click on the ‘Request Bridges’ button. After completing a captcha, you’ll be assigned 2-3 obfs4 bridges, and the Tor Browser will immediately connect to all of them. Usually one or more will be detected as obfs4. Your packet inspector will also definitely see multiple connections going out at the same time to different servers.
    • You can acquire bridges via some other means. (e.g., Tor Project offers an email service for retrieving bridges.) You can then cut-and-paste the bridges into the Tor Browser. This usually means adding 2-3 new bridges, so the packet inspector will see the parallel requests, with one or more being detected as obfs4.

    If you detect obfs4 on any one TCP connection, then check for one or more simultaneous connections to other servers (within a half-second window). Each should have the first data packet going from C→S with TCP PSH and appear to be random bytes (not a known protocol). If you see this, then it’s obfs4, and you can rule out virtually all false-positives. Moreover, the false-negatives do not matter since you only have to catch one obfs4 connection in order to determine that the user is running Tor and trying to connect to obfs4 bridges.

Detecting obfs4 IAT Modes

This packet profiling assumes that you have a finite state machine that is tracking the direction of travel (C→S or S→C). To defend against this type of profiling, obfs4 has a couple of Inter-Arrival Timing (IAT) modes. (Fortunately for us packet profilers, the IAT modes are pretty weak). For the Tor Browser, each obfs4 proxy definition lists the IP address, port, some signature information, and the IAT mode. For example:

obfs4 209.148.46.65:443 74FAD13168806246602538555B5521A0383A1875 cert=ssH+9rP8dG2NLDN2XuFw63hIO/9MNNinLmxQDpVa+7kTOa9/m+tGWT1SmSYpQ9uTBGa6Hw iat-mode=0

  • IAT mode 0 means that packets are segmented by the network. They can be any size. But since they are segmented by the network, packets with large payloads will come first, and the last packet in the data transfer will have the PSH.
  • IAT mode 1 means that packets are segmented by the obfs4 proxy. The maximum TCP payload size will be 1448 bytes. If you see 1448 bytes with a PSH, then just assume that more data will be coming in the same direction. This also means that you can tell it is in IAT mode 1.
  • IAT mode 2 uses random packet sizes. If the packet payloads vary randomly in size (not limited to 1448 or network segmentation sizes), then it’s mode 2. In mode 2, you should not assume that a PSH changes the communication direction (C→S or S→C) unless it actually changes direction

IAT mode 2 is very uncommon. Nearly all bridges use obfs4 with IAT modes 0 or 1.

From a cryptographic viewpoint, obfs4 seems pretty solid. However, the developers appear to have focused on cryptography and not network profiling. Network profiling allows me to identify the entire OBFS family of pluggable transports (including ScrambleSuit, obfs3, and obfs4) without ever touching the cryptography.

2020-07-27 16:42:41.787239 GMT 192.168.15.15[54006/tcp] -> 146.57.248.225[22/tcp] : obfs4
2020-07-27 16:42:41.829451 GMT 192.95.36.142[443/tcp] -> 192.168.15.15[60838/tcp] : obfs4
2020-07-27 16:42:41.832556 GMT 192.168.15.15[47232/tcp] -> 144.217.20.138[80/tcp] : obfs4
2020-07-27 16:42:41.843840 GMT 192.168.15.15[41534/tcp] -> 209.148.46.65[443/tcp] : obfs4
2020-07-27 16:42:41.860354 GMT 38.229.1.78[80/tcp] -> 192.168.15.15[37020/tcp] : obfs4
2020-07-27 16:42:42.077762 GMT 192.168.15.15[43922/tcp] -> 37.218.245.14[38224/tcp] : obfs4
2020-07-27 16:42:42.147042 GMT 192.168.15.15[54346/tcp] -> 85.31.186.26[443/tcp] : obfs4
2020-07-27 16:42:42.153197 GMT 192.168.15.15[49538/tcp] -> 85.31.186.98[443/tcp] : obfs4
2020-07-27 16:42:42.156841 GMT 192.168.15.15[52074/tcp] -> 193.11.166.194[27020/tcp] : obfs4
2020-07-27 16:42:42.170548 GMT 192.168.15.15[33632/tcp] -> 193.11.166.194[27015/tcp] : obfs4
2020-07-27 16:42:42.181053 GMT 192.168.15.15[58162/tcp] -> 193.11.166.194[27025/tcp] : obfs4
2020-07-27 16:42:42.441658 GMT 37.218.240.34[40035/tcp] -> 192.168.15.15[57268/tcp] : obfs4

The Tor Project once described bridges as an “arms race”. On one hand, you have the users who want to circumvent censorship and access to the Tor network. On the other hand, you have the censors who want to block Tor traffic. Unfortunately, the Tor Project has given up on the arms race and settled on a homogeneous solution: obfs4. This is fine if nobody knows how to detect and block obfs4 traffic. However, China appears to have a complicated method for detecting and blocking obfs4 connections, and I have just shown that an easier stateful packet inspection system can detect obfs4 traffic.

Blocking Tor Connections to Meek

By default, the current Tor Browser only supports three ways to connect to the Tor network: direct, bridge using obfs4, and bridge using meek. Direct connections can be detected in real-time using raw IP blocking, or filtering based on the distinctive server certificate. There are plenty of obfs4 bridges, but they are easy enough to detect in real-time, if you know what to look for (as detailed in this blog entry). That just leaves meek.

As far as I know, there is only one meek server available today. It’s hosted at Microsoft’s Azure cloud. Because China blocks direct connections and obfs4, meek is the only available pluggable transport for people in countries like China to access Tor. As a result, it is heavily used and terribly slow; I often see network timeouts when trying to use the meek-azure bridge.

This slowness makes it easy to detect meek. The initial TLS connection and cryptographic negotiation is fast (TLS Client-Hello, Server-Hello, and Change Cipher Specification). However, the encrypted data stream containing the Tor traffic is slow. For identifying meek, an observer only needs to track the TCP packets between the client and the meek server (ajax.aspnetcdn.com) that have over 1000 bytes in the TCP payload. Look for the big delays (over 2 seconds) between the request (C→S) and response (S→C). If someone connects to the meek-azure server and there are consistent long delays in the response times, then it’s meek; all other sites behind that same TLS server are fast.

To reiterate: meek-azure uses domain fronting and hides behind the same TLS server used for ajax.microsoft.com. Responses from ajax.microsoft.com should be fast since it’s used for Microsoft’s content delivery network, which is explicitly designed for speed. If the responses are not fast, then the TLS server is not connecting to a content delivery network. With this simple timing attack, you might not be able to tell meek-azure from any other domain fronting application that uses the same TLS server, but you can detect the domain fronting. And if you’re trying to stop covert messaging frameworks like Tor, then you’re going to want to block all domain fronting.

Completely Blocking Tor

Going back to my initial premise: Suppose you’re a company that has a “no Tor on the corporate network” policy. Between my previous blog entry and this one, you now have everything you need to enforce the policy with a real-time stateful packet inspection system. You can stop all of your users from connecting to the Tor network, whether they connect directly or use a bridge.

The Tor Project operates on the premise that Tor will work around censorship. However, they have (1) not addressed the direct connection issue, and (2) limited their bridge options to obfs4, plus one meek bridge. Unfortunately, both obfs4 and meek are detectable. This has created a situation where any company, service provider, or nation-state can detect and block all connections to the Tor network. Together, these vulnerabilities create a very effective 0day for blocking all access to the Tor network.

(If you are waiting for even more Tor 0days: don’t worry, I still have a long list of blog topics to write. Blocking all users from accessing the Tor network isn’t the worst thing that can happen to Tor users, or to the Tor network.)

* Stateful packet inspection (SPI) uses filtering rules that track the network and transport packet fields in order to determine whether traffic is permitted or denied. Deep packet inspection (DPI) also evaluates the packet’s application layer. Detecting trojan protocols (e.g., using non-HTTPS traffic on an HTTPS port) requires DPI. My first step for detecting obfs4 uses DPI, but it is optional. All other steps only evaluate the transport layer, so it is technically SPI.


Source link