Filename: ???-quickening-tor2webmode.txt Title: Making Tor2Web mode faster Author: Virgil Griffith, Fabio Pietrosanti, Giovanni Pellerano Created: 2014-02-23 Status: Open
1. Introduction While chatting with the Tor archons at the winter meeting, two speed optimizations for tor2web mode [1] were put forward. This proposal specifies concretizes these two optimizations. As with the current tor2web mode, this quickened tor2web mode negates any client anonymity.
2. Tor2web optimizations 2.1) self-rendezvous In the current tor2web mode, the client establishes a 0-hop circuit (direct connection) to a chosen rendezvous point. We propose that, alternatively, the client set *itself* as the rendezvous point. This coincides with ticket #9685 [2].
2.2) direct-introduction Identical to the non-tor2web mode, in the current tor2web mode, the client establishes a 3-hop circuit to the introduction point. We propose that, alternatively, the client build a 1-hop (or 0-hop?) circuit to the introduction point.
4. References [1] Tor2web mode: https://trac.torproject.org/projects/tor/ticket/2553 [2] Self-rendezvous: https://trac.torproject.org/projects/tor/ticket/9685
On Fri, Feb 28, 2014 at 12:03:10PM -0800, Virgil Griffith wrote:
- Tor2web optimizations
2.1) self-rendezvous In the current tor2web mode, the client establishes a 0-hop circuit (direct connection) to a chosen rendezvous point.
We actually call that a 1-hop circuit, because it has one relay in it.
A 0-hop circuit would be what you say below:
We propose that, alternatively, the client set *itself* as the rendezvous point. This coincides with ticket #9685 [2].
As Nick points out in that ticket, the tor2web node will need to have an ORPort open. For example, it could run as a bridge and set "PublishServerDescriptor 0" so the only incoming connections are rendezvous circuits.
It's actually an interesting research question whether this would indeed be faster -- in the proposed case some relay would have to do a new v3 tls handshake with the tor2web node (since you need an established OR connection before you can extend a circuit on it), whereas in the old case maybe there is already an established OR connection from the final hop in the hidden service's circuit to the rendezvous point (relay) that tor2web picked.
2.2) direct-introduction Identical to the non-tor2web mode, in the current tor2web mode, the client establishes a 3-hop circuit to the introduction point. We propose that, alternatively, the client build a 1-hop (or 0-hop?) circuit to the introduction point.
1-hop. 0-hop would be if the tor2web node is a relay and fortuitously the hidden service picked it as one of its intro points.
I'm surprised we don't already do this part -- it looks like a clear win for tor2web.
--Roger