Hello,
I have been working on this proposal for some time and Nick blessed me to send it as Proposal 287.
Here is.
Filename: 287-reduce-lifetime.txt Title: Reduce circuit lifetime without overloading the network Author: Fernando Fernandez Mancera Created: 30-Nov-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 it 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 discuss 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.
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 more difficult for malicious Exit relays to be able to trace a user's pseudonymous profile.
Obviously this is a probability, of course it's possible that sensitive data will leak in a little amount of data but it's more even 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.
About TorBrowser or any other Tor application that is able to manage circuits by its own because of KeepAliveIsolateSOCKSAuth option being active by default shouldn't be affected by this new feature. As the same form that it currently ignores MaxCircuitDirtiness parameter.
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 demonstrating 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's an interesting paper.)
Hi Fernando,
Seems like an important proposal, if there is a good argument that a particular amount of data is "safe". I think your research may help with this.
If everybody chooses different amounts of data, that makes them easier to identify.
On 1 Dec 2017, at 08:47, Fernando Fernández Mancera ffernandezmancera@gmail.com wrote:
About TorBrowser or any other Tor application that is able to manage circuits by its own because of KeepAliveIsolateSOCKSAuth option being active by default shouldn't be affected by this new feature. As the same form that it currently ignores MaxCircuitDirtiness parameter.
We talked about Tor Browser's default behaviour yesterday on #tor-dev.
KeepAliveIsolateSOCKSAuth doesn't ignore MaxCircuitDirtiness: instead, it resets the timer each time a stream is attached to a circuit. This means that circuits stop accepting new streams MaxCircuitDirtiness seconds after they are *last* used for a new stream. (The default is *first used* for a new stream.)
Onion services also have similar behaviour, but we should check the details.
The proposal doesn't specify how KeepAliveIsolateSOCKSAuth and onion services work with MaxCircuitSizeDirtiness and MaxCircuitSizeDirtinessByPort. We need to specify what happens, so the Tor Browser team knows if it needs to change its torrc. And it would help us decide what to set as the default for onion services.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Hi teor,
Seems like an important proposal, if there is a good argument that a particular amount of data is "safe". I think your research may help with this.
Yes, I will try to prove it on the research so I would like to keep the proposal open until the research is finished.
If everybody chooses different amounts of data, that makes them easier to identify.
This reason is why it is not recommended to change the default value, same as for the MaxCircuitDirtiness parameter, so I will specify it on the proposal.
Onion services also have similar behaviour, but we should check the details.
The proposal doesn't specify how KeepAliveIsolateSOCKSAuth and onion services work with MaxCircuitSizeDirtiness and MaxCircuitSizeDirtinessByPort. We need to specify what happens, so the Tor Browser team knows if it needs to change its torrc. And it would help us decide what to set as the default for onion services.
Let me think about it. I will update the proposal soon and I will specify how KeepAliveIsolateSOCKSAuth and onion services work with this new feature.
ffmancera.
On 2 Dec 2017, at 04:56, Fernando Fernández Mancera ffernandezmancera@gmail.com wrote:
If everybody chooses different amounts of data, that makes them easier to identify.
This reason is why it is not recommended to change the default value, same as for the MaxCircuitDirtiness parameter, so I will specify it on the proposal.
If a Tor option has a default value, and we don't recommend changing it, we try to remove that option. So we are unlikely to accept a patch for a new option unless there is some compelling use case for a group of users to set it differently.
Otherwise, we would accept code to set a default and keep that default.
Onion services may be a use case for this option, because if too much data gets sent through a single circuit, it makes it easy to identify the service's guard. (Of course, this only protects the service if the next circuit uses a different guard, which is not guaranteed.)
Alternately, Tor Browser may be a use case for this option, if it wants to manage its circuits itself, regardless of the amount of data they send.
T
Hello,
Fernando Fernández Mancera wrote: [...]
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.
Interesting proposal.
Please see this: https://lists.torproject.org/pipermail/tor-dev/2014-September/007517.html
And especially this reply: https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html
It would be very nice if you could glue these into this proposal as well.
This time it 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.
It makes sense, but the hardest thing here is coming with the right amount of bytes value so we won't end up building on average more circuits than we were with the 10 minutes time dirtiness configuration.
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.
I just want to understand something clear so pointing it out, because it reads "maximum amount of bytes...": the MaxCircuitSizeDirtiness counter will count bytes read/write on a circuit by all streams attached to that circuit, and as soon as threshold is reached the circuit will be marked as dirty, but the circuit will be closed when all streams are idle, correct? Like
If MaxCircuitSizeDirtiness is 10000 bytes (just for example) I could download a file of 150000 bytes from a destination host:36455 over the same circuit, via a single stream, and as soon as that stream is idle, count 150000 > 10000 --> mark circuit dirty, stop attaching new streams to it? I think you thought of this but want to confirm.
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 discuss 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.
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 more difficult for malicious Exit relays to be able to trace a user's pseudonymous profile.
Obviously this is a probability, of course it's possible that sensitive data will leak in a little amount of data but it's more even 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.
About TorBrowser or any other Tor application that is able to manage circuits by its own because of KeepAliveIsolateSOCKSAuth option being active by default shouldn't be affected by this new feature. As the same form that it currently ignores MaxCircuitDirtiness parameter.
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 demonstrating that by a research but first it's nice to get the idea accepted.
Looking forward to see some preliminary statistics. Please think of this threat model:
- an attacker discovers the location of an onion service. He hijacks it, but does not alter the content or the functionality of the service, in order not to signal the discovery to its users and further deanonymize as many users as he can.
- he starts serving useless noise on that services so the bytes limit threshold is reached fast, forcing users to build circuits more often than the time dirtiness method.
- the attacker also controls some hostile relays that could potentially be picked in any new created circuit.
Do we increase the success changes for these kind of attackers? make it harder for them ? Or does the game remain unchanged?
The time dirtiness cannot be gamed by the attacker because it is based just on user's action (or inaction), but the bytes sent over the circuit can. That is why it is there in the first place.
If this sounds bad, here are two crazy ideas you could take into consideration when doing the numbers: 1. Put a hard limit per stream as in how much a single stream can count to the MaxCircuitSizeDirtiness threshold in terms of %, if that is exceeded the bytes in excess are simply discounted, so it becomes impossible for a circuit to be marked dirty "by size" just by being used by a single stream. 2. Make MaxCircuitSizeDirtiness random, a value between n and m, where m cannot be greater than n * q, for *each* circuit. 3. Both 1. and 2.?
Either way, thanks for working on this - this area needs some attention and I am sure we can do better.
Hi,
Interesting proposal.
Please see this: https://lists.torproject.org/pipermail/tor-dev/2014-September/007517.html
And especially this reply: https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html
It would be very nice if you could glue these into this proposal as well.
It looks interesting so I will try to get it included into the proposal in the next update.
It makes sense, but the hardest thing here is coming with the right amount of bytes value so we won't end up building on average more circuits than we were with the 10 minutes time dirtiness configuration.
Of course it will be something really hard but my first idea is to use an amount of bytes a little low than the average amount in ten minutes.
I just want to understand something clear so pointing it out, because it reads "maximum amount of bytes...": the MaxCircuitSizeDirtiness counter will count bytes read/write on a circuit by all streams attached to that circuit, and as soon as threshold is reached the circuit will be marked as dirty, but the circuit will be closed when all streams are idle, correct? Like
If MaxCircuitSizeDirtiness is 10000 bytes (just for example) I could download a file of 150000 bytes from a destination host:36455 over the same circuit, via a single stream, and as soon as that stream is idle, count 150000 > 10000 --> mark circuit dirty, stop attaching new streams to it? I think you thought of this but want to confirm.
Yes, the moment the circuit exceeds the amount of bytes established it will stop attaching new streams to it. But the attached ones will continue sending/receiving data until idle.
Looking forward to see some preliminary statistics. Please think of this threat model:
- an attacker discovers the location of an onion service. He hijacks it,
but does not alter the content or the functionality of the service, in order not to signal the discovery to its users and further deanonymize as many users as he can.
- he starts serving useless noise on that services so the bytes limit
threshold is reached fast, forcing users to build circuits more often than the time dirtiness method.
- the attacker also controls some hostile relays that could potentially
be picked in any new created circuit.
Do we increase the success changes for these kind of attackers? make it harder for them ? Or does the game remain unchanged?
The time dirtiness cannot be gamed by the attacker because it is based just on user's action (or inaction), but the bytes sent over the circuit can. That is why it is there in the first place.
If this sounds bad, here are two crazy ideas you could take into consideration when doing the numbers:
- Put a hard limit per stream as in how much a single stream can count
to the MaxCircuitSizeDirtiness threshold in terms of %, if that is exceeded the bytes in excess are simply discounted, so it becomes impossible for a circuit to be marked dirty "by size" just by being used by a single stream. 2. Make MaxCircuitSizeDirtiness random, a value between n and m, where m cannot be greater than n * q, for *each* circuit. 3. Both 1. and 2.?
Either way, thanks for working on this - this area needs some attention and I am sure we can do better.
I was thinking in the second option but I need more time to make sure this is fine.
I will update the proposal in the next weeks, thank you for your advices.
ffmancera.
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.)
On 13 Dec 2017, at 06:33, Fernando Fernández Mancera ffernandezmancera@gmail.com wrote:
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.
Is there any reason you picked these values?
Typically, when we randomise something, we make sure the parameter values is the average.
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.
Is there any research supporting this? Is it compelling enough to offset the usability issues? (See below.)
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.
This we believe to be true, and we think we've seen attacks using it. But changing circuits doesn't help those attacks.
Also, are you proposing that services mark circuits dirty? Because Tor doesn't work like that right now. Only clients mark circuits dirty.
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.
This will break usability on many websites that depend on requests coming from the same IP address. This is why Tor Browser manages its own circuit lifetimes, and this change would break that.
- 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.)
On 12/12/2017 11:34 PM, teor wrote:
Is there any reason you picked these values?
I have chosen those values because if the user sets a value, I think it is better for this value to be around lower one from the already established. Even so, higher values are included to make it more difficult for the attacker to identify.
I've been thinking, it might be better if this value changes every time a circuit is marked dirty.
Is there any research supporting this? Is it compelling enough to offset the usability issues? (See below.)
I am working on it, so I will try to get it soon as possible.
This we believe to be true, and we think we've seen attacks using it. But changing circuits doesn't help those attacks.
Oh well, I missunderstood you in the last reply I think. I thought if the circuit changes more often then is more probably that it uses a different guard.
Also, are you proposing that services mark circuits dirty? Because Tor doesn't work like that right now. Only clients mark circuits dirty.
No no, I mean clients. I will try to think deeply how it can works with Onion services.
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.
This will break usability on many websites that depend on requests coming from the same IP address. This is why Tor Browser manages its own circuit lifetimes, and this change would break that.
Well, as above I will try to find a good use for this option combined with MaxCircuitSizeDirtiness. So probably I will write back in mid-January but if you find one, please let me know.
ffmancera.
-
Fernando Fernández Mancera -
s7r -
teor