On 13/01/16 20:42, s7r wrote: > After prop 250, a malicious HSDir can not do so much, but a merged > HSDir + IP can for example kill the circuit and force the hidden > service to rebuild it. Under the current design, we retry for some > times and give up if an introduction point is unreliable, but with 246 > we have to retry much more. If the same attacker also holds a > reasonable % of middle bandwidth fraction in the Tor network, it will > at least perform a successful guard discovery over the hidden service > which is terrible. This may be fixed by not retrying a HSDir+IP too > many times as described in section 4.3 of the proposal, but it will > automatically lead to a capacity decrease (we have 5 HSDir + IP left > out of 6). The countermeasures in section 4.3 could be problematic for mobile hidden services, which have unreliable internet connections and therefore lose their intro circuits frequently. A service that lost its internet connection more than INTRO_RETRIES times in a consensus period would be left with no introduction points. The discussions on guard selection have suggested that clients can't easily distinguish between relay failures and internet connection failures. On Android the OS broadcasts connectivity events that could be used to reset the retry counter via the control port, but I don't know about other platforms. Cheers, Michael
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev