Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:53:08Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17957Detect stolen onion service key2020-06-13T14:53:08ZTracDetect stolen onion service keyWould it be possible to add a detection mechanism for stolen onion service keys?
How it could work (I know very little about Tor internals):
A HSDir could tell the tor client that someone else with the same key announced a hidden servic...Would it be possible to add a detection mechanism for stolen onion service keys?
How it could work (I know very little about Tor internals):
A HSDir could tell the tor client that someone else with the same key announced a hidden service just minutes ago.
To determine that it was someone else, a random number could be sent with each announcement of an onion service, and that number randomly changes every time tor is restarted. If tor isn't restarted but the HSDir tells the announcing tor client that a different number was used to announce the onion service before, one could reasonably suspect that the key has been compromised. The user could then try to rule out a false positive, and get a new key.
It might be problematic that the HSDir can lie to .onions it doesn't like, but as long as no automatic action but the notification is done, this shouldn't cause much harm.
**Trac**:
**Username**: ess2Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9689Write proposal for RELAY_AUTHENTICATE/multipath AUTHENTICATE delivery2020-06-13T14:31:44ZMike PerryWrite proposal for RELAY_AUTHENTICATE/multipath AUTHENTICATE deliveryTo protect against relay key theft, it would be useful if relays supported a way to replay the ntor handshake and the DH/ECDH TLS handshake via a directory mirror whose keys are stored in the Tor source code (via #572).
The idea is that...To protect against relay key theft, it would be useful if relays supported a way to replay the ntor handshake and the DH/ECDH TLS handshake via a directory mirror whose keys are stored in the Tor source code (via #572).
The idea is that clients could replay some percentage of their circuits' and TLS connections handshakes via independently authenticated cryptographic paths using the directory mirror keys and #5968. If any one handshake replay failed to yield the same session keys from a replayed DH/ECDH/ntor handshake for any subset of the paths, we know the authentication key for that handshake was stolen and one of the client's paths was MITMed, and we could sound the alarm bells.
We'd probably need two cell types for this: a VERIFY cell that included enough information to replay one or both handshakes, and a RELAY_VERIFY cell that instructed a relay to send an enclosed VERIFY cell on behalf of a remote client.
It would be extra neat if we could use this mechanism as the basis for a proper TLS extension, to allow the whole web to do stuff like this.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7126Multipath consensus integrity verification2020-06-13T14:23:39ZMike PerryMultipath consensus integrity verificationWe want to allow clients to use old consensuses safely without the directory authorities producing new ones. One of the problems with this is ensuring that directory mirrors don't game this time period to feed clients their favorite stal...We want to allow clients to use old consensuses safely without the directory authorities producing new ones. One of the problems with this is ensuring that directory mirrors don't game this time period to feed clients their favorite stale consensus that is still acceptable.
A related problem is "Can we do anything to mitigate malicious targeted consensus delivery in the event that a majority of dirauth signing keys are compromised?"
The common approach for this type of problem is multipath Perspectives-style key authentication. There are several ways we could authenticate the consensus documents in this model. For example, an append-only data structure such as a signed git repo could be created to store consensus hashes for all time. Tor clients could also be modified to store their own chain of observed consensus hashes in a file. In this way, potentially targeted users could drop their consensus hash history onto a USB key, mail it, relocate or otherwise bootstrap an alternate path to the git repo, and verify their connection was not compromised.
A more streamlined Tor-based solution is to extend current Tor directory protocols to allow the set of directory mirrors from #572 to be queried about the latest consensus time they have seen, and for the hash for that consensus time. Clients could then query k of these mirrors, determine the most recent consensus hash that all k mirrors agree on, and request that consensus document from the mirrors that have it. Such requests would be authenticated by the dir mirror identity keys, which would be stored in the Tor source code as part of #572.
This would require additional directory commands ("Tell me the timestamp on your most recent consensus" and "Tell me the hash of that consensus"), as well as some client logic.
The client logic is likely to be the complicated part. It's possible that the dirport commands could be added earlier, allowing us to experiment with various client approaches on the longer term.Tor: unspecifiedhttps://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/5685Publish node best practices doc and scripts2020-06-13T14:19:17ZMike PerryPublish node best practices doc and scriptsI need to convert the Tor Node Best Practices tor-relays post into a wiki page and container creation+update scripts for CentOS/RHEL and Ubuntu LTS.
https://lists.torproject.org/pipermail/tor-relays/2012-April/001268.htmlI need to convert the Tor Node Best Practices tor-relays post into a wiki page and container creation+update scripts for CentOS/RHEL and Ubuntu LTS.
https://lists.torproject.org/pipermail/tor-relays/2012-April/001268.htmlTor: unspecifiedhttps://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: unspecified