[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] tor-talk Digest, Vol 52, Issue 18



> On 9 May 2015, at 12:21 , tor-talk-request@xxxxxxxxxxxxxxxxxxxx wrote:
> 
> Message: 7
> Date: Fri, 8 May 2015 19:21:29 -0700
> From: coderman <coderman@xxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Friendly LAN bridge -- bad idea?
> Message-ID:
> 	<CAJVRA1Ss+eBQO8BxcaVCy+SnZLX6SNbHYAtKF66S2XsweeFRqg@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
> 
> On 5/8/15, l.m <ter.one.leeboi@xxxxxxxx> wrote:
>>> There may be other security implications of a shared Tor client.
>> 
>> Such as
>> 
>> 1. All users that share a tor client also share a threat model. The
>> tor configuration is shared. This may not be an ideal property.
>> 2. If one user of the shared tor client breaks the process--it's
>> broken for all others. Which is to say a bug, exploit, failure will
>> affect all users simultaneously.
> 
> there are also stream isolation concerns, see options
> IsolateClientAddr, IsolateSOCKSAuth, IsolateClientProtocol,
> IsolateDestPort, IsolateDestAddr, etc.
> 
> better to have each client run their own Tor, and a router / gateway
> which can tell Tor Launcher a specific bridge or PT for Tor network
> access.

I want to correct earlier advice about trading separate external guards per client for a single bridge for all clients:
* in either case, network-level observers will know that people at your institution use Tor
* if your local bridge is compromised, all your users could be de-anonymised; if a guard is compromised, one of your users could be de-anonymised. So using a bridge would be like assigning the same guard to all the users at your institution, reducing the chances that one person is using a compromised guard, at the cost of having you all de-anonymised at once if that happens to your bridge.
Tor uses guards for this very reason - it's better to have a very small chance of having all connections compromised, than a large chance of having some connections compromised.

If your threat model includes government or institutional log or monitoring requests, that's worth considering, too.

It really depends how resistant your local bridge is to compromise, institutional, and legal pressure.

Aggregating Tor traffic can be great for privacy - "no, we know you traced it back here, but can't tell you who it was", but only if you avoid logging connections between the clients and the bridge. So make sure (detailed) logging is turned off on any clients, intermediate routers or firewalls, and on the bridge itself.

teor

teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk