On the other hand, the Windows and OS X App Stores are awful. Linux package managers are looking like one of the only straightforward ways to distribute applications securely.
Barring a situation where a CDN hosting the download is compromised but the main site is not hosted on the CDN, it's extremely unlikely that someone would have the ability to inject malware into the download and not have the ability to make the checksum match. Posting checksums is actually pretty useless, and was something that used to be used to deal with the possibility of malicious mirrors, but doesn't provide any security against mitm attacks (unless the main site is secure but the downloads aren't which is idiotic by 2016 standards anyway), the site getting hacked, etc.
Digital signatures are a little bit better if the key is kept safe, since hacking the site and replacing the binary won't allow a random person to produce a valid signature, although ability to modify the source code would still allow someone to introduce backdoors into the next version, but there's still a huge problem where you need some way to determine what key was supposed to be used to sign the binary in the first place, so just posting a signature on a website is also basically useless.
Digital signatures can work if there's some sort of centralized distribution method, or for safely updating software that's already installed.
Given trust in the protection of the private key used to sign the hash list file the integrity of the executable content can be proved (assuming useful SHA1 collision creation is prohibitively expensive).
Coincidentally I was writing a Bash script this weekend to auto-install (Ubuntu) releases into LVM volumes and it includes the following code to verify the download:
set -e
# ...
ISO="${NEW_DIST}-desktop-${ARCH}.iso"
for F in SHA1SUMS SHA1SUMS.gpg ${ISO}; do
if [ ! -r $F ]; then
wget http://cdimage.ubuntu.com/${FLAVOUR}/daily-live/current/$F
fi
done
if ! gpg --verify --keyring /etc/apt/trusted.gpg SHA1SUMS.gpg SHA1SUMS; then
echo "Error: failed to verify the hash file list signature; files may have been tampered with"
exit 2
fi
if ! grep ${ISO} SHA1SUMS | sha1sum -c; then
echo "${ISO} is corrupted; please try again"
exit 1
fiDoesn't seem like a horrible idea to me: you could just add the developer's key to your client, have your client broadcast interest, receive a _signed_ list of available software with appropriate magnet info... Download servers could serve as initial trackers until enough information has propagated through the network for downloads to be trackerless. Checksums? Guaranteed. Signatures? Acquired. Checking? Performed automagically.
Granted, this just moves the point of failure to the developer's key. (Key acquisition needn't necessarily take place on the developer's site, a friend in the network could pass you a link containing the dev's key and the application's magnet info.)
It's not idiotic at all. You let anyone who wants to spread the load by providing downloads, but you use checksums - behind https - to ensure they can be trusted.
"By default". Most developers don't bother to register, and lots of people change the default (and after that, they can right click to open the app and bypass the warning).
I have to admit that Windows' UAC is better in that regard, as it shows the signees name. But of course this is only useful if you know the "right" name.
[0] http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...
(There is third party tool named RB App Checker which does make these tasks a bit easier, though)
――――――
¹ — https://en.wikipedia.org/wiki/Installer_(OS_X)
² — http://f.cl.ly/items/1s1E3n19273M1l3i3S2X/developer_id_insta...
“The two KeRanger infected Transmission installers were signed with a legitimate certificate issued by Apple. The developer ID in this certificate is “POLISAN BOYA SANAYI VE TICARET ANONIM SIRKETI (Z7276PX673)”, which was different from the developer ID used to sign previous versions of the Transmission installer. In the code signing information, we found that these installers were generated and signed on the morning of March 4.”
From: http://researchcenter.paloaltonetworks.com/2016/03/new-os-x-...
and that didn't ring any alarm bells?
“And according to the analysis, this is exactly what they did. They used a different cert to sign their malware. I have to admit that Windows' UAC is better in that regard, as it shows the signees name. But of course this is only useful if you know the "right" name.”
“Yeah, I think this is a major issue on OS X. For the average user it is impossible to tell who signed an app, if it is sandboxed, and what permissions it has. Hell, using the codesign command to extract entitlements from all binaries in a package is hard even for advanced users... (There is third party tool named RB App Checker which does make these tasks a bit easier, though)”
…in this comment thread: https://news.ycombinator.com/item?id=11234966
[0]: https://forum.transmissionbt.com/viewtopic.php?f=4&t=17835
Many people would uninstall and download it over again when running into that kind of error message.
https adds a performance hit. The security of "checksum over https and actual file over http", if the checksum is checked, is the same as "actual file over https", barring preimage attacks.
HTTPS will ensure integrity of your download automatically with no action required from the user.
Checksums require the user to perform the integrity check manually, and 99.9% of users wont bother.
Please don't put your users at risk just to save a negligibly small number of CPU cycles.
> just to save a negligibly small number of CPU cycles
The link above says they can't afford the additional cost. If it's so negligible, would you sponder the cost of those extra cycles? I'm sure they would host on SSL if someone covered the cost.
> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. [0]
[0]: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...
https://www.whonix.org/wiki/Download_Security
>Practically it is difficult to provide SSL protected downloads at all. Many important software projects can only be downloaded in the clear, such as Ubuntu, Debian, Tails, Qubes OS, etc. This is because someone has to pay the bill and SSL (encryption) makes it more expensive. At the moment we don't have any mirror supporting SSL. We're looking for SSL supported mirrors to share the load.
Is it not true that mirrors supporting SSL are more expensive?
"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that." - Adam Langley, Google
Getting an SSL certificate used to be a cost, but that's taken care of now by https://letsencrypt.org/.
There are multiple named projects there that aren't using SSL, and I don't think it's just laziness. If you know of a way for them to use SSL mirrors for no additional cost, I'll work on getting them to switch over.
I suspect that wiki page you linked might be out of date. It seems like all of the Whonix download links on their website are over https, like the VirtualBox images https://www.whonix.org/download/12.0.0.3.2/Whonix-Workstatio....
Whonix also runs a tor mirror, which has significantly more overhead than TLS.
For tails: https://tails.thecthulhu.com/. It appears to be the same server behind http://dl.amnesia.boum.org/ based on the TLS cert.
The situation is messy to actually use https for all of these projects, but I think the issue now is organization rather than overhead.
I seem to remember downloading whonix from their site over HTTP around a year ago.
Do you see a tails HTTPS mirror?
A checksum is NOT a substitute for a digital signature.
https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...
In the case where the attacked has direct control over the website then you're right, it doesn't help at all.
I was pretty sure that's the threat model we were discussing: Software authenticity.
The only way to automatically know if a piece of software is legitimate is to have a trusted public key that can verify a signature.
Also, HTTPS is implied these days. If you're not using HTTPS, you are either malicious, negligent, incompetent, or working for someone who is some or all of the above.
Or poor. Hosting large amounts of binaries over https isn't cheap. I just priced Amazon S3 and cloudfront and for the amount of data that I serve it would cost $300 per month. That's a lot to commit for a GPL-ed binary that brings in practically zero revenue. Maybe there's a cut rate VPS out there that can handle 150GB of data and 3TB of bandwidth per month on the cheap, but I haven't found it yet.
Maybe like pointed out in another reply, not for checksums but for signatures. So you just copy/paste the signature after selecting a file, and then it can verify it's validity.
Is there no such extension yet? it seems like there should be one already.
You could pay for it with some sort of sponsorship from apps themselves, who have an interest in not getting compromised like this (it's terrible publicity).
This wouldn't help anyway. If the malicious party had access to alter the downloads (as they did here) they could just as well change the checksum shown on the page to.
>On the other hand, the Windows and OS X App Stores are awful.
Haven't used the Windows one, but what's "awful" about the OS X one? Quick, one click, installations, isolated, signed, easy updates.
Might be bad for the application developers somehow, but I don't see anything much bad about it from a user perspective -- except maybe the lack of trials. Then again I've been able to get a refund any time I bought an app that was subpar and written to Apple (that was 2 times).
With digital signatures the problem is that I don't often know who is the official author of the app.
Linux distributions package what is released upstream. If upstream is compromised, so is the Linux package.
As such, checking the source is still very much relevant here since this wasn't a compromised app in the Mac App Store, it's an app distributed outside it.
Unless you are a small independent app developer. Virtually no distribution wants to take proprietary software. And you have to package for a wide variety of different distributions.
On the other hand, the Windows and OS X App Stores are awful.
The Mac App store works pretty much effortless for me. It's sometimes a bit slow, but other than that it's pretty trivial to use.
- There's no means of providing paid upgrades. E.g. for a major version bump, which a lot of developers rely on to keep their business afloat.
- The store interface and navigation are also much slower than the iOS counterpart.
- Recently some certificate issues rendered users unable to open their apps.
- Not 100% sure on this one: You can't download older app versions if your OS is no longer supported.
Apple and other do this by simply numbering the names of apps. They don't allow you to specify special "upgrade" pricing, but the effect of this was that developers no longer really have full retail pricing and everything is just set to the upgrade price.
Logic Pro 8 for instance used to retail at $499. The upgrade price was $199. Now Logic Pro X on the Mac App Store is just $199 regardless of whether you are first time user or someone who had the previous version.
- The store interface and navigation are also much slower than the iOS counterpart.
I haven't really found that the Mac Store is any slower. I've found that they are both slow.
- Not 100% sure on this one: You can't download older app versions if your OS is no longer supported.
I don't believe it will even show you newer versions of the apps as long as the developer properly specifies the minimum OS version.
I'm game, but I need a little help. What are your favorite techniques for verifying downloaded programs?
But there are a number of things that can be done:
- always verify the checksum (if available), in case the download mirror (but not the web site itself) got compromised.
- check for strange strings in the binary (use "strings" and "grep"). E.g. URLs
- scan the downloaded file on Jotti or VirusTotal.
- unpack the binary manually with 7-zip or similar if it's a self-extracting file.
- check installation scripts, build files, etc. (if applicable).
- if downloading source code, check a couple of files at random. Will most likely not protect you, but if everyone does it, it helps detecting embedded malware (or bugs) early.
- run "strace" (Linux/Unix) or "FileMon" (Windows) or similar software and log what the software does when you install and run it for the first time.
- and check Hacker New regularly ;)
Debian: have to also fool several people involved in the packaging of said package upstream and everyone using it and building from source
Alas, nobody wants to invest the day or so in actually writing the methods to do it.