Hi, On Wed, Oct 05, 2016 at 04:09:15PM -0400, Philipp Winter wrote: > 0. Overview > > To mitigate the harm caused by malicious exit relays, this proposal > presents a novel scheme -- exit relay pinning -- to allow web sites > to express that Tor connections should preferably originate from a > set of predefined exit relays. This proposal is currently in draft > state. Any feedback is appreciated. > > 1. Motivation > > Malicious exit relays are increasingly becoming a problem. We have > been witnessing numerous opportunistic attacks, but also highly > sophisticated, targeted attacks that are financially motivated. So > far, we have been looking for malicious exit relays using active > probing and a number of heuristics, but since it is inexpensive to > keep setting up new exit relays, we are facing an uphill battle. > > Similar to the now-obsolete concept of exit enclaves, this proposal > enables web services to express that Tor clients should prefer a > predefined set of exit relays when connecting to the service. We > encourage sensitive sites to set up their own exit relays and have > Tor clients prefer these relays, thus greatly mitigating the risk of > man-in-the-middle attacks.
I think that it would be good if the overview and motivation sections of the proposal discussed what concrete attack(s) the proposal aims to prevent, and why "exit relay pinning" is a better solution to address these attacks than any alternative method. Indeed, the only concrete attack mentioned is a man-in-the-middle attack. Some questions: - Are the "opportunistic" or "sophisticated, targeted" attacks all man-in-the-middle attacks, or are there other attacks? - How do the "opportunistic" attacks differ from the "sophisticated" ones? Are they actually different attacks, or just different strategies that malicious exits use to tamper with traffic? - If the attacks this proposal seeks to address really are all various flavours of man-in-the-middle attacks, why is end-to-end encryption (either using HTTPS, with or without pinning, or .onion addresses, or both) not sufficient to solve the problem? Moreover, I don't understand how it actually solves the problem of malicious exit relays tampering with traffic. Either the entity running the web service runs their own exit relays that they trust, or the entity running the web service pins to exits they don't control. In the first case, why wouldn't they just configure an (single) onion site, and get actual end-to-end authenticated encryption? In the second case, the web service operator has to somehow trust the exit operator (on what basis?) and in return for handing the "trusted" exit(s) the opportunity to MitM all their traffic, gets ... no extra assurance about data integrity. As has been noted by others in the thread, "exit relay pinning" amounts to allowing arbitrary (hostile) servers to store (arbitrary) information in the client's Tor instance, and alter the client's path selection algorithms. This seems like a lot of new attack surface to add, and I don't understand from the motivation section a) exactly what attacks exit pinning is meant to address; or b) why those attacks can't be addressed by HTTPS or onion services. Cheers, Henry de Valence _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev