Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
u: > Hi all, > > In summary of this discussion, I would conclude that we agree that we > can and should abandon the Verification Extension and move the code to > our website. > > Thank you all for your insightful ideas & comments. Full ack. Regarding JS caching: - I agree with intrigeri that the caching might become a bit more sensitive than the current situation. For example, since we rolled out the current page, we haven't done any security update to the JS on the page and only functionality updates, while we did push security updates to the code of the extension (mostly Forge updates). - But I agree with Ulrike that we shouldn't block on solving #16091 as we can rely on the URL parameter trick (eg. 4e30a3e59b) to force reloading resources after security updates. We should include a check about this in the release process for updating this code. We won't be releasing extensions anymore but we should keep at least the test suite in a checklist whenever we update this code or new ESRs come out, etc. -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi all, In summary of this discussion, I would conclude that we agree that we can and should abandon the Verification Extension and move the code to our website. Thank you all for your insightful ideas & comments. Cheers! u. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi! On 26.04.19 14:51, intrigeri wrote: > u: >> On 16.04.19 14:29, intrigeri wrote: > >>> One rather minor implementation note, that's relevant in this context >>> only because any software is only as secure as the _version run by >>> actual users_: this migration increases the need to ensure web >>> browsers use the correct version of the relevant web resources (such >>> as JavaScript files), to replace the extension version check we >>> currently have, which is done for every download. At the moment JS can >>> be cached for 24h. We have a ticket about this already; I think it >>> needs to be part of the migration plan. > >> I don't think this increases this need: it's still the same as it is >> now, as the Installation Assistant already uses Javascript files hosted >> on the server. > > Fair point, a component of the big picture is already subject to this > problem, so perhaps having even more code subject to this problem does > not change anything substantially. I don't know and I don't feel > competent to analyze the consequences of this further myself. The best > I can do is to clarify some technical details that might be useful to > whoever wants to dig deeper. So, this proposal replaces: > > A. code, that currently lives in the current extension, and does its >own version checking independently of JS caching policy: it only >relies on data it gets from a HTML page that should not be cached >by browsers > > with: > > B. code that can be retrieved from the browser cache > > And in both cases, as Ulrike mentioned, there's another piece of > cooperating JS code, that lives on our website and can already be > retrieved from the browser cache. I've noted some of your remarks (cross-origin policy + file caching) this on the ticket description of https://redmine.tails.boum.org/code/issues/16128 However, currently we do this version check to check if the extension verification is up to date on user's browsers. When implementing the code on the website instead, the worst that will happen is that some users live with 24 hours of cached JS code - that we can actually force to be reloaded with methods described in the ticket I linked previously, hence I believe the concern is even less concerning than in the current setup (that requires intervention from users to update their extension). >> Is the ticket you are talking about this one: >> https://redmine.tails.boum.org/code/issues/16091? (It's about CSS, not >> JS, but I suspect the exact same issue applies.) > > Yes. I've just made it more generic :) Seen :) Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi! On 16.04.19 14:29, intrigeri wrote: > jvoisin: >>> General security implications >>> - >>> >>> The question we are asking ourselves is: are there any predictable >>> downsides to move the verification code from an extension to the website? > >> I don't see any significant downsides. > > I could not find any either, as long as the threat called [H] in the > design doc of the current system can be mitigated, either in the same > way as what we currently do (see Cross-origin communication and > Content Security Policy paragraphs) or in other ways. Noted. I think that we would need to and we'll be able to tighten the Cross-origin policy compared to what the extension currently does. > One rather minor implementation note, that's relevant in this context > only because any software is only as secure as the _version run by > actual users_: this migration increases the need to ensure web > browsers use the correct version of the relevant web resources (such > as JavaScript files), to replace the extension version check we > currently have, which is done for every download. At the moment JS can > be cached for 24h. We have a ticket about this already; I think it > needs to be part of the migration plan. I don't think this increases this need: it's still the same as it is now, as the Installation Assistant already uses Javascript files hosted on the server. Is the ticket you are talking about this one: https://redmine.tails.boum.org/code/issues/16091? (It's about CSS, not JS, but I suspect the exact same issue applies.) Cheers! u. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi, jvoisin: >> General security implications >> - >> >> The question we are asking ourselves is: are there any predictable >> downsides to move the verification code from an extension to the website? > I don't see any significant downsides. I could not find any either, as long as the threat called [H] in the design doc of the current system can be mitigated, either in the same way as what we currently do (see Cross-origin communication and Content Security Policy paragraphs) or in other ways. One rather minor implementation note, that's relevant in this context only because any software is only as secure as the _version run by actual users_: this migration increases the need to ensure web browsers use the correct version of the relevant web resources (such as JavaScript files), to replace the extension version check we currently have, which is done for every download. At the moment JS can be cached for 24h. We have a ticket about this already; I think it needs to be part of the migration plan. > I think that having the verification happening on the website will > vastly improve the user experience and is a great idea. +1 Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
sajolida: > u: >> 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. What about the downloads via bittorrent? There the OpenPGP signature is bundled with the image, so we can't really tell how many of the bittorrent downloads are additionally verified via the signature. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Thanks to everyone for talking through the details. On Fri 2019-03-22 15:47:23 +0100, Nicolas Vigier wrote: > 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. I think i agree with Nicolas here. I was working under the misunderstanding that the extension did verify the OpenPGP signatures, apologies for not following this closely enough earlier. --dkg signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
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 ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi! 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. Cheers! u. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
u: > 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. This week-end I thought about another elements that could partly explain this low 20% figure. The counter we have on /install/download counts the number of times the "Download" button is clicke, which might be very different from the number of times someone actually finishes downloading Tails. Especially when downloading something big like Tails, downloads might be interrupted and restarted, people might realize it's that big only after starting the download, etc. The counter on this button also introduced a tiny glitch: clicking on the button now opens a new blank tab and then closes it immediately to start the download. See 19a0c6cca1. I don't know how bad the impact of this glitch is but I'm pretty sure it has some. -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
u: > On 22.03.19 02:24, Daniel Kahn Gillmor wrote: >> Is the concern that it's too expensive to maintain both the extension >> and the javascript going forward? > > Ideally we'd only maintain one of those, but I think your idea is good: > if we could increase verification by having an internal mechanism, this > would be an improvement. However, the question remains: what happens if > an attacker controls the website? If an attacker controls the website we're screwed anyway. See attack [C] of our threat model: https://tails.boum.org/contribute/design/verification_extension/#index3h2 -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
u: > Hi! Hi Nicolas, 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. See the discussion we had about this in October 2017: http://lists.autistici.org/message/20171026.135200.28962b40.en.html -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi!
On 22.03.19 02:24, Daniel Kahn Gillmor wrote:
> Is the concern that it's too expensive to maintain both the extension
> and the javascript going forward?
Ideally we'd only maintain one of those, but I think your idea is good:
if we could increase verification by having an internal mechanism, this
would be an improvement. However, the question remains: what happens if
an attacker controls the website?
> 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)
I'm not quite sure what you mean but we regularly and automatically
check that all the mirrors serve correct images ({IMG, ISO} + SIG are
checked), independently of the individual verification that users should
do when downloading an image. But there might be a delay with us
reacting to this if a mirror is compromised.
Cheers!
u.
___
Tails-dev mailing list
Tails-dev@boum.org
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
Hi! 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. > 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. Cheers! u. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
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. 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. - 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. 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. Nicolas signature.asc Description: Digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
jvoisin: >> General security implications >> - >> >> The question we are asking ourselves is: are there any predictable >> downsides to move the verification code from an extension to the website? > > I don't see any significant downsides. Ok, that's a pretty straight-forward statement :) Actually, I wanted to have you Julien involved in this discussion because I thought I remembered you saying in the past that doing the verification in the extension was be a safer place than doing it directly on the website. But again, I'm completely ignorant on these matters and I will trust you blindly if you tell me that it won't be a security to do the verification on the website. > I think that having the verification happening on the website will > vastly improve the user experience and is a great idea. Yeap. With my UX hat on, I couldn't agree more :) -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
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 ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
> General security implications > - > > The question we are asking ourselves is: are there any predictable > downsides to move the verification code from an extension to the website? I don't see any significant downsides. I think that having the verification happening on the website will vastly improve the user experience and is a great idea. ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Security implications: moving code from Verification Extension to our website
hi all-- thanks for bringing this discussion, and your reasoning for it, to the broader community. 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? 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 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. 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. Is the concern that it's too expensive to maintain both the extension and the javascript going forward? 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) 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. --dkg signature.asc Description: PGP signature ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Security implications: moving code from Verification Extension to our website
Hi security people, after working on the Verification Extension for the USB image project, I proposed to get rid of it and integrate the Javascript code that performs the verification directly into our website [1]. Today I'm writing to you because we need your valuable input on the security implications that such a move might have. We lack these skills in our team and would appreciate your help. Below, I'll describe the current state of things, the possible benefits of this move and then I'll try to outline the security question we have. Current state of things --- Users download Tails images via mirrors operated by volunteers. When installing Tails, we advise users to verify the files downloaded using the Verification Extension, that currently works in Firefox and Chrome. The extension only downloads a JSON file located at tails.boum.org over HTTPS, and checks that the hashsum we provide matches that of the user downloaded Tails image. 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. Benefits of moving this code directly into our website -- - More users could more easily verify the images they download. (Note that we don't have metrics for the percentage of users affected, because we lack a detailed analysis of why so few users verify their download.) - It will increase usability for users, as they won't have to install an extension anymore. - Downloads could possibly be verified using other browsers, like Safari and recent versions of IE. (Note however that these browsers currently represent only 1% of visitors to the download pages.) - There'll be a bit less maintenance work for us, but not much: as we would still have to test the code regularly. General security implications - The question we are asking ourselves is: are there any predictable downsides to move the verification code from an extension to the website? If needed, details about the security threats and measures of the extension can be found in our design documentation [2]. Cost Replacing the extension is going to cost money: A rough estimate is that it'll require ~100 hours of work from developers, UX designers, technical writers, managers, and accountant to make this happen, in two iterations (see [1] for a detailed implementation plan). Glad to read your thoughts! Thank you for your input, u. [1] https://redmine.tails.boum.org/code/issues/16128 [2] https://tails.boum.org/contribute/design/verification_extension/ ___ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
