Re: [tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

[George Kadianakis <desnacked@xxxxxxxxxx>]

Mike Perry <mikeperry@xxxxxxxxxxxxxx> writes:

> George Kadianakis:
>> Hello there,
>> 
>> we recently finished implementing proposal 250 which is one of the first steps
>> for the upcoming hidden service redesign [1]. The next steps are implementing
>> proposal 224 and the other performance and security proposals [2].
>> 
>> <snip>
>> 
>> 1) Security issues
>> 
>>    - Professor Hopper pointed out [3] that this proposal will double the number
>>      of introduction points of a hidden service (from the current 3 to 6).
>>      Introduction points have slightly more attack vectors than HSDirs, so we
>>      should not increase their number without analyzing further.
>
> An additional related security issue is the traffic analysis benefits of
> separating out hsdir, IP, and RP. Recall that the original onion routing
> design did this on purpose (despite considerable performance drawback),
> so that actual circuit-level traffic patterns from the hidden service
> would be fully decoupled from their identity information.
>
> If we were to merge hsdirs with intro points that have long-lived
> circuits opened to them, we create additional point where an adversary
> who sees/learns/knows the hs address can attempt to passively or
> actively correlate traffic patterns with a malicious hidden service
> guard. There will be much more traffic available at the intropoint for
> such passive or active traffic analysis than there will be during a
> simple hsdir fetch or post, which means that long-term traffic analysis
> and related intersection/statistical disclosure attacks have much more
> opportunity to succeed. Long-term traffic analysis is also much harder
> to combat with padding.
>

It's interesting that you say this, because reducing traffic fingerprinting
vectors was one of the claimed advantages of proposal 246. From the proposal:

   Hidden services are able to stay online by simply maintaining their
   introduction circuits; there is no longer a need to periodically update
   descriptors. This reduces network load and traffic fingerprinting
   opportunities for a hidden service.

To better understand the various attacks, here are some adversaries that we
could consider:

- Sybil adversary (HSDir + Guard):

  Seems to me that proposal 246 does slightly better than the status quo
  against a Sybil attacker who runs HSDirs and guards and tries to deanonymize
  hidden services or clients that first connect to the HSDir and then to the
  hidden service.

  I say this because proposal 246 only needs 6 HSDirs/IPs, whereas we currently
  need 6 HSDirs plus 3 IPs. So a Sybil attack is going to succeed sooner as it
  is now.

  I'm not sure why you are saying that we create additional monitoring points
  here. It seems prop246 is reducing them from 9 to 6. But maybe we are
  thinking of different attacks.

  FWIW, in prop246 after a client connects to the HSDir/IP, it first fetches
  the encrypted descriptor of the HS (BEGIN_DIR), it then sends an INTRODUCE1
  cell, and then receives an INTRODUCE_ACK. This is one more step than the
  current protocol, which I guess is good for blending in because the
  INTRODUCE1 and INTRODUCE_ACK dance is quite distinguishable. However, tbh I
  doubt that the BEGIN_DIR step will make a big difference against a
  distinguishing attacker.

- Network adversary (HS data center)

  Against a network attacker who monitors the data center of the hidden
  service, I think prop246 copes about the same as the current situation,
  considering the attack vectors from the USENIX paper (noticing the flow of
  INTRODUCE1 and INTRODUCE_ACK cells).

Were you talking about a different adversary?

> Granted, even with prop 224, an adversary that knows a non-authenticated
> hidden service address can decrypt the descriptor to learn the
> introduction points, but to actually be in the position to perform
> circuit-level traffic analysis on them requires another c/n multiplier,
> making the full attack succeed with probability O((c/n)^3) (ie, the
> adversary has to get in the guard, hsdir, and intropoint positions to be
> fully successful).
>
> I think this is reason enough to reject Proposal 246 for high security
> onion services by itself, but the complications with onionbalance also
> concern me, as well.

Yes, I think I agree with this evaluation for now. Seems prop246 is more
complicated than we can handle, and we should probably postpone it, except if
someone can analyze it well soon.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev