[tor-talk] messing with XKeyScore

[isis]

Sebastian Hahn transcribed 2.5K bytes:
> 
> On 05 Jul 2014, at 15:08, Roman Mamedov <rm at romanrm.net> wrote:
> 
> > On Sat, 5 Jul 2014 03:59:28 +0000
> > Matthew Finkel <matthew.finkel at gmail.com> wrote:
> > 
> >> 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).
> > 
> > Well, what is the format of a E-Mail response with a bridge list?

The format is best described in torspec.git/pt-spec.txt, [0] given as:

[["Bridge"] SP] [[METHOD] SP] IP:PORT [SP [FINGERPRINT]] [[[K=V] "," [[K=V] ","]] …]

BridgeDB currently doesn't include the "Bridge" prefix (and hasn't for just
upwards of one year now) due a backwards-compatibility issue with Vidalia. [1]
Meaning that a correctly formed bridge line currently looks like this:

obfs4 1.2.3.4:11111 abcdef0123456789abcdef0123456789abcdef01 sekrit=fu,password=bar

TorLauncher is smart about this, and if a bridge line (such as this one)
doesn't start with "Bridge", then TorLauncher rewrites the line before adding
it to the user's torrc file:

Bridge obfs4 1.2.3.4:11111 abcdef0123456789abcdef0123456789abcdef01 sekrit=fu,password=bar

The same obviously happens when configuring bridges in Tails, because Tails
now uses TorLauncher. The biggest problem we've seen here is that users cannot
correctly/accurately type a bridge's fingerprint.

> > If it's just plain text, why not instead send them as a picture in attachment,
> > with bridge IP addresses encoded in CAPTCHA style to not be machine-readable.
> 
> Because it makes it harder for humans to use, and doesn't help. Watching
> the bridge authority gives you a list of bridges, too - no need to read
> emails.
> 
> There are no "quick fixes" to global surveillance, and we shouldn't
> forget our users when deploying questionable countermeasures.

I agree with Sebastian and Matthew. I'm not willing to deploy something which
makes it more difficult for legitimate Tor users to obtain/utilise
bridges. It's already difficult enough to correctly type a fingerprint.

There are plans to move towards implementing rBridge [2], which would allow
legitimate users to receive new bridges automatically and anonymously. There
is, however, no funding for this work. Either way, due to implementation
difficulty (largely due to certain prerequisite cryptographic primitives of
the anonymous authentication scheme) and integration with Tor Browser, this
will take me and the other volunteers quite some time. Give or take, 2-3
years.

[0]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/pt-spec.txt#l27
[1]: https://trac.torproject.org/projects/tor/ticket/5851
[2]: http://freehaven.net/anonbib/#ndss13-rbridge

-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
GPG: 4096R/A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1154 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20140708/7b92853d/attachment.sig>