[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: ISP controlling entry/exti ("Low-Resource Routing Attacks Against Anonymous Systems")
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: ISP controlling entry/exti ("Low-Resource Routing Attacks Against Anonymous Systems")
- From: Jon Doe <thew0tcher@xxxxxxxxx>
- Date: Mon, 26 Feb 2007 06:01:39 -0800 (PST)
- Delivered-to: archiver@seul.org
- Delivered-to: or-talk-outgoing@seul.org
- Delivered-to: or-talk@seul.org
- Delivery-date: Mon, 26 Feb 2007 09:01:57 -0500
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WJCphQR+3Dy30ObOWYSJzm2T1dQfrFmgIqNH2QadYPZGD8XxcNo2px9vxlcIXkBPhj379mpgNN0sGot3xezBCGTjRNnw/e+nDFpx9iNbstgWhF9bNJxHG/zq3nv6qp5A1imL4v/QLMPqrMErs61u3xBps3J2bG77LQ7BaG8OupU=;
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
xiando wrote:
>> Concerning an ISP controlling both entry and exit
nodes: when Tor
>> clients build paths, they avoid choosing two nodes
on the same /16
>> subnet (see path-spec.txt). So, it does not seem
that this is likely to
>> happen.
>>
>
> This is false. These are actually both at the same
ISP (Same datacenter, same
> provider):
>
> 72.9.108.50 - Tor router Nadia.
> 66.199.240.51 - Tor router Lillemy.
>
> In this case there's no simple way to figure out
that they are next to each
> other (sort if, four rows of racks away or something
like that). They're in
> MyFamily, so Tor knows not to use both of those in
the same path in this
> case, but it should be assumed that The Adversary
isn't going to tell Alice
> or Bob about it's involvement with multiple routers.
>
> Just to give another example, some of Norwegian
Goverument ISP
> Telenor's /16's:
>
> 85.167.0.0
> 80.213.0.0
> 80.212.0.0
>
> It don't know if this information really matters
regarding the paper in
> question. I just wanted to point out that looking at
/16, or /8 for that
> matter, does not in any way prevent one Tor circut
from going entirely within
> one ISP's network.
>
> Does it really matter? I don't know. Something like
the directory authorities
> looking at the servers netname: could be one way of
identifying routers
> within one ISP.
>
> But.. that'll probably help if the ISP is the
adversary. And this may be the
> case. So perhaps only one tor router pr. ISP would
be a good idea.
>
> It may also be the case that ISPs in a whole country
is the adversary, for
> example, SORM hardware connected to Federal Agency
of Government
> Communications and Information (FAGCI) is installed
at ALL the ISPs (There
> are some fights about this laid out the press from
time to time, some refuse,
> but generally speaking ISPs got SORM). FAGCI also
owns RELCOM, a major ISP.
>
> So FAGCI as the adversary: No exit/entry within
Russia in the same circut. But
> does listing a whole country as one family help? Is
it a good idea? Or is /16
> enough?
>
> My personal assumption is that if FAGCI wants to
know the location of US
> forces in Irak and around Iran - so they can pass it
on to Iran - and we
> assume they assuming the US use Tor for their
security...
>
> ...then FAGCI should just sign up Tor-servers at as
many different ISP's
> around the world as they can afford (And FAGCI is
very well-funded).
>
> Which kind of leaves the solution: Grow Bigger. Tell
your friends to run
> Tor-servers. Tell your corporation to do so. Tell
NSA and other branches of
> DoD to do so. And FAGCI. ;-)
>
> It's possible to change path-spec.txt to look at
ripe's netname:, or look at
> the country, or look at /8 instead of /16. But the
real answer as I see it is
> just a way bigger Tor-network, 800 routers, pfft,
setup 800 yourself and
> you're half the network. 8.000 routers, now it's
getting very expensive to be
> half the network.
>
>
>
This is all true of course and the US government could
well be paying
for around the globe Tor servers.
However, I believe this attack would be just as easily
committed by a
globally distributed religious group with a single
country at the centre
of the spy network.
The country I have in mind is Israel and international
jewery providing
the Tor server spy network. Also, Israel could pipe
off all the
international intelligence agency snoop data using
their moles within
worlds military, security and police services.
Together with jewish ownership/control of many ISP's,
all of this data
could all be pooled back in Israel to provide the
largest "global
adversary" in the world. Of course, occasionally,
Israel could give the
other intelligence agencies the odd tip here and
there, so as to keep in
their good books.
Just imagine up to 75% (currently) of the tor server
nodes could be so
easily be seen by Israel
How do you defend from such an adversary? (Thats a
question - I have no
answer! If someone does please tell all!)
I expect I'll get some flak here, particularly from
jews, or other
useful idiots who for one reason or another have been
duped into
assisting them. So I'll provide some proof. Don't take
my word for it,
see for yourself.
All of you gentiles who read this, should go to the
tor ortalk archive
and look at the names of tor operators who posted on
this mail list.
http://archives.seul.org/or/talk/
Then check the posters surname as to whether its
jewish or not.
Here's some useful links for this...
http://wsi.matriots.com/jews7.html (good general list
- but you have to
use your brain.
eg Gold = Old = Mold = Fold = Bold = Gould = Good =
Coward = Corn =
Field = Hay = Straw think in terms of "sounds like"
(Gould = Gold),
"spelt like" ([B,F,G,M]Old = Gold), "equivalent to"
(Good [as] = Gold)
and "looks like" Gold [color of] = Corn = Hay = Straw
= Sand = Beaches
(like Dingle Bay Sands in S.Ireland) = Celendine (a
yellow flower) =
Butter = Buttercup (yellow flower), "trans-language"
Feld = Field =
Felps = Philps = Phillips, "related to" Gold [color
of] = Corn [of] =
Field[Feld] = Hay = Straw)
http://www.avotaynu.com/holocaustlist/ (these are
nearly all jewish
names but some are converts/married into/taken names
eg Wallace
[originally Scottish], so beware, use your brain!)
Also, names to do with "prestige" (often valuable)
items/places/people.
eg Royal family surnames like.. Windsor.
London, Paris, Berlin etc.
Expensive hotels, fabrics, furs, cars, wine, drinks,
the printing
industry, the jewelery industry (from rings & watches
to pens), the fine
china industry, fine art work and antiques, law giving
(eg Judge =
Solomon = Wisdom = Wise = Salt[er] = [Al]Bright =
Shine), jewish
biblical characters (eg Sampson = Strong = Simpson),
Countries (eg
England, Ireland, Welsh, German), wood, rivers etc eg
babbyling
"Brook[s,ing]" = King Davids bloodline = Star[r] [of
David]).
Ok, so now you can do the numbers yourself.
My count is about 50-70% of the posters are jewish, or
of jewish
origin. If this is translated to % of tor servers
then that means about
50-70% are already run by jews!
And when they post that they have been attacked by
someone, like Mike
Perry (pear champagne - upper class cider!) did (MITM
attack), you can
bet your bottom dollar that they themselves are
carrying out such attacks!
The solution to MITM attacks is simple - 5 primary tor
servers who are
in telephone/personal contact with each other! They
send each other
large public keys on a regular basis. They then check
(random) portions
of the keys out over the phone or in person. Enough to
be sure there is
no MITM between them.
Then these servers publish public keys to a further
15 secondary key
servers who themselves are able to check some of the
keys over the phone
or in person. This pretty much guarantees 2 more
layers of entry security.
1. Primary public key node
2. Secondary public key node.
3. Current system entry nodes.
Then all the primary and secondary servers publish
large public keys (a
small list of) to both an internet web page (with save
key file to disk
feature) and on the tor directory. So that you can
verify (by copying
save to disk into torrc file) via other internet
access ports (eg
internet cafe) when we first enter (or declare
re-entry) the tor
network. This is not done every time we re-boot our pc
or re-connect
tor, just when we first connect (or force a
re-connect).
[If necessary, phone numbers can be supplied for
persons in areas (eg
just outside) where a know firewall adversary is
active eg China, so
that a primary check can be made on their first entry
key (or declared
re-entry) into the tor system.Obviously, it will take
more local
volunteers to assist in this if its done! Though it is
not relevant to
the core method]
Once a tor user or tor server have secured a genuine
public key upon
first connection they then hand to each of the 5
primary and 15
secondary public key server nodes a short list of
public keys that can
be used by any server to first contact them! This list
is published (and
updated/rotation wise regularly), securely, to all
directory servers.
They used in the first exchange with the usual tor
servers, they would
have to be broken before a MITM attack was possible.
By updating and
rotating keys regularly there would be little chance
of such an attack
(although it might be possible on a random basis - but
extremely
unlikely on a targeted attack). Anyone wishing to talk
to any tor node
then gets one key (random) from one of the key
servers. Not all the key
servers have to carry all the keys for all the tor
users, just a few are
held by each and only SERVER node public keys are held
at ALL. Ordinary
no server node users just get a public key from of a
server (after
initial MITM protect entry protection). Once this
occurs the directory
list is downloaded (multiplely if necessary) and these
should have MITM
free communication so should be genuine server keys.
Because of this MITM entry protection, ALL tor
communications will be
secure.
To simply re-connect (not a forced re-connect) your
tor uses the
previously stored directory list and link securely (no
MITM) to a key
server for a new master key and then get a new list.
All that is now required is a few new setting in
torrc.
1. List of check entry node keys pasted in (+ key node
node identity) -
as obtained form your internet cafe or verified
(partly at random) over
the phone.
2. A switch to specify how secure you want to initiate
a connection (and
obtaining tor directory list from).
Trust Primary Key Servers only
Trust Primary & Secondary Key Servers only
Trust P & S initialized (first connected) server nodes
only - No MITM
defense (as is currently used)
Trust All Servers - No MITM defense (as is currently
used) - fall back
if all else fails!
3. A switch to specify how secure you want your tor
circuit to be.
Trust P & S initialized (first connected) server nodes
only
Trust All Server - fall back if all else fails!
4. Specify list of Key server nodes to always use.
All 20 of the initialization (P&S) key servers must
have the following
information supplied on tor.eff.org website.
1. Real (and verified) name of operator or
organization (with nominal op
name).
2. Brief CV of the operator or description & location
of the
organization & server
3. Country of operation.
4. No. of years operator has been running tor server
for.
5. Verification that tor server is/is not
working/funded by or working
out of a military or intelligence agency funded
establishment.
6. Method of initialization public key checking being
carried out - eg
phone, personal visit
7. Frequency of public key churn.
If anything here is too onerous then just pare it
down. It should at
least have 5 Primary large key servers who can
guarantee they are not
MITMd and a web site to independently download their
rotated public keys
from.
If tor finds it is unable to confirm this primary
servers public key in
its initial directory then it should report "suspected
MITM", and a
check list come up (not from the web, that gives the
show away) with
further verification tests and places to contact for
advice.
____________________________________________________________________________________
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097