[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Abusing Root-CA attack on tor
- To: or-talk@xxxxxxxx
- Subject: Abusing Root-CA attack on tor
- From: unknown_x@xxxxxxxxxxxxx
- Date: Thu, 3 Aug 2006 22:05:13 +0400
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivery-date: Thu, 03 Aug 2006 14:05:29 -0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=N1-0105; d=Safe-mail.net; b=R26gr6JN292lG3olud+PMMs9C4zDWhTeWlVsvBZR+bk8p656T4hy8E8RH2IQENDb pXu9fxy5nvAN6xx/RgAQsSAX9AJSyovJkVj3zf36AZc4tKf0XSEGD0+X1La8uYIQ VcDNmB0u4dLmCXq5CwEh1Kq177gJmKrTLq7ShNcmV7M=;
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
//Abusing Root-CA attack on tor
I present you my idea of a new attack,
fully deanonimysating and decrypting in realtime tor (and mixminion)
traffic with using and abusing secret key of tor network.
Tor network consist from independent servers generating many keys and stats
material. This peaces of stats combined in a directory servers and
signing with secret key of tor network.
Directory servers works like a trusted CA (certification authorithy).
Secret key works like a root certificate, belong to developers (Root CA).
Public part of this key is contained in each tor client or server. Users trust it.
Can developers or owners Root C abuse it to make eavsdroping?
At first look, this is impractical. If developers will starting forging keys of
independent servers and sign it with Root C, too many users and servers
will detect it, switch off from the network and drop down the reputation
I found another way to make it undetectable.
1). Agent Mallory get the root key of tor network from developers (using servers
hacking, secret stealing, law sanction, interrogation pressure, etc).
2). Mallory go to Isaac - ISP (Internet Service Provider) of Alice and
install AntiTor Interception Device, consist:
(Network Adress Translator) with packet field (like TTL) correction and
b) Virtual Machine (Simulator of tor network, full of false
keys, signed with Root C - key of tor network).
c) Modified tor client
d) NAT retransmitter
f) control software
3). If Alice connect to any site without tor Mallory just sniffing
traffic like Eve.
4) If Alice want to download tor stats from any IP
consisting in list from Mallory module "a", Mallory intercept her request
with NAT-interceptor and inject into module "b". Virtual machine simulate
connection with this IP adress and return false stats to Alice. This
stats signed with right stolen tor network secret key - Root C!
5) Alice start anonymous connection to Bob using false stats through tor. She
select a random chains, encrypt traffic and think: "I'm anonymous"!
6) Every IP selected Alice and consisted in real tor network tor stats
list intercepted by module "a" and injected into module "b". Module "b"
simulate tor network, decrypt Alice traffic in realtime by false keys
and deanonimasing Bob IP adress or every Alice network activity.
7) Mallory know all about Alice traffic in clear from module "b". He's know
about Alice selected tor chains too. Mallory use this chains in module
"c". This tor clien encrypt Alice trafiic with this chains for retransmit
in real tor network with module "d". Traffic going to Bob or any other web
Alice can view correct tor exit node IP from random selected
chains in every web resource.
More about modules:
1) Module "b" may start generating false keys before Alice connection and download
real tor network stats periodically to produce false stats.
2) Modules "a" and "d" not only
select and intercept tor traffic, but forge packet fields to be seems
correct for Alice and Bob.
3) Module "b" simulate traffic in virtual
tor network, based on false stats and used to decrypt it and extract Alice
1) This method can be generalisated for
massive eavsdroping for group of tor users on ISP.
Or for more ISP using more interception devices.
2) This method can be used against any other anonymous protocol (mixmaster,
mixminion), based on trusted CA.
3) Developers can easy save the
reputation and deny Root Certificate abuse. Users can see correct open
source code, analyze protocols, but they can't detect trusted CA abuse
4) It's a combination and generalisation of two classical types of
attack "man-in-the-middle" and Root CA abuse.
Thanks for attention.
//Unknown X (www.PGPru.com project member)