11 ms·

Deanonymizing Tor Circuits

243 points by zbentley 7y ago

Thorrez 7y ago
Why would people spend effort trying to deanonymize an Internet Archive server? Are try trying to deanonymize every single hidden service? And why would they try to DDOS the services once deanonymized? I don't see how anyone would gain anything from that. If you DDOS some big website you get famous from all the news articles being written about you, but DDOSing a hidden service won't make you famous.
- Nextgrid 7y ago
  From what I understand the DDoS is necessary to force the Tor daemon to choose a new guard which is what they need for their attack. As far as deanonymizing it goes, one theory could be that it’s an automated process that crawls the open web for onion links and tries to deanonymize them all.
- jimrandomh 7y ago
  If they want to find out whether a deanonymization technique works, they would choose a target whose identity and location is already known, so that they can confirm that the attack produced the right answer.
- hackerfactor1 7y ago
  I don't know this attacker's reason. I only see the attack. But I can offer some baseless suspicions: I'm forwarding traffic from Tor to the Internet Archive. During the last French election, someone DoS'ed most of their media outlets. As a result, lots of French people used Tor to access the current news from the Internet Archive's collection. Shortly after that, someone tried to DDoS my onion service. With all of the voting and elections and the impeachment vote coming up, I'm expecting attacks since the Internet Archive stores lots of information that the current administration tried to remove from the Internet. Then again, it could be a "researcher", or just someone seeing if it can be done. Perhaps they will decide what they want to do after their attack succeeds.
  - incompatible 7y ago
    Perhaps countries that have already blocked the Internet Archive? But Tor users can already access it through Tor without a hidden service. If the IA itself was DoSed then wouldn't your relay stop working?
    - gruez 7y ago
      random guess: the servers are reached via anycast. if you DDoS from the US, you'll take down access from the US, but not from other regions.
      - oofabz 7y ago
        It's not much of a DDoS if it's from a single country.
        az656 7y ago
        That’s pretty invalid — I often see large attacks that are almost entirely made up of bots from one country.
        lima 7y ago
        I've even seen 100+ Gbps from a single ASN in a single country.
      - az656 7y ago
        Isn’t the point of anycast to absorb the brunt of the attack? If your traffic is localized, maybe dropping the announcement for that PoP would be useful.
  - aasasd 7y ago
    Now we have a mystery of why Frenchmen had to use Tor to read the Internet Archive.
aasasd 7y ago
> many bots will only do one HTTP connection at a time (single threaded) Is it only service admins who do such detective work, or do admins of intermediate nodes also try to filter out bots? I wonder if simple API calls wouldn't get caught in the crossfire.
- Ajedi32 7y ago
  Intermediate nodes can't see HTTP connections. Tor traffic is encrypted.
bitcoinz 7y ago
Bitcoin full nodes running over Tor can also be attacked similarly? I think yes however not sure and not every full node over Tor follows same configuration
- contingencies 7y ago
  All crypto services should be run through a decentralized, extra-codebase voting scheme to generate a confidence interval. Mature services like Bitcoin should have multiple clients and client versions available, geographically distributed across a range of networks, frustrating identification and creating an aggregate mechanism for rapidly detecting anomalous output and mitigating unknown attacks. I implemented this ~8 years ago.
  - bitcoinz 7y ago
    8 years ago? Can you share any link which has details about the implementation?
    - contingencies 7y ago
      Sorry no, it was internal work at Kraken.
      - bitcoinz 7y ago
        lol
jimbo1qaz 7y ago
The embedded images are ugly because of the downscaling (the URL contains &size=600).
- hackerfactor1 7y ago
  Fixed.
