How does Tor obfs4 protocol and PTs work?

Question

Could someone explain how have many countries and corporations managed to differentiate tor traffic from normal traffic, and how exactly the obfs4 protocol (Or any other Pluggable transports) help better than any other bridge from bridge-db?

Answer 1

The Tor Project Wiki has a good article covering this: A Childs Garden Of Pluggable Transports.

The pluggable transport is used as a proxy for tors traffic, it provides an extra layer of transformation that exists around the core OR protocol traffic to mask it from censors or eavesdroppers trying to discover it's true nature. In truth, pluggable transports are distinct from Tor and can be applied to arbitrary TCP network protocols, they provide a point-to-point obfuscated traffic tunnel. For how they fit into the Tor network protocol, from the Pluggable Transport Specification, the high level architecture overview looks like this:

 +------------+                    +---------------------------+
 | Client App +-- Local Loopback --+ PT Client (SOCKS Proxy)   +--+
 +------------+                    +---------------------------+  |
                                                                  |
             Public Internet (Obfuscated/Transformed traffic) ==> |
                                                                  |
 +------------+                    +---------------------------+  |
 | Server App +-- Local Loopback --+ PT Server (Reverse Proxy) +--+
 +------------+                    +---------------------------+

1. OR protocol (default/no pluggable transport)

• When client creates a TLS tunnel to the guard relay or bridge it sends a ClientHello message. This announces things like what ciphers it is willing to support and also indicates the hostname it is trying to contact, through SNI. The supported set of ciphers can be used to identify Tor (even when using a bridge without a pluggable transport) along with the random looking hostname. Tor tried to make it's TLS handshake look as much as possible like Firefox, but ultimately this would still be possible to fingerprint. Further, some censored networks will actively block TLS entirely, so even if it could fake being a normal HTTPS handshake it would still not be suitable for many users to appear to be TLS, they would be blocked anyway for reasons unrelated to Tor.

2. obfsproxy/obfs2

• This was the next deployed method to obfuscate traffic, it performed a symmetric key exchange, this exchanged key was then used to encrypt traffic to the bridge, this wasn't to "protect" the traffic but to obscure the underlying protocol from a passive eavesdropper. This has a problem though, in that it does not perform the key exchange through asymmetric cryptography. This means that a passive observer also sees the key and can trivially strip the encryption and see the details of the underlying protocol (Tor) and block it.

3. obfs3

• This improved upon obfs2, it performed a key exchange using public key cryptography. This meant that the passive eavesdropper would not be able to discover the key by simply observing the traffic, they would need to perform exhaustive computations to break the key to test and see if the traffic under the obfuscation was Tor traffic. Unfortunately this came up against two problems. First the key exchange was unauthenticated, an active adversary can pretend to be Alice to Bob and pretend to be Bob to Alice. Both Alice and Bob believe they are communicating directly with each other but the adversary is actually acting as a man-in-the-middle. Because Bob and Alice don't have some shared secret or public key for signatures exchanged prior to their connecting, they cannot verify each other so the adversary can avoid attacking the cryptography by becoming an active attacker. Secondly, there was a simpler way still for adversaries to see if it was a bridge: Connect to the bridge themselves. When a censor sees someone making an unknown connection to the internet, they would follow up and make their own connection to the same destination and try to speak the obfs3 (or any other known Tor pluggable transport) protocol with it. If it succeeded, they just blocked it. Remember, the censor doesn't have to know what Alice and Bob are saying, the censor just wants to stop Alice and Bob communicating, the reason they want to break the cryptography is just to confirm it's Tor and block it.

4. ScrambleSuit

• ScrambleSuit (definitely my favourite name for a pluggable transport ;)) addressed these problems by also distributing a shared secret with the bridge address. Since real bridge users would be provided this shared secret along with the bridge address and the censors would not, by requiring the client to prove that they know the key before it would talk to them a censor who tries to make their own connection after observing the user connect would not be able to elicit a reaction from the server, it would simply ignore them. This shared secret also provides a solution to the problem of the active adversary. Since Alice and Bob both share a secret they can use it to verify each other meaning that the adversary can no longer successfully masquerade as Bob or Alice to the other party. It can also be configured to provide optional "Inter-Arrival" Time obfuscation and padding to obfuscate the underlying protocols packet size, these frustrates attempts to try to recognize the underlying protocol through recognizing patterns in the "flow" of the underlying traffic, which might act as a distinguisher for censors to detect and block. By default they are not enabled as they come at a very large performance cost.

5. obfs4

• While very similar to ScrambleSuit at its core design, improves upon it through the use of modern, high-speed elliptic curve cryptography rather than the UniformDH used in ScrambleSuit and obfs3, which allows it to have smaller, more secure and less computationally expensive authenticated key exchanges. In it's changing of the protocol handshake it also protects against an attacker who knows of the bridges shared secret from successfully impersonating the bridge, since this would require discovery of the private part of the shared public key. It provides at least the same features as ScrambleSuit and further improvements in it's ability to obfuscate the underlying protocol and it's speed.

6. meek

• Meek is a different approach, rather than trying to stop the discovery of entry points into the Tor network, this tries to make it very hard for an observer to distinguish between Tor traffic and other traffic. Since powerful adversaries have been able to enumerate large sets of bridges through various means, being able to have entry points that don't rely on being unpublished to be hard to block provides an advantage. By utilising content distribution networks, Tor can make it's connections masquerade as a web request to some non-Tor resource to an outside observer, while internally directing the traffic into some server software that forwards traffic back and forth onto the Tor network. This makes it difficult for a censor to block only traffic onto the Tor network while allowing the other services behind the same CDN to continue unimpeded, essentially creating a situation where successful blocking would result in high collateral damage to totally unrelated resources making it potentially expensive and unpopular to block.

These are the most common pluggable transports that are deployed at present, there are a few other options which are covered in the wiki document. Obfs2 or obfsproxy-legacy should be considered unsafe and avoided, and it is listed there purely for historical context and progression from obfs2 through to the currently most popular obfs4.

Answer 2

Hopefully this isn't a really bad answer.

Bridges and PTs are two related things with their own purposes to help each other.

As bridge nodes are not in any Tor directories, adversaries will have a harder time to notice that they are actually nodes for the Tor network.

Plugins on the other hand:

Pluggable Transports (PT) transform the Tor traffic flow between the client and the bridge. This way, censors who monitor traffic between the client and the bridge will see innocent-looking transformed traffic instead of the actual Tor traffic. External programs can talk to Tor clients and Tor bridges using the pluggable transport API, to make it easier to build interoperable programs.

Basically, PTs change the exchanged data and metadata you sent from the client to the bridge and vise versa to obscure it from looking like the normal Tor traffic. Some of them use cryptography to obscure it, while others are disguised to look like other types of transfer data. For example, the unused SkypeMorph which make the traffic looks like Skype Video.

For obfs4, it is further explained here:

Is a transport with the same features as ScrambleSuit but utilizing Dan Bernstein's elligator2 technique for public key obfuscation, and the ntor protocol for one-way authentication. This results in a faster protocol.

ScrambleSuit:

protects against follow-up probing attacks and is also capable of changing its network fingerprint (packet length distribution, inter-arrival times, etc.).