[tor-dev] Tor proposals implemented in Tor 0.2.3.x

[Fabian Keil]

Ian Goldberg <iang at cs.uwaterloo.ca> wrote:

> On Sat, Jun 30, 2012 at 07:03:19PM +0200, Fabian Keil wrote:
> > Nick Mathewson <nickm at freehaven.net> wrote:
> > 
> > > IMPLEMENTED IN 0.2.3.x
> > 
> > >    174  Optimistic Data for Tor: Server Side
> > >    181  Optimistic Data for Tor: Client Side
> > > 
> > >      This one is a performance hack that hasn't seen its full impact
> > >      yet.  Starting with Tor 0.2.3.x, clients MAY send data to the
> > >      exit node before finding out whether the exit has been able to
> > >      successfully connect to the destination server.  Previously, it
> > >      took an extra round trip for clients to wait to see whether the
> > >      exit said "Yes, I'm connected" before they were allowed to send
> > >      data for the exit.
> > > 
> > >      This should make connection startup faster in many protocols
> > >      where the client speaks first (http, https), as more and more
> > >      client programs gain support for it.
> > 
> > Is optimistically sending data for non-testing purposes recommended?
> > 
> > The "Security implications" in 181 seem to imply that it isn't,
> > but the man page doesn't mention any risks. Is that because they
> > are considered obvious, or simply an oversight?
> 
> The issue is that an exit node that supports optimistic data can tell
> when a client is using that feature.

I'm aware of that, additionally I would expect that webservers can
(with some probability) tell as well.

>                                       So if only a handful of clients
> have upgraded to a TBB that supports it (none does at this time),
> they'll stand out.  That's why the default is "use the consensus value",
> which is currently off.  The consensus value can be turned on later,
> when "enough" people can support it.

The default can be changed, though, and while the man page
contains recommendations and even strong recommendation for
other parameter values, there's no recommendation for or against
changing the OptimisticData settings and the risks aren't
mentioned either.

The TorBrowser isn't the only client that could optimistically send
data and other clients (like Privoxy) will need an option for this,
that the user has to explicitly enable.

It's inappropriate for Privoxy's documentation to make recommendations
for or against modifications of Tor's OptimisticData option, therefore
it would be great if the Tor man page contained such a recommendation
so the Privoxy documentation can link to it without putting the user
at risk of changing the option after reading Tor's man page without
understanding the consequences.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20120701/6f068fcc/attachment.pgp>