quotemstr 7y ago
Why do you suppose the Tor project has been so resistant to mitigating this class of attack? In particular, the proposal to require that rendezvous nodes be publicly listed seems sensible to me, and I wasn't immediately able to find any Tor bugs on the subject.
- Astarte 7y ago
  That's a good question indeed. I don't have an answer but some people got similar results when pointing out some issues internally. Only when publishing those on the mail list where everyone can read it things started to gain some traction. "In April 2018 a Tor core member — the most active Tor Project person on that closed mailing list — made an attempt to initiate a “do not do” relay requirements list to improve and streamline the handling of malicious Tor relay reports. (I’m not mentioning his name since he does not want to be publicly associated with bad-relays handling for safety reasons.) Unfortunately also this attempt failed since no Tor directory authority operator answered. (Tor directory authorities are required to enforce any Tor network wide rules unless it is part of the tor code itself.) Starting with June 2019, after multiple reports about suspicious relays remained with no reaction I stopped sending them to the list. Occasionally I sent some suspicious relay groups to the public tor-talk mailing list instead — which ironically was more fruitful." https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548?source=---------5------------------ https://medium.com/@nusenu/the-growing-problem-of-malicious-... Even more ironical, the very person which reported that issue and similar ones (also on twitter) got his twitter account closed shortly afterwards (see other post on that site). So he has much less audience than before. Coincidence? Tinfoil hattery? Maybe. But certainly fishy.
noident 7y ago
First: it seems like the author has come up with a number of useful custom modifications to the Tor daemon to mitigate common attacks against onion operators. Why not work with the Tor Project to upstream some of the more useful ones, as well as the additional debugging information? Reading past Hacker Factor posts, is it just me, or is there a tone of slight disdain towards the Tor project? Second: >However, there's a second attack. The attacker can run one or more hostile guard nodes. If he can knock me off enough guards, my tor daemon will eventually choose one of his guards. Then he can identify my actual network address and directly attack my server. (This happened to me once.) A guard node is going to get a lot of traffic from both onion services and normal Tor users. How can an evil guard node tell which IP belongs to the author's server? Overall, this is startling to read. History suggests that it is only a matter of time before an onion service gets unmasked by the latest attack on the Tor network.
- Operyl 7y ago
  If you read his various articles, and even in this article, he mentions that the Tor team is resistant to a lot of his proposed changes.
  - noident 7y ago
    I have read the articles, but have not found an explanation or specific examples. It's not as if Tor doesn't care about onion services; they just spent 4 years designing and implementing the v3 onion service protocol.
    - SolarNet 7y ago
      It's pretty obvious when one gets stonewalled for political reasons when attempting to contribute to a project. He doesn't need to provide specific examples or explanations, doing so just makes the issue worse. Often these issues involve specific people and specific intuitions that will be hard to interpret without lots of context. It will put the problem people on the defensive and likely cause some sort of outrage or personal attacks, or other unwanted drama. Being polite yet firm on his own page is the best that can really be done in these situations. It allows the technical problem to be magnified while not focusing on drama.
mirimir 7y ago
Good work! > However, there's a second attack. The attacker can run one or more hostile guard nodes. If he can knock me off enough guards, my tor daemon will eventually choose one of his guards. Then he can identify my actual network address and directly attack my server. (This happened to me once.) I also worry about malicious guards. For local machines, I only hit Tor via nested VPN chains. So even if I'm using a malicious guard, the attacker will just get the IP of the exit VPN server. For onion services, I typically use VMs in dedicated servers. And so I can put at least one VPN-gateway VM between the onion server VM and the Tor guard. You could also get all of the guards from tor's state file, and hard-code them in torrc with EntryNode. That wouldn't prevent an attacker from taking the site offline, but at least they couldn't become your guard.
- Operyl 7y ago
  Your last point falls flat if they’re already running a public guard though.
  - mirimir 7y ago
    Why? It "falls flat" if you're using a malicious guard. But then, you're already screwed, in that case.
    - Operyl 7y ago
      Because they could already be running a node that's indexed and has the guard flag.
- Astarte 7y ago
  They could still figure out your guard and attack it directly.
matheusmoreira 7y ago
ExcludeExitNodes {br} Why are brazilian IP addresses associated with abuse? Lots of sites refuse to respond to my browser because of this.
- adrianN 7y ago
  Because a lot of abuse comes from Brazilian IPs. Maybe because people in Brazil have enough money to buy a computer, but not enough money to buy computers that can run the latest versions of Windows?
- deoxykev 7y ago
  Looks like it primarily comes from two ASN's in Brazil: CLARO S.A. (AS28573) and TELEFÔNICA BRASIL S.A (AS18881). Interestingly, it looks like Brazil is right up there with Russia when it comes to total number of risky ASN's. source: https://www.recordedfuture.com/asn-blocklist-analysis/ https://www.recordedfuture.com/asn-blocklist-analysis/
bureaucrat 7y ago
If you need a location hidden service it’s wise to run your own guard.
- noident 7y ago
  Wouldn't your onion service uptime become correlated with the guard's uptime? DDoS probes as described in the OP plus some basic monitoring of known onion sites could discover onions paired with single guard nodes. And if I can become certain that the guard node is owned by the onion operator, you're one subpoena away from deanonymization.
  - Astarte 7y ago
    >Wouldn't your onion service uptime become correlated with the guard's uptime? Yes. This is happening on a fairly regular basis. ddos against a tor node in most cases is just trying to figure out someones IP address or guard node. If you run a big darknet site dealing with things like drugs, CP, fraud, and you want to stay around for a while you need to run lots of nodes otherwise you will be pwned probably within hours. There is no point in doing that for legal onions sites like facebook because everyone knows their real operators. Now when you run lots of nodes and at the same time a big website on the darknet you are in the perfect position to run traffic correlation attacks yourself. There is some tutorial available which suggests using some deceptive methods to spoil such tracing efforts. For example when website A is going down you also shut down your site. Or when there is a big blackout of AWS US etc
- hackerfactor1 7y ago
  Running your own guard is stupid unless you open it for the world to use. If you're the only person using the guard, then the guard offers you zero anonymity. And if lots of people use your guard, then make sure it doesn't violate your ISP's terms of service. (Most ISPs have a clause about residential customers not running public services.) Also, have a plan in place for when (not if) you receive legal notices about copyright infringement, child porn distribution, and other acts that could be criminal in your country/city.
Santosh83 7y ago
Interesting related post: https://www.reddit.com/r/encryption/comments/exjk9e/the_majority_of_tor_nodes_are_in_the_14_eyes/ https://www.reddit.com/r/encryption/comments/exjk9e/the_majo...
Santosh83 7y ago
Also is it not weaker from an anonymity standpoint for the tor deamon to choose the same nation for the entire Tor circuit? I just fired up Tor Browser, navigated to the Tor Blog and this is what I get: https://imgur.com/a/j7JZFVl https://imgur.com/a/j7JZFVl
- Astarte 7y ago
  This has been mentioned on the tor irc several times and also on some other places. No one cared ...
gzer0 7y ago
I think a lot of comments here are forgetting it takes months to be considered a trusted guard node by TOR. Unless you have hundreds of these and a lot of time and patience, and somehow knock off all of the non-malicious guard-nodes + have your "aged" guard nodes set up, this attack will be very difficult to conduct.
- Santosh83 7y ago
  Which the larger countries do. And the main point of Tor is to evade serious adversaries isn't it? If you're not anonymous from nation states when using Tor, then what will protect whistle-blowers and investigative journalists and dissidents? VPNs can be ordered to turn over data by courts and you can never be sure a "no logs" VPN does what it says. Tor is the only viable alternative and we know it can be at least seriously compromised by the bigger nations.
  - azalemeth 7y ago
    What about i2p and Freenet?
    - mirimir 7y ago
      About Freenet, see https://news.ycombinator.com/item?id=22216177 https://news.ycombinator.com/item?id=22216177 I2P was rather like the love child of Freenet and Tor. Like Freenet, it's pure P2P, where all users route traffic for each other. And although there are outproxies to the open Internet, it's mostly about I2P-hosted content. If anything, it's mostly like Tor onion services. It uses a version of Tor's onion routing, called garlic routing. The main difference is that I2P tunnels are unidirectional, whereas Tor tunnels are bidirectional. That will allow for content caching and bundling, but that's not implemented yet. There are reportedly ~10^4 I2P nodes, versus ~2x10^6 Tor users and ~6x10^3 relays. It's been argued that unidirectional tunnels are harder to deanonymize than bidirectional tunnels. But on the other hand, all I2P nodes are readily discoverable by malicious peers, but Tor users are much harder to discover, because Tor clients don't change guards frequently. So bottom line, they arguably provide similar anonymity. Edit: Yes, guards can discover users. But Tor is designed to make it hard for a given guard to see that many users. So you'd need lots of guards. And that's not so easy, because Tor folk are constantly on the lookout for suspicious guards, especially when a bunch show up at the same time.
ur-whale 7y ago
I wonder if Wireguard is dynamic and lightweight enough to be hacked into re-implementing something like tor but that dynamically shuffles data paths in flight ?
- mirimir 7y ago
  Good point! Actually, that works well enough with OpenVPN. I've managed a crude setup that switches two-hop nested VN chains at 10 minute intervals.[0] I should also have mentioned the Orchid app for Android (and perhaps soon for iOS).[1] It implements dynamic multi-hop routing, and reputation-based route selection. As I understand it, commercial VPNs are providing OpenVPN servers for the network, and I would hope that each hop uses a different provider. Users buy bandwidth with supposedly anonymous Etherium-based cryptocurrency. Orchid may provide privacy and anonymity that's at least comparable to do-it-yourself nested VPN chains, and perhaps comparable to Tor. In that you're distributing information and trust among multiple providers, who are paid anonymously. And it's obviously far less work than nested VPN chains. But as with Tor, there's the downside of trusting a complex system, which you likely won't understand well. There's also the issue that current smartphones are so horribly insecure that using such tools arguably provides merely an illusion of security, privacy and anonymity. 0) https://github.com/mirimir/vpnchains https://github.com/mirimir/vpnchains 1) https://www.orchid.com/ https://www.orchid.com/
mirimir 7y ago
This finally hit the tor-dev list.[0] And Mike Perry's post is somewhat alarming.[1] Some excerpts: > The "Oddly, sometimes the connection would succeed" sentence is a red flag sentence. If you are inclined to be paranoid, there is indeed a way to hide a real attack in what looks like a simple ntohl() bug here. > This "sometimes"connection behavior is often seen in tagging attacks, where the adversary abuses Tor's AES-CTR mode stream-cipher-style properties to XOR a tag at one end of a circuit, and undo that tag only if the other endpoint is present. In this way, only the connections that actually succeed are those that the adversary is certain that they are in both positions in the circuit (to perform Guard discovery, or if they are the Guard relay, to confirm deanonymization). > If you want to hide your tagging attack as what looks like a simple ntohl() bug here, you send your intro2 with the reverse IP address. Then, when your middle node suspects a candidate rend cell (via timing + circuit setup fingerprinting, to have a guess), it can confirm this guess by undoing the tag by XORing the cipherstream with ntohl(ip) XOR ip. > <snip> > Aka a correctly performing rend cell tag hidden in what looks like a very common networking bug. > This cipherstream tagging weakness has had a few proposals to fix, most recently: https://gitweb.torproject.org/torspec.git/tree/proposals/295-relay-crypto-with-adl.txt https://gitweb.torproject.org/torspec.git/tree/proposals/295... > BUT DON'T PANIC: There is also an alternate explanation for the "sometimes succeed" red flag in this particular case, other than a tagging attack. > <snip> > So most likely, this is just a poorly written Tor client, but there still is the possibility that it is an attack cleverly disguised as a poorly written Tor client.. :/ > It may be a good idea for Neal's/our monitoring infrastructure to keep an eye on this behavior too, for this reason, to test for the side channel usage + rend XOR "correction" vs just dumb bug that is sometimes connecting by getting lucky (and thus never properly reverses the rend IP address). If this is indeed just a bug, when these rends do succeed, the IP address should never be correct. > The way to do that would be to build rend circuits using 3rd hops that you (the service operator) control, so that that 3rd hop can check if the rend succeeds because the TLS connection happened to be open (benign behavior) or because the reversed ntohl() got corrected somehow (attack). 0) https://lists.torproject.org/pipermail/tor-dev/2020-February/014146.html https://lists.torproject.org/pipermail/tor-dev/2020-February... 1) https://lists.torproject.org/pipermail/tor-dev/2020-February/014154.html https://lists.torproject.org/pipermail/tor-dev/2020-February...
- 7y ago

