Won't comment on the entire content because I have one big comment which refers to the entire proposal or better say the concept of the proposal. I would reject this proposal's concept, because we have o excuse to over-engineer and complicate things in this manner. This is just too complicated for absolutely no gains, even worse opens the door for new stuff we don't need. Here are just a few reasons: 1. Websites need to build and maintain an up to date pinning policy. 2. Relays need to maintain a confirmation pinning policy, which complicates things from relay operator side and not to say Tor client side which needs to fetch both, compare, etc. 3. The descriptor of exit relays grows with pinning policy, putting extra load on the entire ecosystem including the clients. 4. Fetching the policy multiple times using different exit nodes will a) put extra load on the network and most important b) take a lot of time (in terms of user interaction) to load such a website -- we are trying to make an anonymous LOW LATENCY network, which is why we cannot afford this. If we wanted a HIGH LATENCY anonymity network there's so much better stuff we can do to mitigate attacks, but the price is not worth it -- Tor's main use case relates to the fact that it's a LOW LATENCY network, it's a fundamental design. If my website would take 60 seconds to load for Tor users for me it would mean that I hate those users, metaphorically speaking. 5. Opens new [unknown] attacks on anonymity, like setting up malicious pinned exit relays that only accept incoming connections from custom evil middle relays, increasing chances for guard discovery or total deanonymization. Combine this with the content data generated by the user on the website and you have a pretty narrowed list. 6. Opens attacks of DoS on the website, making it inaccessible through Tor by attacking the pinned exits (while we have CDNs and flood protection for clearnet websites, there is no such things for exit nodes -- you just need a big expensive server that has a bigger pipe than the attacker can fill). This will make it very expensive to run a website with pinned Tor exits reasonable immune to DoS attacks. We already have another solution to achieve this with no extra complications and using well tested stuff that does not overload the network, does not overload the clients, do not require significant changes to Tor Browser (besides coding Tor Browser to handle the string serving the onion url, does not even require a proposal -- just a good wiki page [which I made a sticky note to do]) and maintains the anonymity level for the clients: 1. Website that wants to be accessible via Tor should setup a hidden service mirror. Given that since it's also a clearnet website, we assume it does not need location anonymity, so single-hop [rendezvous] hidden services can be used which can scale to whatever that website needs. Say I have a 1 gbps line, I don't care about location anonymity because my website is clearnet public anyway and I want my website to handle many Tor users, just setup a bridge Tor instance on localhost (127.0.0.1) not published to the bridge authority, point the second Tor instance to use bridge 127.0.0.1:port and single hop hidden services. The bottleneck here is my own internet line (and CPU probably). Plenty of other solutions like OnionBalance are also available. 2. Website includes in HTTP headers the onion url instead of pinning policy. This MUST be over HTTPS so an user doesn't get redirected to a fake .onion mirror. You have more chances to convince website operators to include just this extra line rather than pinning policy + maintain pinning policy + exit nodes + exit nodes policy + maintain exit nodes policy. The same level of trust is on the CA, not more. 3. We do not necessarily need a SSL certificate for the onion common name, that's already encrypted end to end and self authenticated. We use the clearnet SSL certificate to make sure clients are pointed to the right onion mirror of a clearnet website so there's no additional cost for a second SSL certificate even, as opposite to running a reasonable number of exit relays pinned to a website. On 10/5/2016 11:09 PM, Philipp Winter wrote: > The proposal is in draft state. We have several open questions that we > are still wrestling with in Section 2.6. Any feedback is greatly > appreciated. You can track the evolution of our proposal online: > <https://github.com/NullHypothesis/exit-pinning> > > --- > > Filename: 273-exit-relay-pinning.txt > Title: Exit relay pinning for web services > Author: Philipp Winter, Tobias Pulls, Roya Ensafi, and Nick Feamster > Created: 2016-09-22 > Status: Draft > Target: n/a > [...]
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev