Re: [Tails-dev] [Tails-news] Tails 3.13.2 is out

Supprimer ce message

Répondre à ce message
Auteur: Georg Koppen
Date:  
À: The Tails public development discussion list
Sujet: Re: [Tails-dev] [Tails-news] Tails 3.13.2 is out
sajolida:
> anonym:
>> Georg Koppen:
>>> Tails - News:
>>>> This release is an emergency release to fix a critical security vulnerability
>>>> in _Tor Browser_.
>>>>
>>>> It also fixes [other security
>>>> vulnerabilities](https://tails.boum.org/security/Numerous_security_holes_in_3.13.1/).
>>>> You should upgrade as soon as possible.
>>>>
>>>> # Changes
>>>>
>>>> ## Fixed _NoScript_ activation in _Tor Browser_
>>>>
>>>> Starting from Friday May 3, a problem in _Firefox_ and _Tor Browser_ disabled
>>>> all add-ons. This release reactivates all add-ons in _Tor Browser_, especially
>>>> _NoScript_ which is used to:
>>>>
>>>> * Most importantly, protect against a very strong fingerprinting technique called _HTML5 canvas fingerprinting_ which can break your anonymity.
>>>
>>> Hm. How does it do that? In particular, what does it do in addition to
>>> the defense we baked into Tor Browser and which is not NoScript
>>> dependent? (see the: "Specific Fingerprinting Defenses in the Tor
>>> Browser", subsection 2. HTML5 Canvas Extraction at
>>> https://2019.www.torproject.org/projects/torbrowser/design/)
>>
>> There's been a misunderstanding. We were supposed to talk about fingerprinting enabled by the loss of NoScript's WebGL click-to-play, not HTML5 canvas fingerprinting.
>
> Hi Georg!
>
> So good to see that you keep an eye on our release notes :)


You are welcome :)

> I'm acting here as a mere translator of the technical knowledge that
> intrigeri transmitted to me in
> https://redmine.tails.boum.org/code/issues/16694#note-14 and that I
> could read on https://2019.www.torproject.org/projects/torbrowser/design/.
>
> I understood that HTML5 canvas fingerprint can use a combination of
> "WebGL, font, and named color" and that "WebGL Canvases have
> click-to-play placeholders (provided by NoScript)".
>
> So, a website could benefit from NoScript being deactivated to use WebGL
> to do HTML5 canvas fingerprinting; even though Tor Browser on its own
> could block other canvas fingerprinting attempts.
>
> And from a user's point of view, NoScript protects them from (some types
> of) canvas fingerprinting.
>
> Isn't it?


Well, not really. First of all, the canvas fingerprinting blocker is
effective regardless whether one has WebGL allowed or not. Before
anything is extracted from an HTML <canvas> element you get at least a
prompt whether you want to allow to return valid image data or not.
That's regardless whether WebGL is available in that process or not.
Thus, even if NoScript would not be enabled there should be no way that
WebGL could be used for canvas-based fingerprinting without the user
allowing it.

Now, you could argue that *if* users allowed canvas fingerprinting they
would be better off entropy-wise if the potentially available WebGL
parts would be behind a click-to-play option. Maybe. I am not convinced
yet, though, that this would make a big or an actual difference.

Click-to-play placeholders have been there from the beginning as there
were *security* concerns with WebGL which are orthogonal to the
fingerprinting ones. The latter we have patched we think, so
fingerprinting-wise we should be good (or at least not bad). NoScript in
general in a Tor Browser context is only used for dealing with
potential security/usability trade-offs covered by the security slider.
In that sense it's a bit weird to have NoScript put WebGL behind
click-to-play by default as we claim on the default security mode all
web features work as expected and are enabled.

We have corrected that for 8.5 in that we place WebGL behind
click-to-play as we do for HTML 5 media on higher security levels but
have it enabled otherwise. An important role played here websites that
were subtly non-working with WebGL behind click-to-play or blatantly
broken without any sign of options for fixing that. I suspect there are
more and more libraries in use that check for WebGL capabilities and
just refuse to proceed if non are detected. :(

The medium-term plan is to actually raise the default security level Tor
Browser comes with to "safer", but that's not going to get accomplished
in the next couple of weeks. It's not even clear what trade-offs we need
to make to that mode to make it somewhat acceptable as a default setting.

Georg