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 - [email protected]
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Reply via email to