Pluggable Transports Session at TorDev

David explains what PTs are and why they were added to Tor. Tor not originally designed for censorship circumvention and does not work well for this purpose by default. Tor’s TLS is easily fingerprintable.

David shows a paper mockup of the Tor PT configuration screen. David shows a live demo of Tor PT configuration screen. The default option is obfs4. The other options currently included are:


flashproxy was recently removed from the list

Brandon and David explain the fte transport as an example. It is confirmed that are in Tor is configured to use the HTTP grammar

The differences between obfs2 (obsolete), obfs3, and obfs4 are discussed.

David explains the look-like-something (fte) and look-like-nothing families of strategies (obfs) of obfuscation.

In the Sony docs data leak, there was a report of deployment in the wild of defeating an obfs2-like obfuscation method for BitTorrent.

obfs3 uses a uniformly random DH handshake in order to defeat detection of the key in obs2.

The key innovation of obs4/scramblesuit is active probing resistance. Active probing is connecting to the suspected bridge and speaking the transport protocol in order to detect Tor bridges.

meek transports use domain fronting to send traffic through CDNs. It is a looks-like-something strategy that looks like HTTPS to a CDN.

obfs4 has become the most used transport. Second is obfs3, and then meek, and then bridges that don’t use PTs.

Fewer than 50 users of FTE. There are only a few FTE bridges.

The most popular countries for using PTs are United States, Russia, Iran, UK, and Germany.

It is unknown why US users use PTs so much. Possible causes are UX related. This is supported by the evidence from the plain Tor / Tor with bridges user numbers from Bangladesh during the blocking of Facebook.

Pros and cons of different PTs: just using Tor without PTs is good enough in most countries. Any PT will probably work in any country blocking Tor. In severe blocking, specific transports are necessary, but custom bridges are also necessary. meek works in severely blocked countries, but is also slower and expensive to operate.

Will wants to know what the story is for PTs on mobile and keeping them pluggable.

Serene presents the Snowflake transport. Snowflake uses WebRTC. It is similar to meek and flashproxy. Like flashproxy, it uses ephemeral in-browser proxies. Like meek, it uses domain fronting, but only for the rendezvous signaling to start WebRTC. Then the data transfer is peer-to-peer. Therefore it could be more scalable and less expensive to operate. This is an improvement over flashproxy websockets is that it has NAT penetration. Snowflake is mostly in Go, but uses WebRTC library, which is in C++. WebRTC has successfully been built for iOS.

WebRTC and related technologies such as STUN, TURN, and ICE were discussed. The availability of public TURN servers was discussed.

How do PTs work on mobile? On Android, it works basically the same, except FTE is not available. On iOS, Guardian Project is working on a feasibility study of porting PTs. A difficulty is that iOS apps can’t fork processes.

The Pluggable Transport configuration protocol vs programmatic APIs as a strategy for integration and developing new PTs was discussed. Nick and Ben’s PT 2.0 spec were also discussed.

Will is working on a UDP transport with spoofing. TCP over UDP is a design consideration. Perhaps SCTP is a solution?

A PT with IP mobility would be cool.

How can we increase the usability of the Tor UI relating to configuring PTs. David is having a separate session on this topic. David’s group at Berkeley did a usability study.

It would be helpful for PT developers to know where different PTs are blocked.

Will has a 

  What is the process for new transports to ship with Tor?
  Overview of existing PTs

Last modified 3 years ago Last modified on Mar 18, 2016, 10:24:32 PM