243 points by zbentley 7y ago

Why would people spend effort trying to deanonymize an Internet Archive server? Are try trying to deanonymize every single hidden service? And why would they try to DDOS the services once deanonymized? I don't see how anyone would gain anything from that. If you DDOS some big website you get famous from all the news articles being written about you, but DDOSing a hidden service won't make you famous.

Nextgrid 7y ago
From what I understand the DDoS is necessary to force the Tor daemon to choose a new guard which is what they need for their attack. As far as deanonymizing it goes, one theory could be that it’s an automated process that crawls the open web for onion links and tries to deanonymize them all.
jimrandomh 7y ago
If they want to find out whether a deanonymization technique works, they would choose a target whose identity and location is already known, so that they can confirm that the attack produced the right answer.
hackerfactor1 7y ago
I don't know this attacker's reason. I only see the attack. But I can offer some baseless suspicions: I'm forwarding traffic from Tor to the Internet Archive. During the last French election, someone DoS'ed most of their media outlets. As a result, lots of French people used Tor to access the current news from the Internet Archive's collection. Shortly after that, someone tried to DDoS my onion service. With all of the voting and elections and the impeachment vote coming up, I'm expecting attacks since the Internet Archive stores lots of information that the current administration tried to remove from the Internet. Then again, it could be a "researcher", or just someone seeing if it can be done. Perhaps they will decide what they want to do after their attack succeeds.
- incompatible 7y ago
  Perhaps countries that have already blocked the Internet Archive? But Tor users can already access it through Tor without a hidden service. If the IA itself was DoSed then wouldn't your relay stop working?
  - gruez 7y ago
    random guess: the servers are reached via anycast. if you DDoS from the US, you'll take down access from the US, but not from other regions.
    - oofabz 7y ago
      It's not much of a DDoS if it's from a single country.
      - az656 7y ago
        That’s pretty invalid — I often see large attacks that are almost entirely made up of bots from one country.
        lima 7y ago
        I've even seen 100+ Gbps from a single ASN in a single country.
    - az656 7y ago
      Isn’t the point of anycast to absorb the brunt of the attack? If your traffic is localized, maybe dropping the announcement for that PoP would be useful.
- aasasd 7y ago
  Now we have a mystery of why Frenchmen had to use Tor to read the Internet Archive.

aasasd 7y ago

> many bots will only do one HTTP connection at a time (single threaded) Is it only service admins who do such detective work, or do admins of intermediate nodes also try to filter out bots? I wonder if simple API calls wouldn't get caught in the crossfire.

Ajedi32 7y ago
Intermediate nodes can't see HTTP connections. Tor traffic is encrypted.

bitcoinz 7y ago

Bitcoin full nodes running over Tor can also be attacked similarly? I think yes however not sure and not every full node over Tor follows same configuration

contingencies 7y ago
All crypto services should be run through a decentralized, extra-codebase voting scheme to generate a confidence interval. Mature services like Bitcoin should have multiple clients and client versions available, geographically distributed across a range of networks, frustrating identification and creating an aggregate mechanism for rapidly detecting anomalous output and mitigating unknown attacks. I implemented this ~8 years ago.
- bitcoinz 7y ago
  8 years ago? Can you share any link which has details about the implementation?
  - contingencies 7y ago
    Sorry no, it was internal work at Kraken.
    - bitcoinz 7y ago
      lol

jimbo1qaz 7y ago

The embedded images are ugly because of the downscaling (the URL contains &size=600).

hackerfactor1 7y ago
Fixed.

quotemstr 7y ago

Why do you suppose the Tor project has been so resistant to mitigating this class of attack? In particular, the proposal to require that rendezvous nodes be publicly listed seems sensible to me, and I wasn't immediately able to find any Tor bugs on the subject.

