[tor-relays] TTTT

2014-04-01 Thread Sebastian Urbach 

Dear list members,

It will take a bit longer than expected to bring the scoreboard and 
surrounding systems up again. As it turns out one system was compromised 
and another machine ran in some hardware trouble. We need to change 
settings and possible buy new hardware as well.


We are working as fast as possible to get everything back on track, so 
please stay with us.


Sorry for the interruption.
--
Mit freundlichen Grüssen / Sincerely yours

Sebastian Urbach

--
Those who would give up essential Liberty,
to purchase a little temporary Safety,
deserve neither Liberty nor Safety.
--
Benjamin Franklin (1706 - 1790),  Inventor,
journalist, printer, diplomat and statesman


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Lots of tor relays send out sequential IP IDs; please fix that!

2014-04-01 Thread Jann Horn 
On Mon, Mar 31, 2014 at 11:12:05PM +0200, Jann Horn wrote:
> Well, the subject line pretty much says it all: Lots of Tor relays send out
> globally sequential IP IDs, which, as far as I know, allows a remote party to
> measure how fast the relay is sending out IP packets with high precision,
> possibly making statistical attacks possible that could e.g. pinpoint the 
> entry
> guard a user or hidden service uses.

Strike "possibly". I picked a random Tor relay from my "probably affected" list
(Winston) and put "EntryNodes Winston" into the config of PC 1 (victim). Then I
started "hping3 -r -i 2 -p 443 --syn 143.229.213.186" on PC 2 (attacker).

While the hping process on PC 2 was running, I ran
"torify curl http://var.thejh.net/trailer_400p.ogg"; on PC 1 for a while, then
canceled it.

hping3 output before launching curl:
len=44 ip=143.229.213.186 ttl=117 DF id=16154 sport=443 flags=SA seq=0 win=1460 
rtt=95.7 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+33 sport=443 flags=SA seq=1 win=1460 
rtt=95.7 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+20 sport=443 flags=SA seq=2 win=1460 
rtt=95.1 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+30 sport=443 flags=SA seq=3 win=1460 
rtt=95.6 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+49 sport=443 flags=SA seq=4 win=1460 
rtt=96.3 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+22 sport=443 flags=SA seq=5 win=1460 
rtt=96.4 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+10 sport=443 flags=SA seq=6 win=1460 
rtt=95.8 ms

hping3 output while curl is running:
len=44 ip=143.229.213.186 ttl=117 DF id=+20 sport=443 flags=SA seq=7 win=1460 
rtt=96.2 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+208 sport=443 flags=SA seq=8 win=1460 
rtt=102.2 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+156 sport=443 flags=SA seq=9 win=1460 
rtt=102.3 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+167 sport=443 flags=SA seq=10 win=1460 
rtt=97.8 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+181 sport=443 flags=SA seq=11 win=1460 
rtt=104.2 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+170 sport=443 flags=SA seq=12 win=1460 
rtt=96.4 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+157 sport=443 flags=SA seq=13 win=1460 
rtt=95.4 ms

hping3 output after stopping curl:
len=44 ip=143.229.213.186 ttl=117 DF id=+142 sport=443 flags=SA seq=14 win=1460 
rtt=95.5 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+44 sport=443 flags=SA seq=15 win=1460 
rtt=95.6 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+8 sport=443 flags=SA seq=16 win=1460 
rtt=95.6 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+10 sport=443 flags=SA seq=17 win=1460 
rtt=96.2 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+16 sport=443 flags=SA seq=18 win=1460 
rtt=95.8 ms
len=44 ip=143.229.213.186 ttl=117 DF id=+3 sport=443 flags=SA seq=19 win=1460 
rtt=95.6 ms


As you can see, the id field's values looked VERY different while PC 1 was
downloading lots of data over the relay.


Yes, true, it looks as if this node is relatively idle, and it's probably not
THAT easy against relays that are used more. But I hope that this shows you
that this is not just a theoretical attack.


signature.asc
Description: Digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Lots of tor relays send out sequential IP IDs; please fix that!

2014-04-01 Thread Daniel Bilik 
On Tue, 1 Apr 2014 02:56:38 +0200
Jann Horn  wrote:

> I scanned a good portion of all the tor exit nodes now, this is the
> distribution of operating systems for the suspicious-looking relays:
> ...
> So, looks as if Windows and FreeBSD are the problems.

Good catch. On FreeBSD this can be tuned via sysctl...

sysctl -w net.inet.ip.random_id=1

... and added to /etc/sysctl.conf so that the setting is not lost on next
reboot. Default value for this tunable is 0.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays