Ximin Luo infinity0@torproject.org writes:
## Background
Pluggable Transports are proxy programs that help users bypass censorship.
[App client] -> XXX EVIL CENSOR HAS YOU XXX ACCESS DENIED XXX [App client] -> [PT client] -> (the cloud!) -> [PT server] -> [App server]
The structural design, on the client side, is roughly:
- App client specifies an endpoint to reach
- PT client receives an instruction, via SOCKS, to connect to this endpoint
- PT client does its thing, magic happens (intentionally vague)
## In Tor
Each endpoint is specified by a Bridge line, in the form of an IP address and an optional fingerprint (for authentication).
This point is not made more important in existing docs, but is important for the topic of this email: both the IP address and the fingerprint are potential *identifiers* of the endpoint. The former is an impure name, the latter a pure name.
Currently, we have two main types of PT:
direct PTs - connect to the endpoint directly via a TCP connection
- these PTs don't try to hide the fact that you're contacting X on addrX.
- instead, they usually transform the traffic so it's not identifiable
- e.g. obfs3, fte, scramblesuit
indirect PTs - connect to the endpoint indirectly, via special means
- flashproxy - connects via an ephemeral browser proxy
- meek - connects via an online web service
I will now argue that indirect PTs should do things in a specific way, which is *not* the way meek and flashproxy currently does things.
## Meek and flashproxy
Meek and flashproxy provide an indirect way of accessing Tor. Instead of connecting directly to a Bridge (which might be blocked), the client connects via a midpoint that is harder to block. Very very roughly,
(meek/fp controller)[meek/fp client] -> [meek/fp midpoint] -> [freedom!]
<snip>
So instead of having, as currently:
(old, hacky) Bridge flashproxy (dummy addr)
We would have the following cases:
(1) Bridge flashproxy (real addr) (2) Bridge flashproxy (real addr) (fingerprint) (3, not-ideal) Bridge flashproxy (dummy addr) (fingerprint)
Option (3) is quite nice, since in indirect PTs the actual address is irrelevant - the Tor client never tries to connect to it. I suggest that we have a special syntax for it though, to explicitly discourage hacks that {use dummy addresses but which are treated as real addresses by the underlying application}, since this breaks assumptions of the PT spec.
Hm, but this kind of kills the magic of indirect PTs, right? That is, users who want to use flashproxy in the way above, will have to know an address or a fingerprint of the bridge beforehand. What is the use case? Advanced users? I guess most users (people who use the TBB) will still need to use the current scheme, right?
Also, if all traffic goes over the midpoint, how can we make sure that the midpoint will connect us to the bridge requested with:
(1) Bridge flashproxy (real addr)
?
FWIW, I liked your argument with regards to authentication, and David's reply citing a few tickets that detail the (lack of) threat model for Tor bridges...