Re: [Tails-dev] Security implications: moving code from Ver…

Delete this message

Reply to this message
Autor: sajolida
Data:  
Para: The Tails public development discussion list
Assunto: Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Daniel Kahn Gillmor:
> hi all--
>
> thanks for bringing this discussion, and your reasoning for it, to the
> broader community.


:) Thanks for chiming in!

> On Wed 2019-03-20 14:25:50 +0100, u. wrote:
>> We know from Javascript statistics of our download page that roughly
>> ~20% of the downloads of Tails images are verified by users using the
>> verification extension. The optional OpenPGP verification accounts for
>> 9% of downloads (computed using the number of downloads of the OpenPGP
>> signature). This means that >70% of Tails downloads might currently not
>> be verified at all.
>
> These numbers are pretty interesting. how do you know that OpenPGP
> verification accounts for 9% of the downloads? are you just measuring
> the number of signature files downloaded?


For the verifications and the downloads, last year we put in place a
"counter" on some events on the download page. Search for "hitCounter"
on https://tails.boum.org/install/inc/js/download.js.

Note that, apart from the review of this JS code done by lamby, nobody
else than me really looked into the way I'm computing these stats and
there might very well be a non-obvious bug in them.

For the OpenPGP verification, yes, I took the number of downloads of the
signature file.

We also don't know why we only have 20% of verification vs hits on the
download button. It sounds quite a lot to me for people being reluctant
or lazy to install the extension but I don't know how to check that.

We also wondered whether it was worth it to analyze all this more in
depth if moving from an extension to the website was cheap enough and
with no security drawbacks.

> In any event, it sounds like you're making a (sensible) case for moving
> from:
>
> 70% unprotected +
> 20% extension-protected +
> 10% OpenPGP-protected.
>
> to:
>
> 90% website-protected +
> 10% OpenPGP protected


It's the idea.

> That's clearly a net win for 70% of downloads, which go from unprotected
> to website-protected, but it's also a net loss for 20% of users, who go
> from protection by the extension to protection by website javascript.


Whether there's a security loss for the 20% of users who currently use
the extension is precisely what we are asking more opinions about.

For example, jvoisin's primary reaction on this thread is that it's
doesn't have any significant downsides.

What makes you think that doing the verification in the extension would
be less secure than doing the verification on the website? What kind of
attacks are we talking about here?

I'm myself completely ignorant on these matters and need to hear expert
voices that I can trust :)

> This would a clearer, unequivocal win if we retained the extension,
> right? then it would go to:
>
>    70% website-protected +
>    20% extension-protected +
>    10% OpenPGP-protected

>
> which is strictly better than all the other scenarios from a
> verification standpoint.


This would require explaining on the download page that people can
choose between the extension and the website verification, what are the
pros and cons, etc. It would require more UX work on our side, more
changes to the page, and more work for the user to make the right
choice, which is something that we thought we could avoid with the
design of our iteration #1 (it doesn't change the design of the page).

> Is the concern that it's too expensive to maintain both the extension
> and the javascript going forward?


The maintenance of the extension itself is not really expensive
(10 hours/year). Maintaining both might not be much either but we need
to be sure that the added complexity is worth it for our users and also
justifies the first implementation cost. Until now I'm really not convinced.

> If the expense of maintaining the extension is too much, i wonder
> whether image verification is the ultimate concern at all. For example,
> should we be considering other approaches like external, spot-checked
> download verification with monitoring and reporting, as some measure of
> resilience against non-targeted attack? (maybe this is already in place
> and i just don't know about it)


If it's what you mean, we already download the images served by our
mirrors daily and check their integrity.

Something else we want to detect here are interrupted downloads. I think
that modern browser do a better job at this (eg. the *.part extension of
Firefox) but I think that we never really researched whether interrupted
download could still be an issue with other browsers.

> thanks for thinking about these tradeoffs clearly and publicly. i wish
> all projects were capable of communicating these legitimate concerns as
> effectively as Tails does.


You're welcome :)

--
sajolida