[tor-bugs] #3875 [Firefox Patch Issues]: TBB's Firefox should use optimistic data socks handshake variant

[Tor Bug Tracker & Wiki]

#3875: TBB's Firefox should use optimistic data socks handshake variant
-----------------------------------+----------------------------------------
 Reporter:  arma                   |          Owner:  mikeperry                    
     Type:  enhancement            |         Status:  new                          
 Priority:  major                  |      Milestone:  TorBrowserBundle 2.3.x-stable
Component:  Firefox Patch Issues   |        Version:                               
 Keywords:  performance roundtrip  |         Parent:  #3890                        
   Points:                         |   Actualpoints:                               
-----------------------------------+----------------------------------------

Comment(by t55wang):

 Replying to [comment:15 mikeperry]:
 > Replying to [comment:13 t55wang]:
 > > Replying to [comment:12 mikeperry]:
 > > > Replying to [comment:11 t55wang]:
 > > > > I've implemented preliminary versions of both. Right now, the
 "tiny change to FF" approach works except for the SSL handshake, which is
 to say it does not work. The "modifying OP" approach works, but doesn't
 deal with some errors very well yet. I will keep you updated when either
 or both approaches do in fact work.
 > > >
 > > > How exactly does the SSL handshake fail, and in what cases?
 > > >
 > > > And for the OP case, what does "not dealing with some errors very
 well" mean in practice? The user experience for errors is already pretty
 bad. I think in practice we can ignore most UX issues with the errors
 since the perf benefit for the good case is so clear.
 > >
 > > These things have been fixed. For the SSL handshake, I told it to stop
 polling after one round and I shouldn't have. For the errors, I meant that
 DNS resolution failure returns "connection has been reset" to the Browser,
 which seems confusing, so I wrote an error message explaining what
 happened (copying from the original "Tor is not an HTTP proxy" message)
 for that case.
 >
 > Ah yeah, for DNS typos that's pretty sad... Random thought: On the
 Firefox side, we could simply retry with optimistic data disabled before
 actually displaying any errors... The error path would then be like 2X as
 slow but correct, but the common case would be still fast. Or, we could
 sink the work into figuring out how to communicate the error belatedly
 through some ungodly side channel. I would not be opposed to either of
 these approaches, if one or both are easy...
 >
 > However, looking at your change to Tor, it looks like we can still give
 the exact error condition to the user anyways.. Unless that's what you
 mean wrt the port 80 hack? I guess the error message gets eaten by Firefox
 if the DNS failure was for a 443 connect? Oh, ew, also, we'd have to
 localize that message in tor either way, and I think tor currently has no
 localization support at all for any messages :/.
 >

 The error is sort of communicated to the user in this patch I posted - if
 DNS resolution fails with the Tor fix (not the Tor Browser fix), the user
 will see a message displayed in the Browser saying something like "Tor has
 terminated the connection because DNS resolution failed".

 Oh, you're right, 443 connects were not considered. I could change it to
 "port 80 or port 443". Not sure if this is the best solution.

 What do you mean by localization?

 > > > Also, can you attach patches as well? It will make it easier for us
 to make suggestions/decisions.
 > >
 > > I have included patches for both the Tor Browser and Tor. Both are
 working, but performance measurements are underway and should be done by
 tomorrow.
 > >
 > > The Tor Browser fix is slightly more involved, as it introduces a new
 state to the connect process (marking where the GET request can be sent)
 and changes the behavior of the SOCKS handshake. I am not sure if there
 are unforeseen consequences of flipping the handshake on its head -
 everything I've tried has worked so far. The Tor fix is much simpler (the
 core is literally one line), but there are some potential problems. We did
 a "hack" where Tor checks if the port we're trying to talk to is port 80,
 and only displays the specific HTTP error message (for DNS resolution
 failure) in that situation. There's also the problem that Tor is
 essentially lying to Firefox by telling it that the socks connect has been
 accepted by the end server, when it hasn't been.
 >
 > Do you know off-hand if we can grow the SOCKS state machine easily to do
 a (possibly synthetic?) retry-on-error, or is that likely to involve some
 higher-level Firefox logic or side channel?

 Currently the SOCKS state machine works this way, as far as I know. During
 the handshake stage, if anything arrives at the socket, a function catches
 it during polling and calls the handshake function. The handshake function
 tries to proceed to the next step of the handshake based on what arrived
 at the socket and what its current step is. If it succeeds, it will keep
 trying to go to the next step further until it can't, in which case it
 informs the polling function to call it again once anything else arrives
 at the socket. At some step the handshake is finished.

 So there is a sort of retry-on-error in there, the handshake function will
 keep trying until the handshake function itself declares that the
 handshake is finished (either a complete success or a complete failure).
 There are only a few conditions which trigger a complete failure, like a
 bad SOCKS version number or an unreadable destination address. So, what
 the handshake function understands as a complete failure can indeed be
 tampered with. What are we considering?

 I have done some straightforward measurements. I measured the time taken
 between the SOCKS request and the HTTP 200 OK reply for a given site.
 After ten measurements Tor with optimistic data had an average time of
 0.56 seconds with a standard deviation of 0.14 seconds, whereas Tor
 without optimistic data had an average time of 0.80 seconds with a
 standard deviation of 0.11 seconds.

 If I measure the time between the GET request and the HTTP 200 OK reply
 for the same site, the average would be 0.56 seconds with a standard
 deviation of 0.09 seconds for Tor without optimistic data, and the same
 measurement would be unchanged for Tor with optimistic data (logically).

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