Astarte 7y ago
That's a good question indeed. I don't have an answer but some people got similar results when pointing out some issues internally. Only when publishing those on the mail list where everyone can read it things started to gain some traction. "In April 2018 a Tor core member — the most active Tor Project person on that closed mailing list — made an attempt to initiate a “do not do” relay requirements list to improve and streamline the handling of malicious Tor relay reports. (I’m not mentioning his name since he does not want to be publicly associated with bad-relays handling for safety reasons.) Unfortunately also this attempt failed since no Tor directory authority operator answered. (Tor directory authorities are required to enforce any Tor network wide rules unless it is part of the tor code itself.) Starting with June 2019, after multiple reports about suspicious relays remained with no reaction I stopped sending them to the list. Occasionally I sent some suspicious relay groups to the public tor-talk mailing list instead — which ironically was more fruitful." https://medium.com/@nusenu/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548?source=---------5------------------ https://medium.com/@nusenu/the-growing-problem-of-malicious-... Even more ironical, the very person which reported that issue and similar ones (also on twitter) got his twitter account closed shortly afterwards (see other post on that site). So he has much less audience than before. Coincidence? Tinfoil hattery? Maybe. But certainly fishy.

noident 7y ago

First: it seems like the author has come up with a number of useful custom modifications to the Tor daemon to mitigate common attacks against onion operators. Why not work with the Tor Project to upstream some of the more useful ones, as well as the additional debugging information? Reading past Hacker Factor posts, is it just me, or is there a tone of slight disdain towards the Tor project? Second: >However, there's a second attack. The attacker can run one or more hostile guard nodes. If he can knock me off enough guards, my tor daemon will eventually choose one of his guards. Then he can identify my actual network address and directly attack my server. (This happened to me once.) A guard node is going to get a lot of traffic from both onion services and normal Tor users. How can an evil guard node tell which IP belongs to the author's server? Overall, this is startling to read. History suggests that it is only a matter of time before an onion service gets unmasked by the latest attack on the Tor network.

Operyl 7y ago
If you read his various articles, and even in this article, he mentions that the Tor team is resistant to a lot of his proposed changes.
- noident 7y ago
  I have read the articles, but have not found an explanation or specific examples. It's not as if Tor doesn't care about onion services; they just spent 4 years designing and implementing the v3 onion service protocol.
  - SolarNet 7y ago
    It's pretty obvious when one gets stonewalled for political reasons when attempting to contribute to a project. He doesn't need to provide specific examples or explanations, doing so just makes the issue worse. Often these issues involve specific people and specific intuitions that will be hard to interpret without lots of context. It will put the problem people on the defensive and likely cause some sort of outrage or personal attacks, or other unwanted drama. Being polite yet firm on his own page is the best that can really be done in these situations. It allows the technical problem to be magnified while not focusing on drama.

mirimir 7y ago

Good work! > However, there's a second attack. The attacker can run one or more hostile guard nodes. If he can knock me off enough guards, my tor daemon will eventually choose one of his guards. Then he can identify my actual network address and directly attack my server. (This happened to me once.) I also worry about malicious guards. For local machines, I only hit Tor via nested VPN chains. So even if I'm using a malicious guard, the attacker will just get the IP of the exit VPN server. For onion services, I typically use VMs in dedicated servers. And so I can put at least one VPN-gateway VM between the onion server VM and the Tor guard. You could also get all of the guards from tor's state file, and hard-code them in torrc with EntryNode. That wouldn't prevent an attacker from taking the site offline, but at least they couldn't become your guard.

Operyl 7y ago
Your last point falls flat if they’re already running a public guard though.
- mirimir 7y ago
  Why? It "falls flat" if you're using a malicious guard. But then, you're already screwed, in that case.
  - Operyl 7y ago
    Because they could already be running a node that's indexed and has the guard flag.
Astarte 7y ago
They could still figure out your guard and attack it directly.

matheusmoreira 7y ago

ExcludeExitNodes {br} Why are brazilian IP addresses associated with abuse? Lots of sites refuse to respond to my browser because of this.

adrianN 7y ago
Because a lot of abuse comes from Brazilian IPs. Maybe because people in Brazil have enough money to buy a computer, but not enough money to buy computers that can run the latest versions of Windows?
deoxykev 7y ago
Looks like it primarily comes from two ASN's in Brazil: CLARO S.A. (AS28573) and TELEFÔNICA BRASIL S.A (AS18881). Interestingly, it looks like Brazil is right up there with Russia when it comes to total number of risky ASN's. source: https://www.recordedfuture.com/asn-blocklist-analysis/ https://www.recordedfuture.com/asn-blocklist-analysis/

