[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Proposal 273: Exit relay pinning for web services
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@xxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev