> 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 <[email protected]> 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
> [email protected]
> https://moderncrypto.org/mailman/listinfo/messaging
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging
