[tor-onions] Privacy Audits for Onion Services

Alec Muffett alec.muffett at gmail.com
Thu Aug 30 16:19:11 UTC 2018


Not to put too fine a point on it: I would start by running an onion server
on a dedicated machine in a network enclave behind NAT and with
intentionally invalid hostnames, so that any/all metadata that might leak
in (say) Apache headers, is mostly useless; the NAT-internal network would
be 10.0.0.0/24, the hostname "invalid.invalid", etc...

It was thinking like this which led me to draft this (now slightly dated)
document; but overall it still is useful:

https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md


The other benefit of putting your onion servers in a NAT enclave is that
you can lock down your guards to a limited set and drill holes in your
firewall specifically for those, and then ban all other outgoing traffic
from your machine; this will help prevent identification via DNS lookups,
package update checks, pingbacks in your CMS stack, etc.

Then: work out for yourself how to do software updates via (say) a HTTP
proxy + VPN.

    -a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20180830/7c5234a7/attachment.html>


More information about the tor-onions mailing list