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

[Trevor Perrin]

Hi Bjarni, all,

Good points, the discussion touches a lot of things:

 1)  Receiving messages via self-hosted Hidden Services

 2)  Servers running as Hidden Services

 3)  Low-latency (Tor) vs high-latency anonymizing systems

I'll only get to (1) here, maybe the others later...

Bjarni argues there's value in avoiding the existing email
infrastructure, to "cut out all the middle-men who might listen in,
mis-classify as spam, arbitrarily delay or otherwise interfere with
your mail".

I'd argue the "listen in" part is solved by encryption.  For the rest:
if this is a problem with your provider you could get a new provider.
Having your average user run an SMTP Hidden Server at home doesn't
seem like it would improve reliability vs commercial services,
considering spam, hacking, ddos, machine and network uptime, the Tor
dependency, etc.

But it's possible existing mail providers won't be amenable to
widespread encryption that removes their ability to see spam / viruses
/ ad keywords, or widespread identity/relationship-hiding.  So perhaps
the premise behind (SMTorP, Cables, Pond, etc) is correct, and we need
new protocols and infrastructure.

In that case, I'd still argue the "sender -> recipient mailbox" model
is better than the P2P "direct contact" model.  In addition to the
useability / reliability / security issues with self-hosted services -
which are substantial - I think the intuition that "direct contact"
improves privacy is untrue in important ways.  Consider the different
sorts of information to hide:

Contents - encryption
Identity - anonymity, pseudonymity
Relationships - who are you in contact with
Presence - when are you online
Volume - how many messages you receive, and when

Let's look at how these are differently exposed in the "mailbox" vs
"direct contact" models:

Contents - end-to-end encrypted, no difference.

Identity - A mailbox server can be accessed over Tor, with traffic
padding (like Pond) to break correlation with sent messages.  In
contrast, a self-hosted hidden service makes it easy for anyone
monitoring your link to de-anonymize you by sending a distinctive
traffic pattern.  Also, uptime-monitoring leaks some information.
Bjarni suggests that if you "are more or less always online, then the
fact that your Tor hidden service is reachable leaks no information".
But "more or less always" is not "always" - there will be power and
network outages, and machine upgrades and moves, which over the long
term could be quite revealing.

Relationships - Against traffic analysis the mailbox model is better,
since an observer can't look for traffic correlation directly between
sender and recipient, or correlate the sender's polling loop with
recipient downtimes.  While these risks could be eliminated
(high-latency remailers, always-on recipient servers), the only
advantage for the direct-contact model is if identities are not
end-to-end encrypted, which they should be.

Presence - Direct contact requires you to advertise server uptime to
the world.  If the server's your laptop, this leaks a lot about your
activities.  Though I admit: if your self-hosted server is always-on,
direct-contact has the advantage that it doesn't reveal to a mailbox
when you download messages.

Volume - A mailbox learns the volume of messages you're receiving, but
if accessed cleverly (like in Pond) can hide this information from
someone observing your network link.  A direct-contact server reveals
this to a network observer.

So I think that for hiding identity and relationships, the "layer of
indirection" provided by a mailbox server is better.  For hiding
presence, direct-contact is better only if you run an always-on server
(unrealistic for most users).  For hiding volume, it depends on the
threat (would you rather reveal this to a server you can choose, or
the network you happen to be on).

Anyways, I guess I'm still not sure there's enough privacy or other
benefit to self-hosted, direct-contact servers to justify the
deployment challenges.

Trevor


On Sun, Jun 15, 2014 at 1:07 PM, Bjarni Runar Einarsson
<bre at pagekite.net> wrote:
> Hey Trevor, everyone,
>
> Thanks for taking a look at SMTorP!
>
> The points you raised in your previous mail are quite valid - real-time
> p2p communication has very different properties from store-and-forward
> based systems and is vulnerable to different classes of attacks and
> different types of abuse.
>
> For some users, real-time direct delivery of messages may leak too much
> information. It may also be too unreliable, if schedules don't match and
> people aren't online at the same time often enough for the message
> exchange to actually take place.
>
> However, for many the opposite is true. If you are not concerned with
> anonymity and are more or less always online, then the fact that your
> Tor hidden service is reachable leaks no information and you reap quite
> measurable benefits from being able to cut out all the middle-men who
> might listen in, mis-classify as spam, arbitrarily delay or otherwise
> interfere with your mail. Today sending e-mail is a like a lottery with
> very good odds - usually you win, and usually the message delivered. But
> not always, and when you lose there is no feedback at all. Mail just
> disappears, thanks to spam filters everywhere. If we can address that
> problem and improve security at the same time, then we've improved
> e-mail quite significantly.
>
> I think the fact that we are using Tor and Tor hidden services for this
> sometimes confuses people, as it leads to the assumption that anonymity
> must be one of our primary goals. But that is not actually the case.
> SMTorP is primarily focused on decentralization and establishing secure
> and private channels over which users exchange normal, non-anonymous,
> e-mail. Just like with regular e-mail, if used carefully, anonymity may
> be achieved, but that isn't our main goal here.
>
> I am quite excited about SMTorP, because although it is not perfect, it
> is very easy to implement and deploy and it can be configured for both
> scenarios - p2p or store-and-forward. So if you need anonymity or high
> availability, you use a shared relay or even a sequence of relays. If
> you want to be sure that you are communicating directly without any
> middle-man, you run the hidden service yourself.
>
> My greatest concern about the p2p mode of SMTorP is actually the classic
> sysadmin concern that an exposed service is more vulnerable to direct
> attacks - if you run a Tor hidden service then people can connect to
> that and try to break it. Who needs timing attacks, if they can just
> 'sploit your Mailpile's built-in SMTP server and read all your mail?
> But hey, fixing that is a mere matter of programming, right? ;-)
>
> Cheers!
>  - Bjarni
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>