/tech/ - Technology

Technology & Computing


New Reply
Name
X
Sage
Subject
Message
Files Max 5 files32MB total
Password
[New Reply]


da17c487ae927ffb34892e5e273fd1207e24063b62f08e7fd584a910fb9b3caa.png (u)
[Hide] (257KB, 474x355)
HAPPENING ALERT
>For a few hours today all v3 onion addresses on the Tor network were down. This appears to be a new kind of attack which affects the entire network and involves overloading the consensus authority nodes.
>You will currently not be able to access any v3 onion addresses, what is happening is unknown, but it is potentially a huge attack on the entire network. Earlier today I made a post outlining consequences I would be putting into place to deter markets from funding DDoS attacks against each other, as the potential to scale and completely kill every node on the network is a very real potential outcome. Now everything is down and I have no idea if this has sped up the process of this occurring or if it is even an attack at all, all I know is, this is big.
>Reddit post by u/hugbunt3r This attack began after Dread forum owner, HugBunter made a post stating the consequences for market owners who continue to attack rival markets.
<—–BEGIN PGP SIGNED MESSAGE—– Hash: SHA512
>The recent/current attacks on multiple markets have been troubling after we’ve all had a good break for some time and things started to heal and become stronger.
>We’ve now had large scale attacks hitting the likes of WHM, DarkMarket and apparently some other services, although I cannot really confirm any others.
>I’d like to outline the main issues with this here. Firstly, /u/Paris and /u/mr_white ‘s work on /d/EndGame has been amazing and has allowed us to all have some really good filtering processes to limit malicious traffic from hitting the application layer and dropping their connections for v3’s where possible. Along with our collective knowledge of the attacks since February 2019, we have some very solid configurations that allow us to scale enough to stay ahead of the attacks and continue scaling alongside it. This is the absolute best protection we as service operators can currently provide and it works, but at many costs.
>We’re not really any closer to seeing a Tor PoW implementation that will seriously improve the situation, but the position we’re in with our own developments is a hell of a lot better than when this all started. There are things I haven’t disclosed publicly because of the potential for abuse, but a lot more worrying things have come from these attacks, costs that aren’t of the monetary kind. The seriousness of the attacks’ will probably become clear at some point. Consequences for Markets
>Consequences for Markets I am aware of at least 2 markets that have paid for attacks against other markets within the last few weeks. I also know of one wishing to pay for retaliation attacks.
>This behavior from market admins is absolutely unacceptable and it will not be tolerated. You have [b]no idea[/b] of the ramifications this has, it is way beyond just taking your competitor offline, inadvertadly, but you are causing a problem that is a great deal worse without even knowing it, if market admins wish me to disclose these other issues to them, they can contact me directly and you will soon rethink your poor business strategy.
>– From here, there will be extreme consequences for any Market admin found to be funding attacks against any other service, market or not. You know who you are and I won’t publicly out you here for it, for the time being.
>Any Ads/other promotional material will be indefinitely disabled You may have your Subdread banned You will be delisted from Recon You will be delisted from DDF Most importantly, your own service will be attacked. This is where it ends, I’m not sitting through another storm of attacks.
<—–BEGIN PGP SIGNATURE—– iQIzBAEBCgAdFiEEYTOs4fS4fFHb8/6l6GEFEPmm6SIFAl/5pNwACgkQ6GEFEPmm 6SIJWA/+M0KfiK5D4T9D3ELwqtAHRBjU8cPqP1yxMYmoZrnZPKO81SuP+fH59xMj XtQn01rIPmRwuLntitf4zGo05LvPWBu8eDErLw4va9yqZtcBVKpP7Jaj+pr8vuRx XgqBA+bdcYpESHs1dzl10HVmeDe2dT7QuuJk63sohw9xf+31wgp9TI2wr8VM48Sv enbO9UUf+dHOajHqmbvNbUOIcf6EPcIUgCA/iedm5WhUfKDOt1AHK4xLYJA7Mmbz 7Y+vCBbPitx0kGMth/xWUsvKWhHeTsv/eSAlsbxmMaVQ4S7zJqJKvHAjxpxT1ZDG lNZqGAH5E4geylibg/mfntJmo4bIg62jQTCT3/kd9Q4ZNWp84Y6FXq55kTTIzrZt ii5Q5wdSIAtUG+mk7gKsPSO2vgvh7TIh8Y6LYg89xvCV1kS9SHC6d2bTiRDqJH7F qo/+qf3ml4jgYqSv4rJIZ7NqmJVGRqQpMMwHxp8zUZyW0ArmE78nTf9I3rRRvaJN OiPnCXDi1i/gK3TrwHOrek4VXhqT+VRBAbUWUPCu1i0IHsfJv3UKgDYLRP2S8x6q A9ed97mTwqNnIKxrXOozvvfE5CJj/N+6Mfu5Q9+3mFNI9FRQtTmoWSpzxrZZdozx nbexW83LKN/b6/zu+KRE/uaabDLg8kvdE/iRiYYAR6gzHlDlHPk= =wZW1 —–END PGP SIGNATURE—–
>An explanation of the attack from Paris, the co-admin of Dread.
>The Tor network is not fully decentralized. When you first connect to the Tor network there is hard coded IPs that your Tor process uses to bootstrap your connection into the Tor network. These IPs allow your Tor process to load up the network’s consensus. This consensus tells the Tor process things like what relays are within the network, which are good relays, bad relays, which are guards, exit nodes, how much traffic a relay can handle, that kind of idea. Your Tor process gets all that information and validates it by signatures of these hard coded IPs. These hard coded IPs are called authority nodes. There is currently 10 of them on the Tor network. And they are why the Tor network cleared out V3 onions for a period of time.
>The authority nodes “vote” on a majority consensus they all share with the Tor network. Generally a new vote happens every hour and the voting process takes 5 minutes. If there is no consensus for three times in a row (as in for three hours) the health the network goes massively down. You can check consensus health at this URL https://consensus-health.torproject.org/. The vote decides a lot of things in the network and when the consensus can’t be succeeded, there is a lot of issues that can occur. Things like V3 Directory variables not being included within a valid consensus so all V3 onions become unreachable.
>The attack basically overloads the authority nodes by sucking up all their bandwidth so the authority nodes can’t communicate between themselves to vote and make a consensus. This fundamentally breaks the network if it goes on too long. This isn’t so new. Like a lot of the Tor attack issues which get exploited in this way there is a closed issue on it.
Replies: >>782 >>1020 >>1104
>>781 (OP) 
https://archive.fo/ZWt4N
Always double archive to the only website that doesn't Cloudcuck you if you happen to be using Tor or a VPN: https://web.archive.org/web/20210111020236/https://darknetdaily.com/?p=1030