bureaucrat 7y ago

If you need a location hidden service it’s wise to run your own guard.

noident 7y ago
Wouldn't your onion service uptime become correlated with the guard's uptime? DDoS probes as described in the OP plus some basic monitoring of known onion sites could discover onions paired with single guard nodes. And if I can become certain that the guard node is owned by the onion operator, you're one subpoena away from deanonymization.
- Astarte 7y ago
  >Wouldn't your onion service uptime become correlated with the guard's uptime? Yes. This is happening on a fairly regular basis. ddos against a tor node in most cases is just trying to figure out someones IP address or guard node. If you run a big darknet site dealing with things like drugs, CP, fraud, and you want to stay around for a while you need to run lots of nodes otherwise you will be pwned probably within hours. There is no point in doing that for legal onions sites like facebook because everyone knows their real operators. Now when you run lots of nodes and at the same time a big website on the darknet you are in the perfect position to run traffic correlation attacks yourself. There is some tutorial available which suggests using some deceptive methods to spoil such tracing efforts. For example when website A is going down you also shut down your site. Or when there is a big blackout of AWS US etc
hackerfactor1 7y ago
Running your own guard is stupid unless you open it for the world to use. If you're the only person using the guard, then the guard offers you zero anonymity. And if lots of people use your guard, then make sure it doesn't violate your ISP's terms of service. (Most ISPs have a clause about residential customers not running public services.) Also, have a plan in place for when (not if) you receive legal notices about copyright infringement, child porn distribution, and other acts that could be criminal in your country/city.

Santosh83 7y ago

Interesting related post: https://www.reddit.com/r/encryption/comments/exjk9e/the_majority_of_tor_nodes_are_in_the_14_eyes/ https://www.reddit.com/r/encryption/comments/exjk9e/the_majo...

Santosh83 7y ago

Also is it not weaker from an anonymity standpoint for the tor deamon to choose the same nation for the entire Tor circuit? I just fired up Tor Browser, navigated to the Tor Blog and this is what I get: https://imgur.com/a/j7JZFVl https://imgur.com/a/j7JZFVl

Astarte 7y ago
This has been mentioned on the tor irc several times and also on some other places. No one cared ...

gzer0 7y ago

I think a lot of comments here are forgetting it takes months to be considered a trusted guard node by TOR. Unless you have hundreds of these and a lot of time and patience, and somehow knock off all of the non-malicious guard-nodes + have your "aged" guard nodes set up, this attack will be very difficult to conduct.

Santosh83 7y ago
Which the larger countries do. And the main point of Tor is to evade serious adversaries isn't it? If you're not anonymous from nation states when using Tor, then what will protect whistle-blowers and investigative journalists and dissidents? VPNs can be ordered to turn over data by courts and you can never be sure a "no logs" VPN does what it says. Tor is the only viable alternative and we know it can be at least seriously compromised by the bigger nations.
- azalemeth 7y ago
  What about i2p and Freenet?
  - mirimir 7y ago
    About Freenet, see https://news.ycombinator.com/item?id=22216177 https://news.ycombinator.com/item?id=22216177 I2P was rather like the love child of Freenet and Tor. Like Freenet, it's pure P2P, where all users route traffic for each other. And although there are outproxies to the open Internet, it's mostly about I2P-hosted content. If anything, it's mostly like Tor onion services. It uses a version of Tor's onion routing, called garlic routing. The main difference is that I2P tunnels are unidirectional, whereas Tor tunnels are bidirectional. That will allow for content caching and bundling, but that's not implemented yet. There are reportedly ~10^4 I2P nodes, versus ~2x10^6 Tor users and ~6x10^3 relays. It's been argued that unidirectional tunnels are harder to deanonymize than bidirectional tunnels. But on the other hand, all I2P nodes are readily discoverable by malicious peers, but Tor users are much harder to discover, because Tor clients don't change guards frequently. So bottom line, they arguably provide similar anonymity. Edit: Yes, guards can discover users. But Tor is designed to make it hard for a given guard to see that many users. So you'd need lots of guards. And that's not so easy, because Tor folk are constantly on the lookout for suspicious guards, especially when a bunch show up at the same time.

