Mike Perry mikeperry@torproject.org 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>
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.