That being said, this fuckery is still going on. Onion v2 addresses don't seem to be affected, so some things are still available. Obviously this isn't a solution but just a bandage. What are anons thinking about this? I've seen mentions of blockchain being a potential fit for this consensus network, to make it less vulnerable to bandwidth attacks. But an obvious question would be how the algorithm obscures the number of onions available as well as their addresses. If it is easy to retrieve such information, that defeats the entire point of a v3 address.
Replies: >>792
…why is Tor so centralized that you can nuke all v3 onions by killing 10 servers?
Replies: >>1749
>>784
I don't understand the tech enough to comment what this means or how to solve it, but I'd expect this kind of shit would result in some serious change in how v3 addresses work, because it's unacceptable that this is even possible in the first place.
Replies: >>795
Shrek.png (u)
[Hide] (388.6KB, 420x420)
>>792
>The Tor network is not fully decentralized. When you first connect to the Tor network there is hard coded IPs that your Tor process uses to bootstrap your connection into the Tor network. These IPs allow your Tor process to load up the network’s consensus. This consensus tells the Tor process things like what relays are within the network, which are good relays, bad relays, which are guards, exit nodes, how much traffic a relay can handle, that kind of idea. Your Tor process gets all that information and validates it by signatures of these hard coded IPs. These hard coded IPs are called authority nodes. There is currently 10 of them on the Tor network. And they are why the Tor network cleared out V3 onions for a period of time.
>whoever controls these servers controls Tor
what a meme
Replies: >>796
>>795
I think you're missing the point. You can say that about guard and exit nodes as well, since whoever controls them controls Tor. The consensus either shouldn't be so frequent or archival measures should be in place to prevent onion addresses from being completely down.

Some more information regarding it. Tor developers haven't mentioned anything regarding the trade wars drama OP's article talks about. Rather, they said that someone's custom implementation of the daemon is at fault as it's making requests too aggressively. The silver lining is that this happened before deprecation of v2 addresses. They're supposed to be phased out sometime this year.
Replies: >>816
>>796
the difference is that guard and exit nodes are (I believe) randomized and dynamic, meaning you don't connect to the same one every time so they don't know where you'll come out of. but if there's a point that you have to connect to every single time you use the service, of course they're going to set up shop there.
Replies: >>817
>>816
Guard nodes are CENTRALIZED and NOT dynamic, exit nodes are not.

You connect every-time for months to the same  assigned guard node, I remember reading; for months, and they don't really give out any information really on how to change it saying that it "violates privacy" that you go ahead and change the .torrc file. Which seems like a load of bullshit.

It's really fucking funny to me because the entire point of TOR is that it's not supposed to be centralized at all and that's it's selling point against big zog, big data and big tech. But the criticized guard node poZZ happened in 2015 regardless of what the community who felt it was a bad idea had to say about it.
Replies: >>866
The .onion seems to be working again. Did they find a way to fix it?
>>817
Guard node can be changed, you can request a change in the menus somewhere. It stays the same for a long time with the intent to prevent new pozzed guard node operators easily becoming your new guard node. Guard nodes are all long-running and supposedly "trusted".
Replies: >>868
>>866
Right, the stated intent IIRC was to limit the risk of glowniggers suddenly spinning up a million entry nodes to MitM someone before a blacklist can be made. Of course the fact that it introduces more centralization defeats the purpose of it all the glowniggers can just compromise the privileged nodes. For further reading see The Anti-Technology Revolution: Why and How.
>>781 (OP) 
Are they doing it again or it's just my tor client?
Replies: >>1021 >>1022 >>1024
>>1020
Yep it's happening again. Same thing as last time. v3 dead, v2 working
Replies: >>1024
>>1020
Here's a writeup: https://matt.traudt.xyz/posts/tracking-tors-network-wide-v3-onion-service-outages/
Replies: >>1024
>>1020
>>1021
>>1022
Seemed brief this time. Hopefully it doesn't become a large attack like last time.
>>781 (OP) 
Use I2P, Lokinet or Freenet instead of Tor.
Replies: >>1754
>>791
Tor died when the original silkroad did. It's just government run bullshit.
>>1104
Are there visit-worthy websites on any of these?
Replies: >>1769
>>1754
Do your own research on dark.fail

19 replies | 2 files
Connecting...
Show Post Actions

Actions:

Captcha:

Instructions
- news - rules - faq -
jschan 0.1.5