Hello,
I think the best approach for elliminating the false positives
would be to make the scanner perform the timing inference attack
as described in the paper.
Unfortunately I don't have enough time to look into this more.
Cheers,
David
On Thu, Nov 17, 2016 at 09:22:47PM +, dawuud
On 21/11/16 14:43, Olaf Selke wrote:
> Am 19.11.2016 um 16:49 schrieb Alex Haydock:
>>
>> There are some graphs showing (the lack of) network diversity here,
>> which are interesting to look at:
>>
>> http://torstatus.blutmagie.de/network_detail.php
>
> yes, this chart displays routers' domain
Am 19.11.2016 um 16:49 schrieb Alex Haydock:
There are some graphs showing (the lack of) network diversity here,
which are interesting to look at:
http://torstatus.blutmagie.de/network_detail.php
yes, this chart displays routers' domain country codes
Another view on the blutmagie live
Hi,
I don't really want to derail this thread, and I'm sure it's been said
before, but I'd love to put in a plug for the TorBSD Diversity Project here:
https://torbsd.github.io/
As a whole, the network is pretty homogeneous in terms of its reliance
on the Linux kernel so kernel bugs and
Hi Jason,
Thanks for your observation. I'll try to investigate soon.
Cheers,
David
On Thu, Nov 17, 2016 at 12:02:05PM -0500, Jason Ross wrote:
> Hi David,
> Thanks for the heads up! It turns out that my relay is in the list of
> affected hosts, however, the kernel I was running
Hi all,
I'm sorry that there are some false positives.
I did previously test against a FreeBSD tor relay and presumed NetBSD
would have a similar result.
Thanks for looking closely at this Ivan.
It sounds like the scanner needs to be fixed.
I'll try to test with a netbsd host soon.
Cheers!
Hi David,
Thanks for your work!
dawuud:
> I added the scan output to the repo, this includes the output csv file
> and a list of vulnerable relays:
>
> https://github.com/david415/scan_tor_rfc5961/blob/master/scan_archive/nov17_2016/probe_out.csv
>
On a Raspberry pi... Linux 4.4.26+ #915 Thu Oct 20 17:02:14 BST 2016
armv6l GNU/Linux
$ netstat -s | grep -i challenge
TCPChallengeACK: 10
(no TCPSYNChallenge result ??)
Le 17/11/2016 à 20:24, Univibe a écrit :
> My relays have been patched to the latest available kernels, and
> aren't in
On a Debian 8 updated relay too :
# netstat -s | grep -i challenge
TCPChallengeACK: 19497
TCPSYNChallenge: 12991
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64
GNU/Linux
Something else for being sure ?
Le 17/11/2016 à 20:24, Univibe a écrit :
> $ ansible tor -a
My relays have been patched to the latest available kernels, and aren't in the
list of vulnerable relays, however they still show high values for
TCPSYNChallenge:
$ ansible tor -a 'bash -c "netstat -s | grep -i challenge"' -b --ask-become-pass
lon | SUCCESS | rc=0 >>
TCPChallengeACK:
Hi David,
Thanks for the heads up! It turns out that my relay is in the list of
affected hosts, however, the kernel I was running (3.16.36-1+deb8u1)
is claimed by Debian to be fixed (see:
https://security-tracker.debian.org/tracker/CVE-2016-5696).
Since your script determines whether the host is
Hi.
I added the scan output to the repo, this includes the output csv file
and a list of vulnerable relays:
https://github.com/david415/scan_tor_rfc5961/blob/master/scan_archive/nov17_2016/probe_out.csv
Greetings Tor relay operators,
First of all, if you operate non-Linux Tor relays then good job!
Thanks! This notice isn't for you. Only Linux is affected.
This morning I scanned the tor network for vulnerability to
CVE-2016-5696 [1], again so that I could compare the results with the
scan
13 matches
Mail list logo
