[tor-talk] messing with XKeyScore

Matthew Finkel matthew.finkel at gmail.com
Sat Jul 5 03:59:28 UTC 2014

On Fri, Jul 04, 2014 at 09:36:23PM +0000, isis wrote:
> Hash: SHA512
> Eugen Leitl transcribed 5.8K bytes:
> > 
> > http://blog.erratasec.com/2014/07/jamming-xkeyscore_4.html?m=1 
> > 
> > Errata Security
> > 
> > Advanced persistent cybersecurity
> > 
> > Friday, July 04, 2014
> > 
> > Jamming XKeyScore
> > 
> > Back in the day there was talk about "jamming echelon" by adding keywords to email that the echelon system was supposedly looking for. We can do the same thing for XKeyScore: jam the system with more information than it can handle. (I enumerate the bugs I find in the code as "xks-00xx").
> > 
> > 
> > For example, when sending emails, just send from the address "bridges at torproject.org" and in the email body include:
> > 
> > https://bridges.torproject.org/
> > bridge =
> > bridge =
> > bridge =
> > ...
> > 
> > Continue this for megabytes worth of bridges (xks-0001), and it'll totally mess up XKeyScore. It has no defense against getting flooded with information like this, as far as I can see.
> > 
> Hi. I maintain and develop BridgeDB.
> For what it's worth, the released XKS rules would not have worked against
> BridgeDB for over a year now. I have no knowledge of what regexes are
> currently in use in XKS deployments, nor if the apparent typos are errors in
> the original documents, or rather typos in one of the various levels of
> transcriptions which may have occurred in the editing process. If these typos
> were at some point in the original rules running on XKS systems, then *no*
> bridges would have been harvested due to various faults. None.
> Ergo, as Jacob has pointed out to me, the regexes which are released should be
> assumed to be several years out of date, and also shouldn't be assumed to be
> representative of the entire ruleset of any deployed XKS system.
> I am willing to implement tricks against specific problems with them, mostly
> for the lulz, because fuck the NSA. But it should be assumed that the actual
> regexes have perhaps been updated, and that highly specific tricks are not
> likely to land.
> The ticket for this, by the way, was created by Andrea this afternoon, it's
> #12537: https://trac.torproject.org/projects/tor/ticket/12537

In reality it's a bit silly to try to mess with these rules if they are
n-years old. Based on the pics, simply requesting that all users use
bridges at bridges.torproject.org instead of bridges at torproject.org is the
easiest change that by-passes this specific set of rules. But, I
think it is more realistic that these minor points are moot and the
regexes were fixed long ago and that the ruleset more fully covers
Tor's distributors now.

This problem makes me sad on many levels, and I'm not opposed to
implementing mitigation techniques (within reason) based on the
rulesets, however we shouldn't do anything that will hurt our users nor
should be do anything that makes tor more difficult to use
(unfortunately this includes sending users bogus bridge addresses).

For the use-case of bridges, where a user tries to circumvent local
network interference and implicitly expects they're not fingerprinted
by NSA, we are mostly failing right now.

More information about the tor-talk mailing list