[tor-dev] Optimistic SOCKS Data
Tom Ritter
tom at ritter.vg
Sat Jun 22 00:50:54 UTC 2019
The attached is a draft proposal for allowing tor to lie to an
application about the SOCKS connection enabling it to send data
optimistically.
It's going to need some fleshing out in ways I am not familiar with,
but I wanted to get something out to start as we think that this is
probably the best path forward for bringing back Tor Browser's
optimistic SOCKS behavior.
-tom
-------------- next part --------------
Filename: xxx-optimistic-socks-in-tor.txt
Title: Optimistic SOCKS Data
Author: Tom Ritter
Created: 21-June-2019
Status: Draft
Ticket: #5915
0. Abstract
We propose that tor should have a SocksPort option that causes it to lie
to the application that the SOCKS Handshake has succeeded immediately,
allowing the application to begin sending data optimistically.
1. Introduction
In the past, Tor Browser had a patch that allowed it to send data
optimistically. This effectively eliminated a round trip through the
entire circuit, reducing latency.
This feature was buggy, and specifically caused problems with MOAT, as
described in [0] and Tor Messenger as described in [1]. It is possible
that the other issues observed with it were the same issue, it is
possible they were different.
Rather than trying to identify and fix the problem in Tor Browser, an
alternate idea is to have tor lie to the application, causing it to send
the data optimistically. This can benefit all users of tor. This
proposal documents that idea.
[0] https://trac.torproject.org/projects/tor/ticket/24432#comment:19
[1] https://trac.torproject.org/projects/tor/ticket/19910#comment:3
2. Proposal
2.1. New SocksPort Flag
In order to have backward compatibility with third party applications that
do not support or do not want to use optimistic data, we propose a new
SocksPort flag that needs to be set in the tor configuration file in order
for the optimistic beahvior to occur.
The new SocksPort flag is:
"OptimisticData" -- Tor will immediately report a successful SOCKS
handshake and hang up if it gets an end cell
rather than a connected cell.
3. Application Error Handling
This behavior will cause the application talking to Tor to potentially
behave abnormally as it will believe that it has completed a TCP
connection. If no such connection can be made by tor, the program may
behave in a way that does not accurately represent the behavior of the
connection.
Applications SHOULD test various connection failure modes and ensure their
behavior is acceptable before using this feature.
References:
[RFC1928] https://www.ietf.org/rfc/rfc1928.txt
More information about the tor-dev
mailing list