Re: [tor-talk] Possible upcoming attempts to disable the Tor network

[Ben Tasker <ben@xxxxxxxxxxxxxxx>]

I'm far from an expert on Tor, but:

> The key is that they will be programmed to redirect users towards the
backup DirAuths servers only once the backup plan
> has been activated. Before this happens, no one should possibly be able
to learn the locations of the backup DirAuths from > these public Gateways.

Assuming a software update isn't required to 'activate' these gateways in
the event of a compromise (and if it is, new DirAuths could just as easily
be pushed that way - as is the case now).

Whilst the code on the 'gateways' might be encrypted, will anything be
needed client side to handle the redirect? If so, what's to stop an
adversary from using the client codebase to develop something 'good enough'
to trigger a redirect to their malicious DirAuths.

I'm assuming you'd send a message signed with a specific key and have the
client verify it? What happens if the Gateways (which the client's
presumably know about) are also seized/compromised after the relevant keys
have been delivered to them?

In terms of a trust model, assuming the keys for the Gateways are
compromised (or a weakness in the implementation found giving the same
effect), presumably the response of the Gateways overrides the 10 DirAuths?
Potentially reducing the effort needed for an attack to 3 or 4 gateway
machines?

I'm not poking holes in your idea, it's more it's caught my interest and
raised a few questions in my mind.


10 Servers spread around different jurisdictions is still quite a challenge
to mount, though not impossible (though as I understand it, as it's
consensus based, they don't need all 10).

But given the widespread effect it would have, they'd have to be able to
support the argument that interfering with the routing of every Tor user
was reasonable in their stated goal - that'd probably carry in some
jurisdictions, but is unlikely to in others.

> A careful and knowledgeable examination of the different state
jurisdictions concerning warrant authorization, or eventually
> known habits to bypass them, etc...

I've no idea whether the operators of the DirAuth's have looked at this
(though I'd be surprised if some haven't) but looking at the processes used
(or ignored) in the relevant countries definitely seems like a worthwhile
effort to me.


On Tue, Dec 23, 2014 at 11:23 PM, Alexis Wattel <alexiswattel@xxxxxxxxx>
wrote:
>
> Hello,
>
> First I'd like you to know that I'm not deeply familiar with the internals
> of Tor infrastructure.
> However I'm reasonably confident to have grasped one fundamental aspect of
> this issue, being that Tor routing depends first and foremost on 10 servers.
>
> Because decentralizing this system will imply a major infrastructure
> evolution, I think that the priority for now is to find a quicker and
> temporary workaround.
>
> TL;DR: Straight facts are between the lines.
>
> Whatever be their ground, these threats seriously expose what could be a
> single point of failure for any capable adversary.
> This attack would in my opinion inflict devastating damage to the Tor
> network, mainly because of a complete reversal of the psychological balance
> between Tor promoters and adversaries. (*)
>
> So 10 servers would need to be seized or compromised to launch this attack.
> For a legal seizure, the different jurisdictions to which those servers
> belong need to be studied at least a little, to determine how easy/hard it
> would be for a politically influent state to obtain cooperation from each
> and every local police force.
> As for an illegal compromise, the challenges are very different and a lot
> has to be thought about.
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> In a few words, here's what I thought could be a somewhat quick to deploy
> temporary defense plan.
> As the 10 DirAuths servers are hard coded, why not make use of that
> existing feature? I mean :
> Hard code several additional backup servers.
> Those cannot directly be DirAuths servers themselves, because obviously
> the same problem would arise. These would be Gateway servers.
>
> The key is that they will be programmed to redirect users towards the
> backup DirAuths servers only once the backup plan has been activated.
> Before this happens, no one should possibly be able to learn the locations
> of the backup DirAuths from these public Gateways.
>
> To achieve this, the code that will manage the transition to the backup
> DirAuths will be encrypted. The backup plan will include the delivery of
> the needed cipher keys to these Gateways enabling them to now happily
> redirect users to fully functional DirAuths (whose location was not
> (supposed to be) known until that time).
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Legal actions to seize servers in different jurisdictions requires lots of
> preparatory work, meaning lots of time. It then appear possible to use this
> aspect to our advantage.
> A careful and knowledgeable examination of the different state
> jurisdictions concerning warrant authorization, or eventually known habits
> to bypass them, etc... could build a great basis on which to implement our
> beloved security-in-depth principle applied to the juridical world. It's
> all about multiplying the barriers...
>
> I think this strategy could build a powerful defense against an attempt to
> instantly knock down of the whole network using this discussed mean of
> attack.
>
> However, the major difficulty my suggestion would struggle against is that
> the complete deployment of these backup servers, especially the DirAuths
> ones, must be conducted with great stealth.
> It will take the most cleverly skilled hackers devoted to the Tor Project
> to adress this issue, issue that I once again consider to be a major one.
>
> Although laying this idea on the table could hopefully light up
> considerable improvement ideas to help any backup deployment to operate
> safely.
>
> Moreover, what are your thoughts on this short-term contingency plan?
>
> Respectfully,
> Alexis Wattel
>
> * I'll elaborate on why I think that this attack could have serious
> adverse impacts on the Tor network if anyone whishes to discuss it.
>
> P.S.: This being my first contribution to a mailing list, I hope I got the
> citation formatting right! ;)
>
> > Tyler Durden:
> >
> >
> >> > So is there no need for some more trusted dir authorities? I mean
> >> > 10 for the whole networks seems a bit tiny.
> --
> 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
>


-- 
Ben Tasker
http://www.bentasker.co.uk

One Server to rule them all,
One Ping to Find Them,
One LAN to bring them all,
And in the darknet BIND them.

- The Tolkien Ring Network

01001001 01100110 00100000 01111001 01101111 01110101 00100000 01100011
01100001 01101110 00100000 01110010 01100101 01100001 01100100 00100000
01110100 01101000 01101001 01110011 00100000 01111001 01101111 01110101
00100000 01100001 01110010 01100101 00100000 01100001 01110011 00100000
01110011 01100001 01100100 00100000 01100001 01110011 00100000 01001001
00100000 01100001 01101101

Command line Russian Roulette: [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / ||
echo *Click*
-- 
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