If I've download a Tor binary from an unofficial source is there a way to verify that the binaries haven't been tampered with?
4 Answers
If you're using your distro's binaries to install Tor then you have to trust the package maintainer of your distro as you do with every other package of your operating system. If you don't trust maintainers and/or developers of your distro then I guess there is a bigger problem since that means you can't trust the operating system in which you run Tor.
Mind that Tor project suggests using its own repositories since most Linux distro's repositories have an outdated version of Tor.
If you're installing Tor from Tor project's repositories (e.g. https://www.torproject.org/docs/debian.html.en for Debian and Ubuntu machines) then you will also have to add and trust the GPG key which was used to sign the packages.
So the question is how can you trust that the GPG key mentioned in torproject.org is owned by Tor developers. One could say that as long as you trust the HTTPS connection and certificate of torproject.org you can trust that you're getting the correct GPG key.
Another way GPG key trust is established is through the Web Of Trust. That means you have to check the key's signatures recursively and find a signature of a person you know.
When you're sure it is the correct GPG signing key, then trust is passed to Tor developers, who we do trust (or not) from the beginning.
-
1As accurate as this answer is for its situation, it doesn't really answer the question which specifically specifies that they're using OS repositories, as opposed to Tor Project repositories. Commented Sep 26, 2013 at 17:10
As you asked for every possible way of tampering, the list is going to be kinda long, but let's start anyway.
The package maintainer adds strange patches...
...or uses a weird build system.
I would say this kind of tampering happens all the time a package is being built (or prepared in case of a source distribution!) for you by a third party. However this is usually not harmful tampering.
On Debian (sorry, I am kind of biased here), you can observe what happens to a certain package in various ways:
- the patches are listed on the patch-tracker, if they can be easily extracted
- the build-logs are archived for later inspection
- there is a general overview of the happenings in the package at the package tracking system
- you can view the source used for the build via git or by calling
apt-get source toron your machine (comparing it to the pristine upstream source is up to you then)
These measures however do not prevent an evil build-machine from injecting malicious code into the binary without logging it. Or the maintainer injecting something bad into the binary he uploads together with a pristine source (maintainer uploaded binaries are not rebuilt in Debian [at least at the moment]).
The evil hacker changing the binary on it's way from the repository to your machine
This is something that should not happen in today's distributions, as the whole chain from the maintainers machine to yours is guarded by signatures (and the maintainer of course checked the signature of the tarball he/she got on the internet ;)).
[ example is again heavily Debian biased, sorry ]
- Maintainer uploads of sources and binaries are signed using PGP.
- Uploads from the build machines are singed using PGP.
- The repository and it's contents are signed using PGP.
[ on a side note: break PGP and the whole world is fucked :) ]
The evil twin/government who pokes around your disk
This is probably the most effective and targeted way in my list.
Start with encrypting your disk (the whole disk, yes, that includes /boot or they will poke your kernel/initrd). An encrypted disk does not only save your kinky pictures, it also prevents strangers from writing to it. Using a read-only medium for the super-secure stuff is an alternative (did I mention Tails already?).
After you think your system is secure, check it on a regular basis. debsums and aide could help you here. So would a backup suite like bacula which can verify disk contents (that should never change).
-
This doesn't have much to do with the question; I've tried to modify it to make it clearer and less distro focused. It doesn't matter where the binary gets modified, just the fact that it is. It's also not about trying to prevent a binary from being modified. Hope that helps, and thanks for the answer anyways!– user5Commented Oct 2, 2013 at 22:43
-
That sounded different in this comment: tor.stackexchange.com/questions/111/… Sorry. But then the answer is easy: you cannot :)– zhenechCommented Oct 2, 2013 at 22:50
-
That very well may be until the deterministic build process graduates from alpha. That comment was made by someone not-me. It does apply though; it can be from repos (my initial intent) or downloaded from somewhere online; it's the same thing. Just a binary from a non-official source.– user5Commented Oct 2, 2013 at 22:52
-
Recently, Tor's build process was rewritten to be deterministic (currently only available in alpha builds). This means that builds produce byte-for-byte identical binaries for each OS/architecture combination that the build targets regardless of what OS/architecture you're currently running on.
Because of this you will (eventually) be able to take a hash of the official binaries and make sure that it matches those provided by your distro (eg. sha1sum tor).
For more information on deterministic builds, see this blog post.
-
As I understand it the build would be identical byte-for-byte with any build targeting the same architecture/OS. Naturally a binary built targeting x86-64 on Windows would be different from one targeting x86 (32 bit) on Linux. It's simply that you should be able to produce that build on any os or architecture Commented Sep 26, 2013 at 17:14
-
Heh, correct; I worded that poorly. Obviously an EXE for Windows is going to be different from the binary for Linux. No idea if you can cross compile. Reworded.– user5Commented Sep 26, 2013 at 17:18
-
It looks like you can cross compile. gitweb.torproject.org/builders/tor-browser-bundle.git/… - A readme for the 3.0.0 alpha build which introduces this system says that it will "then start the build process to produce localized Linux bundles, followed by Windows bundles, followed by Mac bundles." Commented Sep 26, 2013 at 17:23
-
This doesn't actually work yet on distributions. No distro creates a deterministic build, and sha1sums are not posted for the tor client itself (only TBB). Commented Sep 26, 2013 at 20:24
-
Oops, thought I said that this was an upcoming feature. Will correct; thanks. You can still just download a binary from the Tor site and compare checksums.– user5Commented Sep 26, 2013 at 20:40
This issue is not specific to Tor packages. RPM can verify integrity of installed files. For systems that use APT, the debsums utility works similarly.
-
The question is about checking if the binaries match the original Tor source or have other things added. This answer doesn't really answer the question.– user5Commented Sep 30, 2013 at 6:07
-
1Your question said nothing of source code. You asked how to determine if binaries have been tampered with.– pmocekCommented Oct 6, 2013 at 3:07
git diffthesource/folder of the package.