[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Proposal 287: Reduce circuit lifetime without overloading the network.
Hi all,
I have updated the proposal 287 taking into account the advice and
comments that you gave me. So please take a look and if you have
something to improve, don't hesitate to let me know.
Thanks everyone for the help. :-)
ffmancera.
-----------------------------------
Filename: 287-reduce-lifetime.txt
Title: Reduce circuit lifetime without overloading the network
Author: Fernando Fernandez Mancera
Created: 30-Nov-2017
Updated: 11-Dec-2017
Status: Open
Motivation:
Currently Tor users are reusing a given circuit for ten minutes (by default)
after it's first used. This time is too long because a malicious Exit relay can
trace a user's pseudonymous profile, especially if connections from multiple
protocols are put on the same circuit.
This time is established on MaxCircuitDirtiness parameter and by default its
value is ten minutes.
I have been thinking in a way to fix this. The first idea that came to my mind
was to use StreamIsolationByHost and StreamIsolationByPort on it, but I wasn't
able to sort it out.
One day, I thought "Why is time so important?" and later on I realized that
maybe focusing on the amount of bytes running through the circuit could end up
being a better approach on this problem.
Design:
I propose two options to reduce this problem, both based on taking into account
the amount of bytes running through a circuit.
MaxCircuitSizeDirtiness (temporal parameter name) will take an integer field
that is contained on an interval and represents the maximum amount of bytes
that can be written/read (we need to discuss about the use of one for both) by
the circuit. If the circuit exceeds that amount, new streams won't use this
circuit anymore.
MaxCircuitSizeDirtinessByPort (temporal parameter name) will take an array of
integers that are contained on an interval and represents the maximum amount of
bytes that can be written/read (we need to discuss about the use of one for
both) by the circuit per port (StreamIsolationByPort). This array is parallel
to the array of ports from StreamIsolationByPort. If the circuit exceeds that
amount, new streams won't use this circuit anymore.
Regarding default values it would be useful to set up one a bit lower than the
average amount of bytes per circuit. On MaxCircuitSizeDirtinessByPort after
discussing it we shouldn't set up a default value because someone can identify
the port used. About MaxCircuitDirtiness, if the others are set up by default
it could be bigger, like thirty minutes, so if the user doesn't send/receive a
significant amount of data the circuit will be changed anyway.
In order to make it more difficult for an attacker to identify user by focusing
on the established amount of bytes, we can introduce a range of
MaxCircuitSizeDirtiness * [0.8, 1.1] per circuit.
Security Implications:
It is believed that the proposed changes will improve the anonymity for end
users. The end user won't reuse a given circuit if they have sent a
considerable amount of bytes, thus making it more difficult for malicious Exit
relays to be able to trace a user's pseudonymous profile.
About the security on Onion services, the proposed changes could improve the
anonymity because if too much data gets sent through a single circuit, it makes
it easy to identify the service's guard. It is not ensured that the guard
changes but it increases the probability.
Obviously this is a probability, of course it's possible that sensitive data
will leak in a little amount of data but it's even more possible that sensitive
data will leak in a large amount.
Specification:
In order to implement this feature we will need to add some new
functionalities. We need to parse MaxCircuitSizeDirtiness and
MaxCircuitSizeDirtinessByPort from the torrc config file. We need to create a
function or improve one to check the amount of bytes that are running through
the circuit and if this amount is higher than the established value, consider
the circuit dirty.
Compatibility:
The proposed changes should not create any compatibility issues. New Tor
clients will be able to take advantage of this without any modification to the
network.
Implementation:
It is proposed that MaxCircuitSizeDirtiness will be enabled by default and also
increase MaxCircuitDirtiness to thirty minutes.
It is proposed that MaxCircuitSizeDirtinessByPort won't be enabled by default
for port 22, 53, and port 80 as StreamIsolationByPort.
How it works with KeepAliveIsolateSOCKSAuth:
- If KeepAliveIsolateSOCKSAuth option is active, then if on
(MaxCircuitDirtiness * 0.5) minutes the amount of bytes sent/received
through the circuit doesn't surpass half of the established amount,
this amount will be reset.
- If KeepAliveIsolateSOCKSAuth option isn't active, then
MaxCircuitSizeDirtiness will work as normal.
Performance and scalability notes:
The proposed changes will reduce Tor network stress as users who do not exceed
the set amount will reduce circuit generation by three (if default
MaxCircuitDirtinesss value is thirty minutes).
I want to work on demonstrate that by a research but first it's nice to get the
idea accepted.
References:
Tor project research ideas [https://research.torproject.org/ideas.html]
Enhancing Tor's Performance using Real-time Traffic Classification
[https://www.cypherpunks.ca/~iang/pubs/difftor-ccs.pdf] (It's not exactly about
that, but they talk about circuit lifetime and the ten minutes problem a few
times. Also it is an interesting paper.)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev