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.
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.
In particular, this allows using most of the proposed onion service error codes in the SOCKS5 reply. I think the control protocol should still emit event messages describing the errors, but this will allow using synchronous error handling, as well.