David Goulet dgoulet@torproject.org writes:
On 08 Oct (19:49:34), Matthew Finkel wrote:
On Wed, Oct 2, 2019 at 5:46 PM Nick Mathewson nickm@freehaven.net wrote:
On Fri, Sep 27, 2019 at 1:35 PM Tom Ritter tom@ritter.vg wrote:
On Mon, 5 Aug 2019 at 18:33, Tom Ritter tom@ritter.vg wrote:
On Tue, 2 Jul 2019 at 09:23, Tom Ritter tom@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.
Okay! This is now proposal 309.
I went for a walk and I came to the realization that we're going about this (a little bit) wrong.
Thanks for the updates Matt!
The advantage of optimistic data is that application data is available when tor sends the RELAY_BEGIN cell (therefore it is able to send a RELAY_DATA cell immediately after the RELAY_BEGIN cell is sent). So, tor doesn't need to reply immediately, just early enough such that the application can start writing data on the connection.
For exit connections, Tor should probably reply a success/failure immediately (where failures result from impossible connection requests or other early failures).
For onion service connections, tor can reply much later. I might suggest as late as successfully retrieving the onion service descriptor. Of course, this will introduce a race between the application writing data and tor completing the introduction and rendezvous, but this may be worth the risk.
So are you suggesting that we can still do SOCKS error codes? But as David said, some of the errors we care about are after the descriptor fetch, so how would we do those?
Also, please help me understand the race condition you refer to. I tried to draw this in a diagram form: https://gist.github.com/asn-d6/55fbe7a3d746dc7e00da25d3ce90268a
IIUC, for onions the advantage of opportunistic SOCKS is that we would send DATA to the service right after finishing rendezvous, whereas right now we need to do a round-trip with Tor Browser after finishing rendezvous. Is that right?
If that's the case, then sending the SOCKS reply after the rendezvous circuit is completed would be the same as the current behavior, and hence not an optimization, right?
And sending the SOCKS reply after the introduction is completed (as David is suggesting) would be an optimization indeed, but we lose errors (we lose the rendezvous failed error, which can occur if the onion service is under DoS and cannot build new circuits but can still receive introductions).
What other problems exist here?