A concern with this proposal that I have not seen mentioned is that exit pinning would cause the Tor path itself to leak more information about the intended destination. For example, a destination could (possibly without malicious intent) pin a single exit that is otherwise unlikely to be used. Simply choosing that exit would thus make it appear much more likely to be visiting that destination from the view of an adversary that can identify the exit (e.g. by being chosen as the middle relay or by performing a congestion attack that identifies relays on a circuit). This gets worse when connections can be linked together as originating at the same client because without pinning it is unlikely to repeatedly choose the same exit (or from any small set of exits). Connections can be linked as originating at the same client by the guard (or anybody observing a guard) or by middle relays that observe the same guard being used in a short period of time, indicating activity by the same client.
Best, Aaron
On Oct 11, 2016, at 7:58 PM, Henry de Valence hdevalence@riseup.net wrote:
Hi, On Wed, Oct 05, 2016 at 04:09:15PM -0400, Philipp Winter wrote:
- 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.
- 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