[messaging] Tor Hidden Services in (Cables, SMTorP, Pond)

[David Leon Gil]

> Hidden Servers probably also have value in protecting servers from getting taken down, or their operators harassed.






Definitely yes on the latter. It depends on what you mean by 'taken down' for the former: If you mean 'a legal authority ordering a service to be taken down' then yes. If you mean 'less susceptible to DOS attacks', then definitely not. (This is one of the downsides of HS; it's -- relatively -- trivial to permanently DOS a hidden service.





> They also allow the server operator to claim that since the server can only be contacted


over Tor, it's impossible for server to know much about its clients - this might help avoid getting drawn into legal investigations.






​It (also?) minimizes the chances that an order granting access to ISP-kept IP-connection logs at the server's real endpoint would be proper.* (Alas, a lot of ISPs keep IP logs; see, e.g., [1].) This is a big privacy benefit for a Pond server (or other HS-only service) operator.










​[1] http://cryptome.org/2014/06/verizon-stratfor-hack.pdf



​*(Assuming that the third-party-doctrine in its strong form is wrong. In particular, there is a clear and cheap minimization strategy for discovery that doesn't disclose IP addresses.)
—
Sent using alpine: an Alternatively Licensed Program for Internet News and Email

On Sat, Jun 14, 2014 at 4:31 PM, Trevor Perrin <trevp at trevp.net> wrote:

> Some e2e messaging protocols make use of Tor Hidden Services.  It's
> interesting to think about what value this adds:
> In Cables [1] and the (work-in-progress) SMTorP [2], recipients can
> run their own Tor Hidden Service.  So if you're online, messages can
> be delivered directly to you without needing a mailbox server.
> The downside:
>  - Tor Hidden Services are easier to de-anonymize than Tor clients, as
> arbitrary traffic can be directed at them [3].
>  - Traffic correlation between sender and receiver is easier than it
> would be in a store-and-forward system.
>  - The recipient is advertising their online / offline status to
> anyone who knows their address.
>  - Correlating sender traffic with the online/offline status of
> potential recipients might be possible.  Consider an attacker who can
> monitor the sender's traffic profile.  If the sender's traffic profile
> suggests they are "polling" for a recipient until time T, then
> delivering a message, that suggests the sender might be communicating
> with a recipient whose hidden service came online shortly before time
> T.
> So a store-and-forward system with many users sharing the same mailbox
> server seems better.  This is how Pond works [4].  But Pond's mailbox
> servers are *also* Hidden Servers.  This may have some benefits, but
> it doesn't seem necessary:
> For user anonymity, users can contact their mailbox server and their
> recipients' mailbox servers over Tor; Hidden Services aren't needed.
> For unlinkability of users with each other, the correlation of packet
> timing and sizes between sender and recipient needs to be broken.  In
> Pond, clients retrieve padded data from their mailbox server at a
> roughly constant rate.  Hidden Services don't help with this.
> Hidden Servers might make it harder to do correlation of traffic
> between sending clients and recipient *servers*, by making the
> recipient server hard to locate.  But if users choose servers run by
> known parties, then this protection is lost.  A better solution would
> probably be high-latency-variance relays (remailers, mix network)
> between sending clients and recipient servers.
> Hidden Servers probably also have value in protecting servers from
> getting taken down, or their operators harassed.  They also allow the
> server operator to claim that since the server can only be contacted
> over Tor, it's impossible for server to know much about its clients -
> this might help avoid getting drawn into legal investigations.
> But it's interesting to note that Pond's dependence on Tor Hidden
> Services is slight.
> Trevor
> [1] http://dee.su/cables
> [2] https://github.com/pagekite/Mailpile/wiki/SMTorP
> [3] http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf
> [4] https://pond.imperialviolet.org/tech.html
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140616/838886a3/attachment.html>