And here's what brings me to Tor: I'm a "whistleblower," I have information that needs to get to the right people the right way. Tor has been made partly as a whistleblower's tool and yet some reporting tools block us.
Does anyone keep a list of what institutions use Tor and how? Who is using it as designed, where the anonymity revolution is happening and where it isn't?
Maybe i have an idea for users to be safe if an attacker manages to put a torsploit to get the real ip (the case of FH)
Include in the tor bundle a bot who connects randomly to all sensitive onion sites (and clicking randomly on links maybe :) ).
In this case EVERY tor users are going everywhere (blindly) , visiting any onion sites
The attacker can't figure out if a user is going on these sites on purpose or against his willing.
Everybody is guilty = none is guilty.
@TOR Team: On the contrary we are grateful to you for even you can not imagine the no. of people whom we have saved from death when the secretive orders of some politicians at the helm of the affairs were released for their murders just because of few scams they had unearthed. We switched over to TOR (when we by chance met a network engineer working abroad in a flight) and thereafter we feel safe. Thank you for everything which you guys are doing for the preservation of human rights. Thanks to United states and other EU countries who have the best laws in the world. I wish they force every country to use their laws (so far as human rights are concerned). Thank you once again to your team, and all people associated with TOR.
Edward Snowden and the enormous shakeup of surveillance that his whistleblowing set-off, not to mention what is en route?
confident, muckraking journalists like Glenn Greenwald embarrassing the powers-that-be with such eloquence?
the revelation of the extent of surveillance that some suspected, but no one could really confirm, that has shifted opinions on intrusions on internet and related freedoms?
I think the answer is "no" to all those questions. Tor has proven to be a critical building block for all of those points, benefiting both supporters and the detractors of Tor. Whether they admit it or not.
I found this discussion which reveals how Freedom Hosting and Silk Road were busted. Hint: The official story about detective work is a complete ret-con lie. Tor cannot protect hidden services as well as we thought. What's written here makes a lot of sense. Here's the exchange:
You have to wonder how Freedom Hosting and Silk Road's server IPs were both found.
I think all of Tor is FBI/NSA compromised and that they can read all traffic.
Tor routes all traffic via a bunch of intermediary nodes. If LEA owns enough nodes, they would just have to be the node that starts a request and ends a request, to find both your IP and the hidden services' IP:
You (1.2.3.4)->NSA node->other node (maybe NSA, doesn't matter to them)->NSA node->Hidden service (4.3.2.1).
They can then see that communication took place between 1.2.3.4 and 4.3.2.1 and will know that one is the hidden service and the other is an adversary.
This is one way they could have found the IPs of all of the sites they wanted to bust.
The other method is via weaknesses in the webserver software, getting it to give up its real IP, and that's very possible as well. That's the story the NSA wants us to believe took place.
But we just don't know, and I would not touch Tor anymore until the situation is clear.
> You (1.2.3.4)->NSA node->other node (maybe NSA, doesn't matter to them)->NSA node->Hidden service (4.3.2.1).
There are actually 6 nodes between you and a hidden service. Hidden services also use 3 relays And don't forget that communication is encrypted, so nodes along the way can't read it. The NSA nodes can correlate traffic at either end to determine that you are *likely* visiting the hidden service.
Oh yeah, I see now that it's 3 nodes for exit points and 6 nodes for hidden services. Then they'd need to infect 4 of the 6 intermediary nodes in a chain to do such a correlation attack, which is much more difficult.
However, I just came up with a much easier attack:
Let's say that you want to find the IP of hidden service "opva2...onion". All onion addresses are cryptographic keys used for communicating with them. So, your goal is to find a computer that answers to this key. But Tor clients (like a hidden service, or you) will only talk directly to the Tor entry nodes they're using to connect to the network. They won't accept random incoming connections.
Knowing this, here are the steps you'd take:
1. Infect the network with a very large amount of Tor entry nodes under your control.
2. Wait for lots of computers & hidden services to connect to your entry nodes. If, for example, the OPVA server has to re-start and then reconnect to the Tor network, there's a very high chance it will pick your Tor entry node if you own enough of them.
3. Now use all of your Tor entry nodes to send fake packages to every Tor client (all of the hidden services & all clients connected to that bridge). The packages you send out will be encrypted with the "opva2..." public key, which means that the only node that will be able to decrypt and understand that message and reply to it will be the OPVA2 hidden service.
4. When you get a reply from one of your Tor clients, you've conclusively found the hidden service's IP.
I'm not sure this is how they did it, but either way Tor is fucking dead at the moment. We need to be cautious and wait. Maybe the network itself is still pretty safe for end-users, but it's definitely suicide to start new hidden services now. There are several ways that they can find service IPs.
Verrrrry good, Sinner! That's how it's done. Used to be a hidden service was unmaskable in half an hour that way. So Tor was patched to stay with the same 3 guard nodes forever. Later, when the balance got upset, some guards had too many clients, they returned to switching guards but only monthly, not moment-by-moment. Now unmasking takes months, not minutes. Not good for anonymity against a persistent adversary with large resources. Talk among devs is maybe delay the selection of new guards to once every three months. This would only prolong the needed attack time but provides no sure cure.
The attack on the Tor network proceeded unimpeded for some months. It began with breaking into the hidden service directories and harvesting every in-use hidden service address. Then a probe came once per day, about the same time each day. One single probe and that was it. After FH was taken down and half the hidden service addresses disappeared, the probe came earlier each day. Since the probe was no longer predictable, you couldn't have your service down at probe time. Then it became necessary to shut everything down.
And there are sites back up and running!!! That would be unbelievable so clearly the site admin believes he's anonymous when he pays for the service. Probably the server owner doesn't even know a hidden service is being hosted on one of their accounts. I cannot envision any other way for this current situation, with on-topic hidden services still running, to exist. Maybe they don't truly understand the risk, or maybe they don't care about protecting the hoster. The probe is buried in the access logs, but if the site is super busy, who has the time to search them?
Neat! You link to a very interesting PDF which says the same thing as "Sinners" comment but in more academical detail. Basically control the guard nodes and you own the hidden service, just as Sinner said.
"VI. OPPORTUNISTIC DEANONYMISATION OF HIDDEN SERVICES
• Given the onion address of a hidden service with unencrypted list of introduction points determine if her guard nodes are used by this hidden service.
• Determine the IP addresses of those hidden services that use the attacker’s guard nodes.
• Determine if the attacker’s guard nodes are used by any of the hidden services, even if the list of introduction points is encrypted."
Arma: Oh well... Now we wait while the Tor designers try to implement some way of preventing the Entry Guard Nodes from knowing that they are connected to a Hidden Service. It can probably be done, if you can somehow implement a scheme where the hidden service does not announce its hidden service node ID to its entry gateway, and instead just tells it a regular, random client ID. Then, after it's connected to the Tor network, it announces its real hidden service IDs to some random bridge node deeper within the network.
All traffic for that hidden service must then route via that bridge node. That way the hidden services look almost like any other regular-user client node of the Tor network (from the perspective of the entry guard nodes that are connecting them to the network). I say "almost", because they will obviously have far higher traffic and stand out from regular users. But at least the gateway/entry node cannot know for sure which hidden service it is.
In fact... if this sort of "rendezvous" pathing was to be implemented, it would be very beneficial to constantly switch entry nodes/guard nodes *and* your client node ID, so that entry guard nodes would not be able to monitor these high-bandwidth user-traffic patterns for very long, and the ID would also constantly be changing, which makes the hidden service even safer and makes it hard to keep track of who is who.
This might be an improvement, but I am also aware that this just moves the attack to a 2-vector attack, where an adversary must control both the chosen bridge node and the relevant entry node at the exact same time, so that they can snap up the real client-ID via the bridge node, and then correlate that client-ID to the real IP connected to its respective entry guard node. (Or they'd just go to the hidden service directory, look up which bridge node the hidden service resolves to, and then see if any of their entry guard node-users are constantly connected to that bridge node.) But at least with constantly switching the bridge node, entry nodes and client ID, the hidden service will be *safer* than before.
It will also be far slower, if it selects a low-bandwidth bridge node... Entry/Exit nodes are usually high-bandwidth service providers, whereas bridges are more likely to be residential internet connections... So that's something to take into account.
Okay here's a more crystallized version of the idea. Perhaps make entry nodes double-up as hidden service entry nodes, in this manner:
1. The hidden service connects to the network via a randomly chosen entry guard node (which may be evil). It only tells the entry guard node its random client ID, not any of its hidden service IDs.
2. Once it's connected to the network, it picks another random entry guard node and connects to it VIA the Tor network: HS->Entry guard->Bridge->Another entry guard.
3. It tells this 2nd entry guard node to act as the map between "suprscrtservice.onion" and "j23r2hr2h34uhuh" (its random client ID). This means that the 1st entry guard node in the chain is not aware that this mapping is taking place.
4. Now when people want to connect to "suprscrtservice.onion" they resolve it to entry guard #2 and connect to it (client->their entry node->a bridge->entry guard #2). This entry guard #2 in turn then connects back to the hidden service, via a random bridge back to entry guard #1. And entry guard #1 finally connects it to the regular Tor client ID, not knowing that it's handling requests for a hidden service at this very moment, because entry guard #1 only knows about the regular client ID.
5. Constantly, and I mean constantly, break this chain and switch to new entry guard #1's and new Tor client IDs, so that it becomes more difficult for an adversary controlling entry guards to keep track of you.
6. Less frequently, change entry guard #2 as well, but it's not as important.
I'll keep watching the situation. There's lots of room for improvement on Tor.
Does what I'm writing make sense as a possible improvement to think about, or was it all for nothing?
Comments
Please note that the comment area below has been archived.
Thank you for being you. For
Thank you for being you. For many years to come!
Is this a white flag?
Is this a white flag?
No, it is simply exactly
No, it is simply exactly what it says.
Should I scrub my hardrives
Should I scrub my hardrives when you post coded messages like this?
Thanks for working on Tor,
Thanks for working on Tor, everyone.
And here's what brings me to Tor: I'm a "whistleblower," I have information that needs to get to the right people the right way. Tor has been made partly as a whistleblower's tool and yet some reporting tools block us.
Does anyone keep a list of what institutions use Tor and how? Who is using it as designed, where the anonymity revolution is happening and where it isn't?
You might like the
You might like the discussion at the bottom of
https://decvnxytmk.oedi.net/about/torusers
A lot of people who happily use Tor don't want to be highlighted as Tor users.
What's going on here?
What's going on here?
let not forget to thank you
let not forget to thank you and the team too :)
Thanks a lot for your
Thanks a lot for your work
Maybe i have an idea for users to be safe if an attacker manages to put a torsploit to get the real ip (the case of FH)
Include in the tor bundle a bot who connects randomly to all sensitive onion sites (and clicking randomly on links maybe :) ).
In this case EVERY tor users are going everywhere (blindly) , visiting any onion sites
The attacker can't figure out if a user is going on these sites on purpose or against his willing.
Everybody is guilty = none is guilty.
Thank you for your
Thank you for your contributions to the fight against fascism and/or totalitarian 'democracy!'
@TOR Team: On the contrary
@TOR Team: On the contrary we are grateful to you for even you can not imagine the no. of people whom we have saved from death when the secretive orders of some politicians at the helm of the affairs were released for their murders just because of few scams they had unearthed. We switched over to TOR (when we by chance met a network engineer working abroad in a flight) and thereafter we feel safe. Thank you for everything which you guys are doing for the preservation of human rights. Thanks to United states and other EU countries who have the best laws in the world. I wish they force every country to use their laws (so far as human rights are concerned). Thank you once again to your team, and all people associated with TOR.
~Albert Montaro
Thank YOU!!!! Not only have
Thank YOU!!!! Not only have you provided the tools, but you have opened my eyes up to how important and precious individual privacy is!
Without Tor, would we have
Without Tor, would we have had:
I think the answer is "no" to all those questions. Tor has proven to be a critical building block for all of those points, benefiting both supporters and the detractors of Tor. Whether they admit it or not.
Keep up the good work.
I found this discussion
I found this discussion which reveals how Freedom Hosting and Silk Road were busted. Hint: The official story about detective work is a complete ret-con lie. Tor cannot protect hidden services as well as we thought. What's written here makes a lot of sense. Here's the exchange:
----- Sinner@3pp1+a8NbBmh8G488R3CM0iV5Kk ----- 2013.10.11 - 18:42:29GMT -----
Don't use Tor, man.
You have to wonder how Freedom Hosting and Silk Road's server IPs were both found.
I think all of Tor is FBI/NSA compromised and that they can read all traffic.
Tor routes all traffic via a bunch of intermediary nodes. If LEA owns enough nodes, they would just have to be the node that starts a request and ends a request, to find both your IP and the hidden services' IP:
You (1.2.3.4)->NSA node->other node (maybe NSA, doesn't matter to them)->NSA node->Hidden service (4.3.2.1).
They can then see that communication took place between 1.2.3.4 and 4.3.2.1 and will know that one is the hidden service and the other is an adversary.
This is one way they could have found the IPs of all of the sites they wanted to bust.
The other method is via weaknesses in the webserver software, getting it to give up its real IP, and that's very possible as well. That's the story the NSA wants us to believe took place.
But we just don't know, and I would not touch Tor anymore until the situation is clear.
--
*Sinner*
----- moony@FB5nvW5PTcpK_03pkeBMahqq3Us ----- 2013.10.11 - 23:41:30GMT -----
> You (1.2.3.4)->NSA node->other node (maybe NSA, doesn't matter to them)->NSA node->Hidden service (4.3.2.1).
There are actually 6 nodes between you and a hidden service. Hidden services also use 3 relays And don't forget that communication is encrypted, so nodes along the way can't read it. The NSA nodes can correlate traffic at either end to determine that you are *likely* visiting the hidden service.
----- Sinner@3pp1+a8NbBmh8G488R3CM0iV5Kk ----- 2013.10.12 - 04:16:13GMT -----
Oh yeah, I see now that it's 3 nodes for exit points and 6 nodes for hidden services. Then they'd need to infect 4 of the 6 intermediary nodes in a chain to do such a correlation attack, which is much more difficult.
However, I just came up with a much easier attack:
Let's say that you want to find the IP of hidden service "opva2...onion". All onion addresses are cryptographic keys used for communicating with them. So, your goal is to find a computer that answers to this key. But Tor clients (like a hidden service, or you) will only talk directly to the Tor entry nodes they're using to connect to the network. They won't accept random incoming connections.
Knowing this, here are the steps you'd take:
1. Infect the network with a very large amount of Tor entry nodes under your control.
2. Wait for lots of computers & hidden services to connect to your entry nodes. If, for example, the OPVA server has to re-start and then reconnect to the Tor network, there's a very high chance it will pick your Tor entry node if you own enough of them.
3. Now use all of your Tor entry nodes to send fake packages to every Tor client (all of the hidden services & all clients connected to that bridge). The packages you send out will be encrypted with the "opva2..." public key, which means that the only node that will be able to decrypt and understand that message and reply to it will be the OPVA2 hidden service.
4. When you get a reply from one of your Tor clients, you've conclusively found the hidden service's IP.
I'm not sure this is how they did it, but either way Tor is fucking dead at the moment. We need to be cautious and wait. Maybe the network itself is still pretty safe for end-users, but it's definitely suicide to start new hidden services now. There are several ways that they can find service IPs.
--
*Sinner*
----- alt.fan.yardbird@iRUHGZ+v8TOpwKsP+y_FH0AumD8 ----- 2013.10.12 - 04:59:45GMT -----
> I'm not sure this is how they did it
Verrrrry good, Sinner! That's how it's done. Used to be a hidden service was unmaskable in half an hour that way. So Tor was patched to stay with the same 3 guard nodes forever. Later, when the balance got upset, some guards had too many clients, they returned to switching guards but only monthly, not moment-by-moment. Now unmasking takes months, not minutes. Not good for anonymity against a persistent adversary with large resources. Talk among devs is maybe delay the selection of new guards to once every three months. This would only prolong the needed attack time but provides no sure cure.
The attack on the Tor network proceeded unimpeded for some months. It began with breaking into the hidden service directories and harvesting every in-use hidden service address. Then a probe came once per day, about the same time each day. One single probe and that was it. After FH was taken down and half the hidden service addresses disappeared, the probe came earlier each day. Since the probe was no longer predictable, you couldn't have your service down at probe time. Then it became necessary to shut everything down.
And there are sites back up and running!!! That would be unbelievable so clearly the site admin believes he's anonymous when he pays for the service. Probably the server owner doesn't even know a hidden service is being hosted on one of their accounts. I cannot envision any other way for this current situation, with on-topic hidden services still running, to exist. Maybe they don't truly understand the risk, or maybe they don't care about protecting the hoster. The probe is buried in the access logs, but if the site is super busy, who has the time to search them?
Wow, that's a lot of
Wow, that's a lot of words.
See https://vbdvexcmqi.oedi.net/blog/yes-we-know-about-guardian-article#com…
Neat! You link to a very
Neat! You link to a very interesting PDF which says the same thing as "Sinners" comment but in more academical detail. Basically control the guard nodes and you own the hidden service, just as Sinner said.
Nice read: http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf
"VI. OPPORTUNISTIC DEANONYMISATION OF HIDDEN SERVICES
• Given the onion address of a hidden service with unencrypted list of introduction points determine if her guard nodes are used by this hidden service.
• Determine the IP addresses of those hidden services that use the attacker’s guard nodes.
• Determine if the attacker’s guard nodes are used by any of the hidden services, even if the list of introduction points is encrypted."
Exact same thing Sinner said, but in nicer words.
Arma: Oh well... Now we wait
Arma: Oh well... Now we wait while the Tor designers try to implement some way of preventing the Entry Guard Nodes from knowing that they are connected to a Hidden Service. It can probably be done, if you can somehow implement a scheme where the hidden service does not announce its hidden service node ID to its entry gateway, and instead just tells it a regular, random client ID. Then, after it's connected to the Tor network, it announces its real hidden service IDs to some random bridge node deeper within the network.
All traffic for that hidden service must then route via that bridge node. That way the hidden services look almost like any other regular-user client node of the Tor network (from the perspective of the entry guard nodes that are connecting them to the network). I say "almost", because they will obviously have far higher traffic and stand out from regular users. But at least the gateway/entry node cannot know for sure which hidden service it is.
In fact... if this sort of "rendezvous" pathing was to be implemented, it would be very beneficial to constantly switch entry nodes/guard nodes *and* your client node ID, so that entry guard nodes would not be able to monitor these high-bandwidth user-traffic patterns for very long, and the ID would also constantly be changing, which makes the hidden service even safer and makes it hard to keep track of who is who.
This might be an improvement, but I am also aware that this just moves the attack to a 2-vector attack, where an adversary must control both the chosen bridge node and the relevant entry node at the exact same time, so that they can snap up the real client-ID via the bridge node, and then correlate that client-ID to the real IP connected to its respective entry guard node. (Or they'd just go to the hidden service directory, look up which bridge node the hidden service resolves to, and then see if any of their entry guard node-users are constantly connected to that bridge node.) But at least with constantly switching the bridge node, entry nodes and client ID, the hidden service will be *safer* than before.
It will also be far slower, if it selects a low-bandwidth bridge node... Entry/Exit nodes are usually high-bandwidth service providers, whereas bridges are more likely to be residential internet connections... So that's something to take into account.
Okay here's a more crystallized version of the idea. Perhaps make entry nodes double-up as hidden service entry nodes, in this manner:
1. The hidden service connects to the network via a randomly chosen entry guard node (which may be evil). It only tells the entry guard node its random client ID, not any of its hidden service IDs.
2. Once it's connected to the network, it picks another random entry guard node and connects to it VIA the Tor network: HS->Entry guard->Bridge->Another entry guard.
3. It tells this 2nd entry guard node to act as the map between "suprscrtservice.onion" and "j23r2hr2h34uhuh" (its random client ID). This means that the 1st entry guard node in the chain is not aware that this mapping is taking place.
4. Now when people want to connect to "suprscrtservice.onion" they resolve it to entry guard #2 and connect to it (client->their entry node->a bridge->entry guard #2). This entry guard #2 in turn then connects back to the hidden service, via a random bridge back to entry guard #1. And entry guard #1 finally connects it to the regular Tor client ID, not knowing that it's handling requests for a hidden service at this very moment, because entry guard #1 only knows about the regular client ID.
5. Constantly, and I mean constantly, break this chain and switch to new entry guard #1's and new Tor client IDs, so that it becomes more difficult for an adversary controlling entry guards to keep track of you.
6. Less frequently, change entry guard #2 as well, but it's not as important.
I'll keep watching the situation. There's lots of room for improvement on Tor.
Does what I'm writing make sense as a possible improvement to think about, or was it all for nothing?
Love you all! My best to all
Love you all! My best to all Tor Peoples and TAILS Peoples!