Hi,
I just set up an experimental Tor mirror here:
(Please don't include it in any mirror lists yet.)
I'm a little worried about security, though. The 'Configuring a Mirror' page [1] has me cloning the Tor website via rsync, which isn't a secure protocol. There are two specific risks here:
1. To the user of the mirror: A network attacker between my server and Tor could have replaced the Tor binaries with a malicious copy.
2. To the host of the mirror: A network attacker, or an evil sysadmin at Tor, could insert PHP scripts (or other things that Apache will execute) into my system, then execute by making a web request.
I worked around (2) by adding "php_flag engine off" to the Directory entry in my Apache configuration, but I'm not certain that's good enough. Can the .htaccess in the Tor mirror override it? Are there other things that Apache will execute that I'm not aware of?
To solve (1), how about letting users submit an SSH public key so they can rsync over SSH, or just have an account with a stupid password like "tormirror", then publish the SSH fingerprint on torproject.org?
A Git repository with signed tags could be another solution.
[1] https://www.torproject.org/docs/running-a-mirror.html.en
Thanks,
On 03/27/2014 07:42 PM, Taylor Hornby wrote:
- To the host of the mirror: A network attacker, or an evil sysadmin at Tor, could insert PHP scripts (or other things that Apache will execute) into my system, then execute by making a web request.
I worked around (2) by adding "php_flag engine off" to the Directory entry in my Apache configuration, but I'm not certain that's good enough. Can the .htaccess in the Tor mirror override it? Are there other things that Apache will execute that I'm not aware of?
I have another solution. As far as I know, Apache bases its decision on the file extension, never the file contents, so it should be possible to whitelist safe extensions with rsync.
This can be done with a command like this:
rsync -av --filter="merge ./tor-rsync-rules" --delete \ rsync://rsync.torproject.org/website-mirror tor-mirror-testing/
Where the ./tor-rsync-rules file contains something like this:
+ *.asc + *.cgi + *.common + *.css + *.csv + *.dmg + *.en + *.exe + *.gif + *.gitignore + *.gz + *.htaccess + *.html + *.ico + *.jpg + *.js + *.local + *.odp + *.org + *.pdf + *.pl + *.png + *.rdf + *.sample + *.serial + *.sh + *.svg + *.txt + *.wmi + *.wml + *.xhtml + *.xml + *.xpi + *.xz + *.zip
# Allow all directories (some of them have . in the name) + */
# Disallow everything else that has an extension. - *.*
The whitelist of safe file extensions can be generated like this:
find tor-mirror/ -type f -iname "*.*" | \ sed 's|.*.||' | sort -u | sed 's|^|+ *.|'
Be sure to verify the list manually in case you already have a malicious copy.
I tested this, and it gives me a directory that's exactly the same size as the one I get when I rsync the normal way. I also commented out the "*.zip" whitelist, deleted a zip file, and it (correctly) did not the zip file I deleted.
So it works.
But there are some problems:
1. I'm not sure if the rsync rules are being applied on the client or the server. If they're being applied on the server, the server can just ignore them, and send .php files anyway.
2. If the Tor people want to add files with a different extension, everyone running a mirror will have to update their whitelist. Is this likely to happen?
I'd appreciate it if someone could check my work. In particular, I'm not sure how the filter interacts with deletions. I wonder if it will stop things from being deleted, too.
Hi Taylor,
On 03/28/2014 02:42 AM, Taylor Hornby wrote:
- To the host of the mirror: A network attacker, or an evil sysadmin at Tor, could insert PHP scripts (or other things that Apache will execute) into my system, then execute by making a web request.
I worked around (2) by adding "php_flag engine off" to the Directory entry in my Apache configuration, but I'm not certain that's good enough. Can the .htaccess in the Tor mirror override it? Are there other things that Apache will execute that I'm not aware of?
I would recommend to serve static mirrors like one of tpo.org using a webserver that does not execute anything server side in the first place. Additionally, you might want to mount the directory noexec. You could still use your main webserver to serve the content with reverse proxying.
To solve (1), how about letting users submit an SSH public key so they can rsync over SSH, or just have an account with a stupid password like "tormirror", then publish the SSH fingerprint on torproject.org?
I agree that rsync over ssh with a shared, read-only account would be nice.
tor-mirrors@lists.torproject.org