[tor-dev] Proposal 273: Exit relay pinning for web services

[s7r]

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
> [...]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161006/89c87f17/attachment.sig>