ur-whale 7y ago

I wonder if Wireguard is dynamic and lightweight enough to be hacked into re-implementing something like tor but that dynamically shuffles data paths in flight ?

mirimir 7y ago
Good point! Actually, that works well enough with OpenVPN. I've managed a crude setup that switches two-hop nested VN chains at 10 minute intervals.[0] I should also have mentioned the Orchid app for Android (and perhaps soon for iOS).[1] It implements dynamic multi-hop routing, and reputation-based route selection. As I understand it, commercial VPNs are providing OpenVPN servers for the network, and I would hope that each hop uses a different provider. Users buy bandwidth with supposedly anonymous Etherium-based cryptocurrency. Orchid may provide privacy and anonymity that's at least comparable to do-it-yourself nested VPN chains, and perhaps comparable to Tor. In that you're distributing information and trust among multiple providers, who are paid anonymously. And it's obviously far less work than nested VPN chains. But as with Tor, there's the downside of trusting a complex system, which you likely won't understand well. There's also the issue that current smartphones are so horribly insecure that using such tools arguably provides merely an illusion of security, privacy and anonymity. 0) https://github.com/mirimir/vpnchains https://github.com/mirimir/vpnchains 1) https://www.orchid.com/ https://www.orchid.com/

mirimir 7y ago

This finally hit the tor-dev list.[0] And Mike Perry's post is somewhat alarming.[1] Some excerpts: > The "Oddly, sometimes the connection would succeed" sentence is a red flag sentence. If you are inclined to be paranoid, there is indeed a way to hide a real attack in what looks like a simple ntohl() bug here. > This "sometimes"connection behavior is often seen in tagging attacks, where the adversary abuses Tor's AES-CTR mode stream-cipher-style properties to XOR a tag at one end of a circuit, and undo that tag only if the other endpoint is present. In this way, only the connections that actually succeed are those that the adversary is certain that they are in both positions in the circuit (to perform Guard discovery, or if they are the Guard relay, to confirm deanonymization). > If you want to hide your tagging attack as what looks like a simple ntohl() bug here, you send your intro2 with the reverse IP address. Then, when your middle node suspects a candidate rend cell (via timing + circuit setup fingerprinting, to have a guess), it can confirm this guess by undoing the tag by XORing the cipherstream with ntohl(ip) XOR ip. > <snip> > Aka a correctly performing rend cell tag hidden in what looks like a very common networking bug. > This cipherstream tagging weakness has had a few proposals to fix, most recently: https://gitweb.torproject.org/torspec.git/tree/proposals/295-relay-crypto-with-adl.txt https://gitweb.torproject.org/torspec.git/tree/proposals/295... > BUT DON'T PANIC: There is also an alternate explanation for the "sometimes succeed" red flag in this particular case, other than a tagging attack. > <snip> > So most likely, this is just a poorly written Tor client, but there still is the possibility that it is an attack cleverly disguised as a poorly written Tor client.. :/ > It may be a good idea for Neal's/our monitoring infrastructure to keep an eye on this behavior too, for this reason, to test for the side channel usage + rend XOR "correction" vs just dumb bug that is sometimes connecting by getting lucky (and thus never properly reverses the rend IP address). If this is indeed just a bug, when these rends do succeed, the IP address should never be correct. > The way to do that would be to build rend circuits using 3rd hops that you (the service operator) control, so that that 3rd hop can check if the rend succeeds because the TLS connection happened to be open (benign behavior) or because the reversed ntohl() got corrected somehow (attack). 0) https://lists.torproject.org/pipermail/tor-dev/2020-February/014146.html https://lists.torproject.org/pipermail/tor-dev/2020-February... 1) https://lists.torproject.org/pipermail/tor-dev/2020-February/014154.html https://lists.torproject.org/pipermail/tor-dev/2020-February...

7y ago