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

[coderman]

On Sun, Jun 29, 2014 at 5:58 PM, Seth David Schoen <schoen at eff.org> wrote:
> ...
> 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.

i know that one mechanism i have used to some limited success is
fronting a nginx proxy in front of multiple back-end hidden services
as actual sources.

this leaves an ephemeral instance (similar to ram only relays) with a
different traffic profile more like your average relay. (it has more
symmetric bandwidth no matter how lopsided the end point recv vs. xmit
is tilted which betrays most direct hidden service serving, or client
only links)

that is to say:
  front-onion -> nginx -> 3x-?x many onion HTTP keep-alive with
heart-beat if no request in last 30sec

it is slower, and less efficient, but also seems to be more robust.
  (putting multiple onions on the front end to avoid hotspots and
transient unavailability another question more apropos availability
than unlinkability...)

i'd love to see someone do some research on this subject they could
make public, hint hint! ;)



> 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 would be quite interesting as a method to pursue further, but
also as you mention, still a far cry from strong traffic analysis
resistance. (distinct from social graph discovery resistance)


best regards,