Silk Road forums
Discussion => Security => Topic started by: Eternal Sunshine on September 09, 2013, 09:15 am
-
Ok, a bit offtopic (and I suppose this topic will be moved) but i wanted max visibility.
With tormail down (freedomhost taken down) i've taken on a project create a mail service for tor.
Please check it for vulnerabilities. It is hosted on.
http://7pj2o4o4adfyu2mr.onion
If nobody is able to find out the real IP of the squirrelmail interface I will go through the next fase and put it on it's separate server (since i'm a webdeveloper it's now sitting on a vps between clearnet projects) and allow user registrations.
Also, any feedback is welcome. If anyone suggest a better webbased email client (WITHOUT JAVASCRIPT) i'm willing to try it.
Regards
Eternal Susnhine
-
My assumption here is that it ultimately would gate email from the Internet to a hidden service location, like tormail. If you're just building a mail server with a webmail interface to let "local" users email each other, with no inbound/outbound Internet email, disregard much of my message below (except for the hidden node isolation part)
Anything approaching tormail in scope that provides anonymity for the server storing the messages requires 2+ nodes, with one acting as an Internet-accessible MX host (the public node), which then immediately shoves all received messages up to a hidden service address, delivering the message to the host responsible for acting as a hidden service (the hidden node). Then users connect to the hidden node to retrieve/send messages via webmail/pop/whatever, and all stored messages reside at the hidden node, only accessible via a hidden service. Outbound mail from the hidden node reaches the public node via a different hidden service, then the public node routes messages to Internet destinations.
The hardest part about providing tormail-like services is the epic deanonymization exposure you get from the public node requiring public Internet connection at a known location. You have a registered domain name, and a whole chain leading back to you that way if you're not extremely careful. How you paid for the domain, the contact info the registrar has for you (paying them for "private" registration usually doesn't provide much anonymity. Social engineering, a subpoena, or a warrant will disclose all info they have on you, including the source IPs you registered it from). If you use an allegedly-privacy-protecting third-party to register a domain as a proxy, it's *their* domain from the registrar's perspective. If they decide to steal it, you may not be able to stop them. The DNS servers for the domain can also lead back to you (again, payment tracing, and source IPs used to manage DNS records). Obviously, the hosting of the public node itself can lead back to you (through payment as well as your remote connections to it.. if it's a VPS or dedicated node, logs of your connects to the console interface as well may show your source IPs). If the public node gets hacked or seized, any log entries showing your SSH connects/etc lead back to you.
The hidden node has to stay anonymous, even if (when) it gets hacked. So it needs to have physical/virtual isolation from the Tor instance in front of it. Assume the adversary has root, can empty its iptables filters, and can send packets of their choosing out the network interface destined for their servers to deanonymize it. Only private IPs on it, be careful what other MAC addresses show up in its arp tables, be aware of hardware deanonymization (run "lspci" and "dmidecode" as root for a good idea of what I'm talking about).
And when you configure your MTAs, make sure you're scrubbing all of the mail headers properly. And test things like mailer-daemon messages, bounces, etc for deanonymizing content, behavior, and headers as well.
If it achieves anything close to tormail-like popularity, you should pretty much assume that the traffic destined for the public node's IP is going to end up in every intelligence agency's queue of sniffed traffic, to grab the SMTP message contents. Which means that your remote management traffic to it may also end up in that net, so manage it through the hidden service you're accepting mail from the hidden node on, or via an out-of-band method that isn't going to end up in the same bucket.
If that's what you're considering, it's great that you're considering providing a service like tormail..but just make sure you've thought out what you're signing up for. Your primary risk is someone finding *you* through the public node, then coercing you into providing access to the hidden node.