Complete specification for generalised PT composition

obfs-flash (both client and server) already composes two PTs together. We have [ticket:9744] to generalise one aspect of the server component, but there are some things missing for full generalisation; we also need to do this for the client side.

I have some notes here on the abstract design goals we want to achieve: ​https://github.com/infinity0/tor-notes/blob/master/pt-compose.rst

We might also want to do [ticket:7153].

added component::circumvention/pluggable transport fog owner::infinity0 priority::medium research severity::normal status::new type::enhancement labels

Here are some of the issues we ran into, when turning obfs-flash-client into a more general form. I've also done a simple language substitution to turn them into statements that are applicable to the server side, but I haven't thought them through so they might be less correct.

Remote interface:

• client: the outermost PT (that writes to the internet) might not send to a particular address. (e.g flashproxy-client)
• server: the outermost PT (that reads from the internet) might not listen on a particular address. (not sure if we need to support this, even flashproxy's websocket-server isn't this weird)

Real remote PT:

• client: the remote bridge address (if any; see prev point), tor must give to the outermost PT, not the innermost as naive chaining achieves
• server: the remote client address (if any; see prev point), tor must read from the outermost PT. (this might already be covered with ExtORPort handling)

Per-bridge shared-secrets / other metadata:

• client: this might be dynamic (from Tor), so needs to be passed per-connection.
• server: this is probably static and can be input via config files. (not entirely sure about this)

FWIW, in the future the transport combinator should also be able to help rate limit its transports.

We started working on pluggable transport rate limiting in the 196-transport-control-ports.txt proposal, but it needs more thought and more engineering to work for transport combinations. There is also: https://lists.torproject.org/pipermail/tor-dev/2013-September/005419.html

Here is a transport combo that doesn't work very well with all our suggested designs.

From https://lists.torproject.org/pipermail/tor-dev/2014-January/006159.html :

Thinking about transport composition, scramblesuit|meek could be an
interesting thing. What this would mean is that your client makes an
HTTP request to some server, containing a POST body with the beginning
of a ScrambleSuit conversation. If you have the shared secret, the
server replies with 200 and you start communication. If you don't have
the shared secret, the server replies with a 404 (or even 200 with an
ordinary web page). What it means is that there can be a magic URL that
only you (holder of the shared secret) can use as a bridge. It could
even be on a real web site with real pages and everything. ScrambleSuit
would additionally provide some diversity of packet lengths and timing.

For example, in the server-side of the above example, if the attacker doesn't know the shared-secret, scramblesuit (the internal transport here) will just stay silent, and there is no communication channel for meek (the outter transport) to learn that it should spit out a 404 or 200 page.

David suggested (as a possible workaround) to have a timeout on meek after which, if the internal transport remained silent, meek spits out a 404 page. But now we are starting to tweak our transports to satisfy our combiner model (and we also have to tweak each transport wrt to each internal transport).

Just a thing we should consider if we are going to spend actual engineering time on this.

I have pointed out another issue in [[ticket:10196#comment:5]], which further restricts the sort of transports we can chain.

Generally, transports ought not to destroy information from previous layers, as flashproxy does - it ignores the Bridge line of the user, which (in the case of scramblesuit) includes a shared-secret that does not work for other Bridges that the flashproxy-facilitator might pick. (The context is the fog combined-PT case, where something is tunneling through flashproxy.)

Trac:
Keywords: N/A deleted, pt-combiner, research added

Trac:
Keywords: pt-combiner deleted, fog added

Replying to asn:

If you don't have the shared secret, the server replies with a 404 (or even 200 with an ordinary web page). What it means is that there can be a magic URL that only you (holder of the shared secret) can use as a bridge. It could even be on a real web site with real pages and everything.

a normal error message would be bad. the adversary would see traffic but when he tries to access it he only gets a 404. thats suspicious. so there should be a legit website. but it has to be a real website. a site that is the same for all bridges would be easily fingerprintable. autogenerated content is not much better. its not entirly impossible but there are just too many things to think about. a solution could be to provide a reverse proxy to a real webserver. this would also delegate all the complexit that comes with a webserver. #17057

Trac:
Username: elypter

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

moved to tpo/anti-censorship/pluggable-transports/trac#10061 (closed)