You have a launcher for some software, it allows you to execute the software but it will also allow you to switch versions and upgrade to newer versions.

When the launcher is executed, it downloads a manifest file from a specific URL (built into the launcher) to fetch the current list of versions. If there is a newer version, the user is notified and can update. If they decide to update to the new version it will pull another manifest from the same host as before, this is the manifest for the specific version.

This file contains a list of file names contained within this version and their respective SHA1 hashes. The patcher will then connect to the same host again to download files whose hashes do not match the local copies.

All manifest files and file objects for each version are stored within a single S3 bucket in this example. All requests are made over HTTPS to gzipped files.


I feel like this would be open to attacks due to semi-automatic downloading of executables. I don't know where an attacker could get in though. Should all files on the remote server be signed? Or will verifying the file contents with the SHA1 hashes provided by the server be enough?

Is there anything I can do to keep this safe, or should this kind of technique be avoided completely?

  • 1
    You should check what the TOR project is doing for their updater Oct 25, 2013 at 10:55

4 Answers 4


You have to consider what an attacker might do. He can grab your update file, inject it with malware, compute a SHA hash, deliver it to one of your clients, and infect them. Their computer would not reject it if it's only looking at hashes.

If your app only accepts signed files, he cannot infect them.

But checking individual files may or may not be enough, depending on your code. If you only test your code as a whole version, the attacker could possibly find an interaction bug by mixing an older version of one of your modules with your newer code. You should consider signing a collection of modules at the same grouping you are willing to test and deploy at. That way, you deploy only the tested change as a whole, never piecemeal.

This kind of attack was perpetrated against Microsoft Update. Someone could download the list of modules but then interfere with the downloading of the actual modules.

Not only could this approach reduce your attack footprint, it could serve to improve your end user experience by ensuring they are installing complete packages that are exactly what you tested. It might even help keep them out of "DLL hell."


I would probably sign the files with a key not accessible to the internet or the update server and only install files that are signed by that key. This prevents a compromise of your server from being able to compromise your clients.

SSL should help make sure that your clients don't connect to an attackers server, but it won't protect your clients if your server itself is compromised. The only way to protect there is to make sure the server can't post a file that the updater will accept.


This approach sounds fine to me.

Because the communication is secured with SSL, it's not readily possible for an attacker to insert a malicious file. Sure, SSL has some issues, but if an attacker can break SSL they can do all sorts of bad things.

You are of course trusting the software supplier. They could slip malicious code into an update. But then, you have to trust them anyway - they could have slipped malicious code into the initial version you are already running. Also, if they don't keep their systems secure, a third party could break in and distribute malicious updates.


Updates should definitely be signed. Just ship the public key with the app, and sign updates with the corresponding private key. If the signature doesn't match, then the update isn't from you and doesn't get installed.

You can have GPG do the heavy lifting. This technique is extremely common.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .