[tor-dev] Optimistic SOCKS Data

[David Goulet]

On 08 Oct (19:49:34), Matthew Finkel wrote:
> 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.

I think indeed this could work!

Proposal 304 specifies errors up until a rendezvous failure so should we then
only send back the SOCKS reply once the rendezvous circuit has been
established (upon reception of the RENDEZVOUS2 cell)?

It could be seconds in real life before that reply is given back to Tor
Browser so not sure if optimistic data will worth anything there :P ...?

Another option exists: In my experience, failing a rendezvous is much more
rare than failing an introduction. In other words, if the introduction is
successful, chances are very good that you'll rendezvous. Which means that we
could send back the SOCKS reply after a successful introduction and drop the
rdv error from prop304?

> 
> 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.

As we discussed the other day, we have this "Stream ID" problem as in for an
emitted control event (for a stream), TB needs to associate it with the right
tab basically.

We basically have two options here I believe. Either TB sends us a unique
identifier that could become an exported ID on the event by encoding it in the
SOCKS username/password somehow.

Else, tor sends it back to TB within the SOCKS reply. That one leads to a race
where the control event is likely to be fired _before_ the SOCKS reply and
thus TB will have to handle async event vs the SOCKS reply.

Else else, theoritical, maybe the current u+p from TB per tab is already
enough but I doubt since I'm guessing it is the same u+p for two tabs on the
same .onion?

Cheers!
David

-- 
muPNmU1nkiEFKr9f9HH4gmfbJilH9zaFLRGFIqcNBQg=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20191009/615180aa/attachment.sig>