Hi,
we discussed this on IRC and failed to be truely convinced by either
side of things. Here is a bit more thorough discussion of this
matter... and related ones, as it seems like the problem is quite
wider than initially expected.
> Beginning by cons, disabling this setting would slow down the
> connections to AJAX style websites like modern webmails or so.
The fact the web browser usually opens a bunch of concurrent
connections to such a website multiplies this a bit.
> But having it set to true would make iceweasel having persistent
> connections to websites. Persistent connections sounds bad, because it
> means a Tor route is maintained to a website for the time of this
> connection,
Just to make it clear, using default FF configuration, the maximum
lifetime of such a persistent connection is:
Normal Tor route lifetime
+ network.http.keep-alive.timeout
= 10 + 5 minutes
= 15 minutes
> which could break the anonymity.
I am still interested in hearing how this can break anonymity.
(Neither joking nor willing to be sarcastic.)
> It does also break the use of the "new identity" button, when the
> user want to use another route to a given website.
*This* is where the real issue is IMHO, but I strongly disagree with
the subject of this sentence ("It").
Sure, Vidalia currently notifies the user *new* connections will use
new routes, but our target user typically does not know about
persistent connections.
On the other hand, preventing linkage between various Web activities
would not be solved at all by disabling HTTP keep-alive: asking for
new Tor routes without closing the web browser, even if HTTP
keep-alive is disabled, means engaging in new Web activities without
resetting the browser state (e.g. cookies) => these "new" Web
activities could be linked to the "old" ones despite the Tor routes
change and the lack of HTTP keep-alive. It looks to me like the use
case you are concerned about ("user wants to use another route to a
given website") is particularly affected by such linkage attacks as
this situation typically applies to websites that require user
authentication... and cookies to be enabled (e.g. GMail or alike).
Moreover, FF is not the only shipped application that maintains
persistent connections to the Internet: Pidgin and Gobby, probably
among others, do so as well.
=> I don't think that disabling HTTP keep-alive would be a solution to
this issue.
However, an issue does exist and the current state of things in
T(A)ILS could be considered as violating the PELD specification we've
been writing:
It MUST be made as difficult as possible for the user to unknowingly
compromise anonymity.
It mainly depends whether we consider linkage between unrelated
activities to "compromise anonymity". Going as far as this would be
nice from a general security/anonymity point of view, but I don't
think this is actually doable nowadays: e.g. if the user uses IM under
a given contextual identity while browsing the Web using another, Tor
currently provides no way (AFAIK) to prevent linkage of these
identities together (a proposal to make unlinked activities use
different routes is being worked on, but not implemented yet).
The issue we are facing is no matter of configuring this or that
application differently, it's rather a general OS-level problem I
don't believe we can solve with technical means as of today.
So in the current state of things, I think we should not interpret the
specification as requiring the PELD to isolate unrelated (concurrent
or sequential) Internet activities.
The keyword in the specification sentence I am quoting therefore
appears to be "unknowingly" I think. My proposal would then be:
1. Patch Vidalia notification message (upstream if possible, only our
custom package else) to:
- make it clear existing persistent connections won't use new routes
- provide some simple examples of possible applications that are
susceptible to keep connections open (FF, IM)
- practical workaround hint: explain such applications shall be
closed before asking for new routes
2. Add about the same text in T(A)ILS end-user documentation, probably
in a less concise way as we are not restricted by popup size
constraints; we should explain step-by-step how to workaround such
issues.
Hmm?
[...]
> Having a look at this option, it seems there is also a
> "network.http.keep-alive.timeout" setting, which by default seems to
> be set to 5 minutes (I guess, cause my Iceweasel setting has this
> value, and I don't remember having modified it).
> So maybe an alternative would be to lower this timeout to something
> like 2 or 3 minutes only.
Speaking about practical consequences of such a modification, this
would:
- decrease the maximum lifetime of FF's HTTP persistent connections
from the default 15 minutes to 10+2=12 or 10+3=13 minutes. I must
say I don't clearly see what kind of good using such seemingly
randomly chosen magic numbers would do. Going from 150% to 125% of
the Tor routes lifetime makes little sense to me. Switching to a
very low timeout value, such as 15 or 30 seconds, would make more
sense, as it would make the maximum HTTP connection lifetime very
close (i.e. 102.5% or 105%) to the Tor routes lifetime. Effects on
performance would need to be investigated a bit if we decide to go
this way.
- slightly increase the chances a given persistent connection timeouts
before next Tor routes turnover; the probability for this is
currently 0.5, and this change would increase it to 0.7 or 0.8. I
don't like so much playing with probabilities strictly lower than 1,
without being able to guarantee anything. Moreover, these calculated
probabilities are only true in the ideal mathematical world: in many
real-file cases, there are good chances a website that opens a
connection to Facebook servers will re-open it as soon as the
keep-alive timeout expires; in such a case lowering the HTTP
keep-alive timeout value does not offer single bit of additional
protection.
Anyway, considering the range of the problem uncovered by bertagaz'
question, which I believe I have demonstrated to be considerably wider
that expected, I think we should first think and make decisions about
the general picture rather than focusing on this FF setting. We may
need to get back to it at some point though.
Bye,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Every now and then I get a little bit restless
| and I dream of something wild.
