[tor-dev] Optimistic SOCKS Data

[Matthew Finkel]

On Wed, Oct 2, 2019 at 5:46 PM Nick Mathewson <nickm at freehaven.net> wrote:
>
> On Fri, Sep 27, 2019 at 1:35 PM Tom Ritter <tom at ritter.vg> wrote:
> >
> > On Mon, 5 Aug 2019 at 18:33, Tom Ritter <tom at ritter.vg> wrote:
> > >
> > > On Tue, 2 Jul 2019 at 09:23, Tom Ritter <tom at 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.