Hi,
Giorgio Maone:
>
> This *would* not work for Tor Browser users, because of NoScript's ABE
> built-in LOCAL rule, which prevents cross-zone (WAN to LAN) HTTP
> requests, if only ABE was enabled per NoScript's default configuration.
>
> See https://noscript.net/abe
>
> Unfortunately, ABE seems to be turned off by Tor Browser's custom
> configuration.
> Like in other cases, there's surely a valid rationale behind this choice.
> Mike, could you please explain it? Is there anything I can do to make
> ABE better suited for the Tor Browser's specific needs?
https://bugs.torproject.org/10419 is the one discussing how to defend
against the fingerprinting vector. We decided that ABE is not necessary
(avoiding its complexity) back then.
Georg
> -- G
>
> On 08/04/2015 14:51, tails-bugs@??? wrote:
>
>> Hi,
>
>> We received that email to tails-bugs.
>
>> Cheers.
>
>> From: Taylor Hornby <th@???>
>
>> Dear Tails Team:
>
>> I believe I have found a way for a malicious website in Tails to scan
>> the user's local network for running HTTP servers. This could be used to
>> fingerprint them (i.e. use the list as a sort of supercookie), or
>> possibly deanonymize them if they have a very unique configuration.
>
>> It works by using JavaScript to measure the amount of time it takes to
>> load the URL. This is done for every IP in the range 192.168.1.0/24.
>
>> Here's a proof of concept page that just prints out the load times in
>> milliseconds (warning: it starts running immediately when you open it):
>
>> https://defuse.ca/dev/tailssidechannel.html
>
>> (view source to see exactly how it works)
>
>> Here's a screenshot of what it produces on my network:
>
>> https://defuse.ca/dev/tailssidechannel.png
>
>> You can easily see from the output which IP addresses have a web server
>> running on port 80 (.11, .12, .25, .29, .30, ...).
>
>> Once an attacker knows an HTTP server exists at a given IP and port
>> number, they can start to profile what application is running on it. For
>> example, images could be loaded into HTML5 canvas and then returned to
>> the server. This way, if you had, say, a printer web administration
>> page, they could tell what make/model of printer you had by looking for
>> logo images. (I have not tried it; I'm not sure if same-origin-policy
>> would prevent it; but I don't think it would).
>
>> I wasn't able to test this with vanilla Tor Browser Bundle, since I
>> couldn't get it to run. I will do that as soon as I am home from
>> university.
>
>> An update: I tested with Tor Browser Bundle 4.0.6 (the latest), and it
>> does not have this problem. It looks like TBB blocks all requests to the
>> local network.
>
>> I also forgot to mention I was testing using Tails version 1.3.2 inside
>> a VirtualBox VM, in case that matters.
>
>> It would be really nice if Tails would block all non-Tor traffic from
>> kernel space when the "No" option is selected at startup. I'm sure this
>> has been discussed before, so there must be some reason it doesn't.
>
>> My PGP key for this email address is at:
>
>> https://defuse.ca/downloads/th.asc
>
>> The fingerprint is on my twitter:
>
>> https://twitter.com/DefuseSec/status/575767865552306176
>
>> -Taylor
>
>
>
>> _______________________________________________
>> Tails-dev mailing list
>> Tails-dev@???
>> https://mailman.boum.org/listinfo/tails-dev
>> To unsubscribe from this list, send an empty email to
> Tails-dev-unsubscribe@???.
>
>
>
>
>
>
> _______________________________________________
> Tails-dev mailing list
> Tails-dev@???
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
>