[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 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 :/.

 > > 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?

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