[tor-bugs] #7167 [Pluggable transport]: Combine traffic obfuscation with address diversity of flash proxy

[Tor Bug Tracker & Wiki]

#7167: Combine traffic obfuscation with address diversity of flash proxy
---------------------------------+-----------------------------------------
     Reporter:  karsten          |      Owner:  asn
         Type:  project          |     Status:  needs_revision
     Priority:  normal           |  Milestone:
    Component:  Pluggable        |    Version:
  transport                      |   Keywords:  SponsorF20131101 flashproxy
   Resolution:                   |  Parent ID:
Actual Points:                   |
       Points:                   |
---------------------------------+-----------------------------------------

Comment (by dcf):

 Replying to [comment:32 dcf]:
 > What I am most concerned about is the scenario when something connects
 to the external listener (and an address is queued), but something goes
 wrong in the proxy chain (for example the WebSocket handshake is bad) and
 there's no following connection to the internal listener. We will have an
 orphan address in the queue that will be associated with the next
 connection that survives to the internal listener. In the current
 implementation, I supposed this will eventually result in deadlock,
 because the size of the FIFO is limited. Perhaps we can age and expire
 queue entries.

 I did tests today and it is indeed trivial to wedge the server just by
 making 10 non-WebSocket connections to it. Here is what you see in the
 case of a normal obfs3|websocket connection:

 {{{
 2013-09-10 18:46:30 external connection from [scrubbed].
 2013-09-10 18:46:30 handleExternalConnection: now 1 conns buffered.
 2013-09-10 18:46:31 internal connection from 127.0.0.1:35389.
 2013-09-10 18:46:31 connecting to ORPort using remote addr [scrubbed].
 2013-09-10 18:46:31 handleInternalConnection: now 0 conns buffered.
 }}}

 Notice how an external connection leads to an internal connection that
 reduces the numbers of conns buffered. Compare this to what happens if you
 just connect with netcat 12 times:

 {{{
 2013-09-13 15:49:39 external connection from [scrubbed].
 2013-09-13 15:49:39 handleExternalConnection: now 1 conns buffered.
 2013-09-13 15:49:53 external connection from [scrubbed].
 2013-09-13 15:49:53 handleExternalConnection: now 2 conns buffered.
 2013-09-13 15:52:00 external connection from [scrubbed].
 2013-09-13 15:52:00 handleExternalConnection: now 3 conns buffered.
 2013-09-13 15:52:03 external connection from [scrubbed].
 2013-09-13 15:52:03 handleExternalConnection: now 4 conns buffered.
 2013-09-13 15:52:04 external connection from [scrubbed].
 2013-09-13 15:52:04 handleExternalConnection: now 5 conns buffered.
 2013-09-13 15:52:06 external connection from [scrubbed].
 2013-09-13 15:52:06 handleExternalConnection: now 6 conns buffered.
 2013-09-13 15:52:08 external connection from [scrubbed].
 2013-09-13 15:52:08 handleExternalConnection: now 7 conns buffered.
 2013-09-13 15:52:10 external connection from [scrubbed].
 2013-09-13 15:52:10 handleExternalConnection: now 8 conns buffered.
 2013-09-13 15:52:12 external connection from [scrubbed].
 2013-09-13 15:52:12 handleExternalConnection: now 9 conns buffered.
 2013-09-13 15:52:14 external connection from [scrubbed].
 2013-09-13 15:52:14 handleExternalConnection: now 10 conns buffered.
 2013-09-13 15:52:18 external connection from [scrubbed].
 2013-09-13 15:52:25 external connection from [scrubbed].
 }}}

 What I propose to do about this: Let's push conns on a stack, rather than
 a queue. When a new external connection comes in, it is put on top of the
 stack. When a new internal connection comes in, it is assigned the most
 recently seen address, the one at the top of the stack. Zombie connections
 that somehow didn't survive the proxy chain to make an internal connection
 will remain at the bottom of the stack, and never assigned to any
 ExtORPort connection (and we can just prune them if they get too old).

 Using a stack rather than a queue means that we are virtually certain to
 invert the order of two near-simultaneous external connections. But we
 weren't worried about that anyway. It means that we will quickly forget
 about addresses that connected to our proxy chain but didn't result in an
 ExtORPort connection.

 I believe this will be good enough to prevent incorrect ExtORPort
 addresses, assuming that parties are honest or naive, and not malicious.
 That is, it will prevent assigning the address of someone who happened to
 just port scan the server, except for a narrow race window. (You would
 have to do your port scan or netcat after a legitimate external
 connection, but before that connection gets all the way through the proxy
 chain.) It's still vulnerable to malicious actors, say someone who makes
 constant non-WebSocket connections in an effort to poison the metrics
 data. But I'm not sure we can do better until Mk. III, when we do
 something to always correctly match up ExtORPort information.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7167#comment:38>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online