Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:29:30Zhttps://gitlab.torproject.org/legacy/trac/-/issues/9001Slow Guard Discovery of Hidden Services and Clients2020-06-13T14:29:30ZMike PerrySlow Guard Discovery of Hidden Services and ClientsIn http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf, one of the attacks described is a method for locating the Guard nodes of a hidden service within about an hour.
It also seems possible to locate the Guard nodes of persisten...In http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf, one of the attacks described is a method for locating the Guard nodes of a hidden service within about an hour.
It also seems possible to locate the Guard nodes of persistent, automated clients in a similar timeframe by similarly repeatedly destroying HSdir lookup circuits for your target hidden service.
These attacks are possible to execute on such rapid timescales because *each* endpoint in hidden service communications can destroy the current circuit, and force the other party to create a new one using a new middle node.
There are at least three ways to slow this attack:
1. Multiple layers of guard nodes.
1. Create a "Virtual Circuit" abstraction layer that picks your hops for a given purpose, and tries to re-use those hops even after certain failure conditions.
1. Change the Tor Protocol to prevent DESTROY cells and other mechanisms of circuit destruction from destroying the counter-party's endpoint, and create mechanisms for multiple clients to share a single HS rend circuit (such as I2Ps 'garlic routing' concept).
Nick and I are tentatively leaning towards the "Virtual Circuit" approach. Such a layer would cleanly decouple path selection from circuit use, and allow us to do things like keep the same three hops for rend and intro circuits for N days, regardless of transient circuit failures or DESTROY cells.
This would considerably slow the attack, and also make all sorts of anonymity metrics and analysis easier to do. For example: We can choose N intelligently such that we would expect the runtime of the attack to be a function of our guard lifetime from #8240, or we could define lifetime based on expected circuit use and application-provided linkability hints (such as #5752).
We can also use the layer to improve the path bias accounting to only count failure if you are forced to choose a new path, rather than simply make a new circuit.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7582Don't disable exits so harshly for unexpected END_REASON_EXITPOLICY2020-06-13T14:25:17ZNick MathewsonDon't disable exits so harshly for unexpected END_REASON_EXITPOLICYSee Roger's tor-dev message at https://lists.torproject.org/pipermail/tor-dev/2012-November/004179.html and ensuing discussion.
It's wrong to completely disable an exit for the crime of having exceptions to its policy summary, since tha...See Roger's tor-dev message at https://lists.torproject.org/pipermail/tor-dev/2012-November/004179.html and ensuing discussion.
It's wrong to completely disable an exit for the crime of having exceptions to its policy summary, since that's just a summary.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7509Publish and use circuit success rates in extrainfo descriptors2020-06-13T14:25:06ZMike PerryPublish and use circuit success rates in extrainfo descriptorsarma suggests we publish create cell success rates in the extrainfo descriptors. We want to use these values to measure the actual rate of client circuit success network wide given our current path selection weights.
In this simple case...arma suggests we publish create cell success rates in the extrainfo descriptors. We want to use these values to measure the actual rate of client circuit success network wide given our current path selection weights.
In this simple case, a graph traversal computation would do the trick, but ideally we want to do it in a way that is liar-resistant. Does this mean we should publish information on our observed peers' rates of CREATE success instead?
Perhaps this can be modeled as an eigenvalue problem, a-la eigenspeed (#5464). Since we're computing only a single scalar value for the whole network at the end as opposed to a vector of weights, there might be a simplification we could deploy that reduces the amount of stuff we need to shove into extrainfo.
Either way, an extrainfo-based approach may end up being simpler to implement than a centralized scanner for reliably measuring circuit failure (see #7281).
I'm not sure I trust a fully self-reported scheme more without some kind of liar resistance, but it might end up that doing the graph traversal already bakes in as much liar resistance as you'd get from having each node report on its peers. It might be possible to prove this even, but something tells me empirical simulation is as close as we're going to get.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7157"Low circuit success rate %u/%u for guard %s=%s."2020-06-13T14:25:45ZRoger Dingledine"Low circuit success rate %u/%u for guard %s=%s."I'm seeing this "low circuit success rate" warning on my client sometimes when on a flaky wireless network connection.
I'm guessing that the problem is that we're blaming the guard when we should in fact be blaming the network.
We shou...I'm seeing this "low circuit success rate" warning on my client sometimes when on a flaky wireless network connection.
I'm guessing that the problem is that we're blaming the guard when we should in fact be blaming the network.
We should a) figure out how to improve the log message so we get more hints about where our bug is, and/or b) just straight-out hunt for it.
Mike suggests raising the number of circuits we have to make before we'll spit out the warning. I expect that will mask the bug, but not find or resolve it.
Bug report originally raised in #7066.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7003Wipe relay key material from memory on common crash conditions2020-06-13T14:23:13ZMike PerryWipe relay key material from memory on common crash conditionsTor should wipe key material before common crash conditions, to avoid key material leak in the case where relay operators have otherwise taken steps to keep key material off of disk.
There are two vectors towards obtaining key material ...Tor should wipe key material before common crash conditions, to avoid key material leak in the case where relay operators have otherwise taken steps to keep key material off of disk.
There are two vectors towards obtaining key material after crash: core files, and large mmap attempts by other users' processes.
It turns out many OS kernels do not provide ways to defend against the latter case. Therefore, tor should attempt to wipe sensitive key material on atexit, SIGSEGV, SIGBUS, tor_assert() and other common exit conditions.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6135Tune + tighten path bias parameters2020-06-13T14:21:58ZMike PerryTune + tighten path bias parametersThe path bias defenses in #5458 and #5956 will have tunable parameters to allow us to dial in on the lowest acceptable amount of bias while not also breaking stuff.
That is going to require more work and attention, though. It's possible...The path bias defenses in #5458 and #5956 will have tunable parameters to allow us to dial in on the lowest acceptable amount of bias while not also breaking stuff.
That is going to require more work and attention, though. It's possible that network scanners (ie #5459) can provide us with answers for #5458.
We can also ask our volunteer QA team to report what sorts of values they see in their logs for stuff like this, to get an idea on real ranges in real clients.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5968Improve onion key and TLS management2022-03-22T12:59:29ZMike PerryImprove onion key and TLS managementAs a best practice behavior, a relay should check that the onion key it tried to publish is actually the one it sees in the consensus in which it appears.
The onion key should also be what authenticates the TLS key (rather than the iden...As a best practice behavior, a relay should check that the onion key it tried to publish is actually the one it sees in the consensus in which it appears.
The onion key should also be what authenticates the TLS key (rather than the identity key, as it is now).
This would prevent some utility vectors of identity key theft, where a non-targeted upstream MITM attempts to use a relays identity to impersonate it in order to execute a tagging attack (#5456).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5956Thresholds of nodes to build circuits should be tunable and maybe consider we...2020-06-13T14:19:50ZNick MathewsonThresholds of nodes to build circuits should be tunable and maybe consider weights tooOn #5343, Mike notes that he doesn't like the 1/3 threshold for having sufficient exit nodes to build circuits.
Arguably, this threshold (and the other threshold changed in #3196) should be consensus parameters too.
Arguably, there sho...On #5343, Mike notes that he doesn't like the 1/3 threshold for having sufficient exit nodes to build circuits.
Arguably, this threshold (and the other threshold changed in #3196) should be consensus parameters too.
Arguably, there should also (or instead?) be a minimum threshold by weight.
I'm marking this for 0.2.4.x, but it's likely to be very backportable.Tor: 0.2.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/5563Better support for ephemeral relay identity keys2020-06-13T18:11:25ZMike PerryBetter support for ephemeral relay identity keysTagging-based amplification attacks are primarily an issue of node integrity. For the most part, they are impossible to perform if you are external to the tor network, and they are detectable if the adversary's proportion of compromised ...Tagging-based amplification attacks are primarily an issue of node integrity. For the most part, they are impossible to perform if you are external to the tor network, and they are detectable if the adversary's proportion of compromised nodes on the network is low, due to excessive circuit failure at non-colluding nodes.
However, this all changes if most nodes have easily accessible identity keys. All the adversary need do is make a quick stop at each high capacity tor relay, freeze the ram/reboot the box, and extract the keys. From that point on, the adversary is free to intercept and tag traffic transparently upstream. Worse, as the adversary performs this procedure at more and more nodes, their circuit failure rate will fall. At least according to the math of some dude who claims to be a raccoon: https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html
I believe the best stopgap solution to this (at least until whatever comes out of #5460 is deployed) is to encourage relay operators to keep their relay keys on a ramdisk, so they are discarded in the event of reboot. This would at least require the adversary to retain persistent access to the machine, which risks discovery via auditing mechanisms.
Unfortunately, there are a few issues with how Tor treats relay identity keys that makes it extremely inconvenient for relay operators if they ever change.
This ticket is to serve as the parent ticket for enumerating these inconveniences.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5460Write proposal(s) to implement improved relay/circuit crypto authentication2020-06-13T14:50:11ZMike PerryWrite proposal(s) to implement improved relay/circuit crypto authenticationWe need to write a proposal to determine the best way to provide authentication to our circuit crypto, so that cells that have been tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not the third.
As I understand it...We need to write a proposal to determine the best way to provide authentication to our circuit crypto, so that cells that have been tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not the third.
As I understand it, there are two competing possibilities:
1. Self-authenticating crypto (BEAR/LION/LIONESS, others?)
2. Per-hop MAC
The main disadvantage of 1 is that it's likely slow and not very many people use it. The disadvantage of 2 is that it requires us to disclose path length count and position to nodes, as well as have MACs that either grow with increased path length, or become less secure with increased path length.
There are probably other issues. I believe the current plan is to produce both options in one or more proposals and compare and contrast them.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/5459Exit scanner should scan for Guard <-> Exit reachability2020-06-13T16:18:58ZMike PerryExit scanner should scan for Guard <-> Exit reachabilityThe Tor Exit Scanner should be checking to ensure that all Guard nodes can create circuits to all Exit nodes, to attempt to detect tagging and path bias attackers who fail circuits that don't go through colluding nodes.The Tor Exit Scanner should be checking to ensure that all Guard nodes can create circuits to all Exit nodes, to attempt to detect tagging and path bias attackers who fail circuits that don't go through colluding nodes.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/legacy/trac/-/issues/5458Clients should warn and disable guards responsible for excessive circuit fail...2020-06-13T14:20:24ZMike PerryClients should warn and disable guards responsible for excessive circuit failuresIn https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html, the raccoon gave us some bounds to determine unreasonable amounts of circuit failure that indicate a potential tagging attack.
Tor Clients should emit warnings an...In https://lists.torproject.org/pipermail/tor-dev/2012-March/003361.html, the raccoon gave us some bounds to determine unreasonable amounts of circuit failure that indicate a potential tagging attack.
Tor Clients should emit warnings and disable guards if they observe anywhere near this amount of circuit failure per guard. His bound for tagging was 80%, but frankly if even 50% of my circuits are failing, I would want tor to tell me.
Maybe >50% failure should notice and >66% failure should warn?Tor: 0.2.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/5457Bw auths don't count circuit failures in descriptor mode2022-03-10T15:30:22ZMike PerryBw auths don't count circuit failures in descriptor modeWhen we are using descriptor bandwidth (ie no feedback), we are unable to properly use circuit failure statistics to penalize nodes that are either attempting path bias, or are just experiencing CPU overload.
The fix *should* be simple....When we are using descriptor bandwidth (ie no feedback), we are unable to properly use circuit failure statistics to penalize nodes that are either attempting path bias, or are just experiencing CPU overload.
The fix *should* be simple. I think we just need to add another clause in aggregate.py where we check for use_circ_fails to also check for use_desc_bw and properly combine the pid_error and circ_error for that case (perhaps just by multiplying them).sbws: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5343Require a threshold of exit nodes before believing we can build circuits2020-06-13T14:19:50ZNick MathewsonRequire a threshold of exit nodes before believing we can build circuitsWe should not allow circuits to get built unless we know descriptors for a sufficiently large fraction of exit nodes.
This should mitigate an attack proposed by wanoskarnet, wherein your bridges collude to only tell you about compromise...We should not allow circuits to get built unless we know descriptors for a sufficiently large fraction of exit nodes.
This should mitigate an attack proposed by wanoskarnet, wherein your bridges collude to only tell you about compromised exits. See also #5342.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3890Applications should start using optimistic data2020-06-15T23:13:29ZNick MathewsonApplications should start using optimistic dataIf we've got any applications that speak a protocol where latency matters, and where connections typically start out with the client sending data, then we should look into making them support optimistic data. (This means that the client...If we've got any applications that speak a protocol where latency matters, and where connections typically start out with the client sending data, then we should look into making them support optimistic data. (This means that the client sends data before hearing about whether the socks connection is successful.)
I'm calling this "bundles", but it should mostly focus on application-specific subtickets.