u:
> On 26.03.19 12:01, sajolida wrote:
>> u:
>> It's good to see you on our discussion channels :)
>>
>>> On 22.03.19 15:47, Nicolas Vigier wrote:
>>>> On Fri, 22 Mar 2019, sajolida wrote:
>>>>> 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?
>>>>
>>>> It seems the extension is currently only downloading an unsigned json
>>>> file with https to verify the checksums, so someone controlling the
>>>> website could return a bad json file.
>>>
>>> Correct.
>>>
>>>> So it looks like in both cases (the extension and javascript on the
>>>> website), an attacker controlling the website could make it possible
>>>> for a bad download to be seen as good by the user. However there is
>>>> still maybe a small difference:
>>>> - with javascript on the website, an attacker controlling the website
>>>> could just disable the verification and claim that any download is
>>>> good.
>>>
>>> Correct.
>>>
>>>> - with the extension, an attacker controlling the website could replace
>>>> the json file with one that contain a different checksum. However
>>>> they have to guess what the user will have downloaded from the mirrors,
>>>> which is maybe not easy if only one of the mirrors is bad. This is
>>>> assuming that the extension only accepts json files containing only
>>>> one value for the checksum, which I don't know if it is the case.
>>>
>>> The JSON file can technically contain many files and their checksums.
>>
>> Or the same attacker controlling the website can pretend that the
>> verification is done by the (genuine) extension but display a malicious
>> result on the page, pretending that the download is correct.
>>
>> With my very little understand of JavaScript and browser security, I
>> think that the question here is whether the web page is a more risky
>> environment to run our JavaScript than the extension. But either way, we
>> can't protect from an attacker controlling the website or what is
>> displayed on our download page.
>>
>>>> With the current version of the extension, I don't know if it makes a
>>>> big difference. However if there was some plan to improve the extension
>>>> to make it verify gpg signatures, then that could be a big difference.
>>>
>>> Agreed.
>>
>> The first version of the extension was actually doing certificate
>> pinning: verifying that the SSL certificate of the website was signed by
>> the correct certificate authority. We dropped this security feature last
>> year when switching to Web Extensions. Having the extension do other
>> kind of verification (eg. OpenPGP) would achieve something similar.
>>
>> But since we can't protect anyway from an attacker who can control the
>> website or what is displayed on our download page, having the extension
>> do more elaborate verifications might not bring much.
>
> …unless the logic of the verification extension changes substantially:
>
> it could alert the user differently than by using postMessage and
> display failure messages in the browser using some sort of ugly browser
> popup instead of displaying the information on our website. Then the
> website can not interfere. I did not check if this is possible technically.
The website could hijack the work of the extension before it even gets a
chance to do the verification or the website could even pretend that no
verification is needed.
Yesterday we talked again really briefly about this with jvoisin and he
restated the fact that moving the verification code from the extension
to the website doesn't increase the attack surface in any relevant way,
regarding general browser and JavaScript vulnerabilities. And again for
the same reason: even if the code in the extension is not exploited, the
code (JavaScript AND HTML) on the website is the weakest link here.
--
sajolida
