On Mon, 5 Aug 2019 at 18:33, Tom Ritter <t...@ritter.vg> wrote: > > On Tue, 2 Jul 2019 at 09:23, Tom Ritter <t...@ritter.vg> wrote: > > Or... something else? Very interested in what David/asn think since > > they worked on #30382 ... > > I never updated this thread after discussing with people on irc. > > So the implementation of > SOCKS-error-code-for-an-Onion-Service-needs-auth implementation is > done. David (if I'm summarizing correctly) felt that the SOCKS Error > code approach may not be the best choice given our desire for > optimistic data; but felt it was up to the Tor Browser team to decide. > > In the goal of something that works for 90%+ of use case today, the > rest later, I'll propose the following: > > In little-t tor, detect if we're connecting to an onion site, and if > so do not early-report SOCKS connection. > > Another ugly option is to early-report a successful SOCKS connection > even for onion sites, and if we later receive an auth request, send an > HTTP error code like 407 that we then detect over in the browser and > use to prompt the user. I don't like this because it is considerably > more work (I expect), horrible ugly layering violations, and I don't > think it will work for https://onion links.
I attached an updated proposal taking this into account, and I'd like to request it be entered into torspec's proposals list. -tom
Filename: xxx-optimistic-socks-in-tor.txt Title: Optimistic SOCKS Data Author: Tom Ritter Created: 21-June-2019 Status: Draft Ticket: #5915 0. Abstract We propose that tor should have a SocksPort option that causes it to lie to the application that the SOCKS Handshake has succeeded immediately, allowing the application to begin sending data optimistically. 1. Introduction In the past, Tor Browser had a patch that allowed it to send data optimistically. This effectively eliminated a round trip through the entire circuit, reducing latency. This feature was buggy, and specifically caused problems with MOAT, as described in [0] and Tor Messenger as described in [1]. It is possible that the other issues observed with it were the same issue, it is possible they were different. Rather than trying to identify and fix the problem in Tor Browser, an alternate idea is to have tor lie to the application, causing it to send the data optimistically. This can benefit all users of tor. This proposal documents that idea. [0] https://trac.torproject.org/projects/tor/ticket/24432#comment:19 [1] https://trac.torproject.org/projects/tor/ticket/19910#comment:3 2. Proposal 2.1. Behavior When the SocksPort flag defined below is present, Tor will immediately report a successful SOCKS handshake subject for non-onion connections. If, later, tor recieves an end cell rather than a connected cell, it will hang up the SOCKS connection. The requirement to omit this for onion connections is because in #30382 we implemented a mechanism to return a special SOCKS error code if we are connecting to an onion site that requires authentication. Returning an early success would prevent this from working. Redesigning the mechanism to communicate auth-required onion sites to the browser, while also supporting optimistic data, are left to a future proposal. 2.2. New SocksPort Flag In order to have backward compatibility with third party applications that do not support or do not want to use optimistic data, we propose a new SocksPort flag that needs to be set in the tor configuration file in order for the optimistic beahvior to occur. The new SocksPort flag is: "OptimisticData" -- Tor will immediately report a successful SOCKS handshake subject for non-onion connections and hang up if it gets an end cell rather than a connected cell. 3. Application Error Handling This behavior will cause the application talking to Tor to potentially behave abnormally as it will believe that it has completed a TCP connection. If no such connection can be made by tor, the program may behave in a way that does not accurately represent the behavior of the connection. Applications SHOULD test various connection failure modes and ensure their behavior is acceptable before using this feature. References: [RFC1928] https://www.ietf.org/rfc/rfc1928.txt
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev