[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 MikePerry201210 tbb-bounty  |         Parent:  #3890                        
   Points:                                                    |   Actualpoints:                               
--------------------------------------------------------------+-------------

Comment(by t55wang):

 Replying to [comment:19 mikeperry]:
 > I guess I got confused by your above comments in response to the
 behavior of the browser patch (which given the localization and SSL issues
 does seem better than the Tor patch). Just to clarify your above comments:
 The DNS failure/typo case for the browser patch results in a "Connection
 reset" message with the current browser SOCKS patch?
 >
 > If so, we might want to come up with some sort of way to retry failed
 requests like that without optimistic data... You say the SOCKS state
 machine already retries for that failure case, though? That seems weird to
 me...

 In Tor Firefox, before my modification, you'd get a "Connection Reset"
 message. After my modification, you'd get a "Unable to Connect" message,
 after two or three seconds (when I tried it). In original Firefox, not the
 Tor browser, you'd get a "Server not found" message. (this makes a bit of
 sense when you consider that in optimistic data we sort of assume the
 server always agreed to the SOCKS connection, so it can't be "not found")

 Retrying without optimistic data sounds interesting, but I'm not exactly
 sure why. Is there a situation under which Tor browser with optimistic
 data would not be able to find the server but Tor browser without it
 would?

 I misunderstood when I replied earlier; what I meant is that the SOCKS
 state machine has a number of retry mechanisms when certain things fail
 (one of which I manipulated to get optimistic data in), For your
 particular case, it does not in my patch. The browser sends the GET
 request optimistically and any failure is simply reflected as a failure of
 the GET request.

 I think it may be possible to both match the error messages perfectly and
 force a retry with optimistic data by playing with the state machine more
 cleverly. I'm not sure about this though. I haven't managed to do so, and
 this seems to work anyway.

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