[tor-talk] High-latency hidden services (was: Re: Secure Hidden Service (was: Re: ... Illegal Activity As A Metric ...))

[Seth David Schoen]

Andreas Krey writes:

> On Thu, 26 Jun 2014 00:50:29 +0000, Tor Talker wrote:
> ...
> > > enough to do it securely enough. Also, hidden services are far more
> > > vulnerable than Tor users, simply because they serve stuff.
> ...
> > What sort of vulnerabilities would you expect to see?
> 
> Problem: Your hidden server can be made to talk by accessing it
> (which is not the case for tor clients). Thus correlation attacks
> are possible if you have access to the bandwith data of a server
> you suspect to be a hidden service. Also the downtime of a hidden
> service could be correlated with obtained downtimes of IP addresses
> of machines at usual hosting providers (or elsewhere; apparently
> pinging the entire v4 internet is quite feasible nowadays).

I wonder if there's a way to retrofit high-latency hidden services
onto Tor -- much as Pond does, but for applications other than Pond's
messaging application.

For example, maybe there's a way for a hidden service to define an
asynchronous API through which client software can use the service,
and then have some kind of pool of API requests and API replies which
the server can update via asynchronous polling (much as Pond does with
pools of user-to-user messages).

This could conceivably have much better traffic analysis resistance,
maybe even against a global adversary.

Then a question is whether users would want to use a service that takes,
say, several hours to act on or answer their queries (and whether the
amount of padding data required to thwart end-to-end traffic analysis
is acceptable).

One important problem is what counts as "thwarting end-to-end traffic
analysis".  Right now with Pond, the goal is to prevent anyone from
knowing which Pond users communicate with which other Pond users and
when, not necessarily prevent them from knowing who is a Pond user.
(It seems like the Tor traffic generated by a Pond user's client would
be recognizable as coming from Pond.)  On the other hand, the services
that I'm thinking of should prevent a passive adversary from knowing
who is using _which services_, including locating the infrastructure of
those services.  In my analogy, the system should conceal the fact that a
particular person is running Pond on their home network, and also conceal
which servers are providing infrastructure for Pond communications.

Satisfying this property might have implausibly high padding
requirements.

-- 
Seth Schoen  <schoen at eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107