[tor-dev] Optimistic SOCKS Data

[George Kadianakis]

David Goulet <dgoulet at torproject.org> writes:

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

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?