Stand-alone downloads of program assets has a security implication

June 2, 2024

I recently read Engineering for Slow Internet (via), which is about what it talks about and also about the practical experience of trying to use the Internet in Antarctica (in 2023), which has (or had) challenging network conditions. One of the recommendations in the article was that as much as possible you allow people to do stand-alone downloads with their own tools for it, rather than forcing them to download assets through your program (which, to put it kindly, may not be well prepared for the Internet conditions of Antarctica). In general, I am all for having programs cope better with limited Internet (I used to be on a PPP dialup modem link long after most people in Canada had upgraded to DSL or cable, and it was a bit unpleasant), but as I was reading the article it occurred to me that supporting people getting assets your program will use through their own downloads can change the security picture of your application a bit, possibly requiring additional changes in how you do things.

When a modern application fetches assets of some sort over HTTPS from a URL that you fully specified (for example, a spot on your website), most of the time you can assume that the contents you fetched are trustworthy. The entire institution of modern web PKI is working (quite well) to keep bad people from easily intercepting and altering that flow of data. Only in relatively high security situations do you need to add some sort of additional end to end security verification, like digital signatures; a lot of the time you can just assume 'we got it over HTTPS from our URL so it's good'.

(Even with fetching assets over HTTPS, signing your assets provides safety against various attacks, including attackers who compromise your website but not your signing infrastructure.)

This is obviously not true any more if you accept files that were downloaded outside of your program's control. Then you're relying on the person using your software to have not been fooled about where they got the files from and to not have had the files quietly swapped out or provided by malicious other software on their machine. Since you didn't fetch these assets yourself, if you need trust in them it will have to be provided in some additional way. If you aren't already digitally signing things, you may need to start doing so (with all of the key management hassles this involves, and potential key expiry, and so on), or perhaps fetch a small list of cryptographic hashes of the assets from your website while allowing the person to provide you the asset files themselves.

(On common systems, some things you want to download may already be signed due to general system requirements, for example program updates.)

This is not just about the security of your program. This is also somewhat about the security of people using your program, in terms of what they can be tricked into doing by a malicious asset that they accidentally download from the wrong place. Attackers definitely already use various forms of fake program updates, compromised installers, and so on, with various additional tricks to direct people to those things.


Comments on this page:

By Andrew at 2024-06-03 11:11:33:

Signing the assets is in general better security for that kind of usecase than merely authenticating the server. See also the whole "APT has HTTPS disabled by default" thing.

If you're distributing content (especially the executable kind that will run on a million people's machines), sign the content. HTTPS is a thin veneer of security by comparison.

Written on 02 June 2024.
« Phish tests and (not) getting people to report successful phish attacks
CVEs are not what I'll call security reports »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sun Jun 2 23:42:06 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.