protect users against freeze, replay and version-rollback attacks
Currently, we tell users that the GPG signatures linked to from the download page 'allow you to verify the file you've downloaded is exactly the one that we intended you to get. For example, tor-browser-1.3.15_en-US.exe is accompanied by tor-browser-1.3.15_en-US.exe.asc.' This is false.
The GPG signatures only prove that a particular person associated with The Tor Project has signed a particular file; they do not authenticate the filename, thus they do not authenticate the package name or the package version, and they do not prove that a particular package file is the final build of a package version which we want to distribute to users. This leaves our users vulnerable to version-rollback attacks and package-substitution attacks if they download packages from mirrors or over non-HTTPS connections.
We should:
- switch to signing the output of
sha256sumon a package file, which includes the filename and a hash of the file, rather than signing the package file directly, and - explain on the verifying-signatures page how to verify downloaded packages using the signed SHA256SUM files, including explaining that unless there is a blank line after the '
Hash:' line and before the hash-and-filename lines, the SHA256SUM file has been tampered with.