wiki:org/meetings/2012SummerDevMeeting/Notes/D2S2PluggableTransports

Objectives: plan for deployment of pluggable transports.

Steven has a road map for pluggable transports.

Roger: Which world do we live in in? Either: There is no transport that is unblockable. Or: there exists a transport that is unblockable. Some belive we live in the first world, others in the second. I.e., are we seeking the holy grail of transports, or just wanting to stay ahead in an arms race?

Discussion about an HTTP transport; general sentiment seems to think it's the best goal. However, any transport that is sufficiently costly to block is good enough.

Let's make a plan for this discussion:

  • Establish a censorship group.
  • Talk about the actual options we have right now, why they're not perfect, what order do we expect them to be blocked, in what order are we going to put effort into them?
  • Shall we deploy one at a time, or all at once? [Steven has a paper, available on request, on the subject of whether to deploy all at once or one at a time. If we assume there is a transport which we can force the censor to block other traffic as often as Tor, then we should do many at once, and choose the most popular protocols. None of the current obfsproxy proposals do this--they can be blocked with 0% false positives.]

[Roger: has come to believe that obfs2 without shared secret is blockable with DPI, because of correlation in the handshake. obfs2 with a shared secret doesn't have that problem, but a DPI firewall could identify it by the uniform randomness of the stream.]

[BitTorrent would be a great transport; Bram Cohen has sort of claimed working on it, but we've not heard from him in some months.]

[Steven's paper considered only collateral damage cost, but ignored the cost of the censor updating their infrastructure with a new signature or something--it's another arms race to consider.]

Roger: There are two arms races:

  1. Come up with a transport that has false positives if you try to block it, and
  2. Make sure there is a transport that works against's yesterday's DPI boxes.

If we find that obfs2 is blocked tomorrow, let's not wait for something perfect, rather release another imperfect next-gen obfsproxy and force the censor to continue the arms race.

It would be useful to quantify (in economic or time terms) how much the deployment of a new transport can cost the censor.

Zack talks about Stegotorus. There's a part called the "chopper." The chopper can be thought of as "obfs-a"(?) or as a replacement for Tor's use of TLS. Then there are the steganography modules (only one so far, a "very bad" fake HTTP). Working on making a better one in order to crank up the false positive rate. Another guy (Lay) is working on another Stegotorus module that impersonates HTTPS. Chopper is capable of distributing one long-lived Tor link across many small HTTP sessions.

15 minutes remain; let's bring it back to the next steps. obfs2 is working, should we deploy flash proxy now? Roger nods.

David will send to tor-dev a description of flash proxy, with an explicit call for testing and concerns, also the known next steps. David's idea of "deployment": Some bundles available to download, and a blog post to announce it. Use the dumb HTTP rendezvous until it gets blocked.

Stegotorus is not ready for deployment. In 3—6 months's time, "obfs3" can be ready (chopper and nothing else). (Just spits encrypted stuff on the wire, doesn't look like HTTP.)

Brandon's Wiley's project, Python pluggable transport library (pyptlib), is mentioned.

Roger: We should not spend time on C modules for obfs if it has not been blocked. Rather, let's focus on the rapid development of Python transports. If obfs2 becomes blocked, he might change his mind.

Isis: Bananaphone. Roger: Does it have a repo and running code? Isis: yes.

Put a list of all known transports on the pluggable transports web page:

Tariq: who is going to be tracking the arms race? Are we ahead, behind, or what? Right now individuals keep track of that on their own.

Roger brings up a good point: Let's not deploy a new transport until we have a plan for what to do when it is blocked. E.g., what do we do when a DPI box starts blocking flash proxy by protocol inspection? David says we could perhaps work with Stegotorus, but it is not a satisfactory plan.

Isis: chaining transports could be worthwhile: e.g., obfs2 to Bananaphone. It would make the inside of Bananaphone look more random (apparently it doesn't randomize its payload by itself).

Roger's final points:

  1. Make it so other researchers can research using your code. E.g., be able to recruit other allies in the arms race.
  2. Deploying new transports. We can relatively easily deploy clients and bundles, but it's much harder to deploy on bridges. So we can't really iterate as fast as we might think.

Action items

  • Zack: Make a ticket to implement the Stegotorus chopper on top of pyptlib.
  • Zack: Write a spec document for the Stegotorus chopper protocol.
  • David: Write a message to tor-dev about flash proxy.
    • Make flash proxy bundles.
  • Roger: Add missing known transports to the pluggable transports page.
Last modified 6 years ago Last modified on Jul 18, 2012, 8:07:24 PM