Live data from Hacker News

Proof-of-Work Defense for Onion Services

blog.torproject.org

111–120 of 159 posts

Re: Proof-of-Work Defense for Onion Services

#111

Surely the DDossers will just use some of their botnets for generating the POWs? I don't think I fully understand the scheme. Is the idea that as the attack progressed this would consume more and more of their resources making an attack impractical? Surely in that scenario more and more of the real traffic's resources would be consumed by them having to solve puzzles also, so Tor would in effect be cooperating with t…

> Surely the DDossers will just use some of their botnets for generating the POWs?

It takes much, much, much more (proven) work to DoS a service than it does to use it normally.

Re: Proof-of-Work Defense for Onion Services

#112

Surely the DDossers will just use some of their botnets for generating the POWs? I don't think I fully understand the scheme. Is the idea that as the attack progressed this would consume more and more of their resources making an attack impractical? Surely in that scenario more and more of the real traffic's resources would be consumed by them having to solve puzzles also, so Tor would in effect be cooperating with t…

> Surely the DDossers will just use some of their botnets for generating the POWs? It takes much, much, much more (proven) work to DoS a service than it does to use it normally.

Then that sounds like a very elegant solution in that case.

Re: Proof-of-Work Defense for Onion Services

#113

Earlier quoted context omitted.

And why do we need this assumption exactly?

Proof-of-work uses resources like memory, CPU, hard drive space, and so on for their challenges which just means that the person with the most resources has a disproportionate impact within the system. A botnet owner has more total resources than anyone else so any PoW challenges that a server issues can be easily outsourced to the system. Overall, they will have more leverage from these resources than the number of…

You're trying to solve a straightforward engineering problem with an unfit solution to an ill-defined problem. The solution of sybil problem would not solve the case of coordinated attack by multiple nefarious agents. You can also call this meat botnet owned by master-coordinator. The solution would distinguish this from a normal botnet but in the end your service down in the very same manner and clients gave up most of their privacy for nothing.

Imagine instead the following trivial scheme: instead of burning resources the client would pay to be served in reverse order of payment value. Let's say client is willing to pay 1 cent to be served in the next 10 seconds. The attacker would have to pay more as he have to occupy the whole head of this queue all the time to be successful. Let's say server can process 100 rps - now he's making over a dollar per second, which he can use to scale his serving capacity.

Re: Proof-of-Work Defense for Onion Services

#114

I'm surprised something like this wasn't done sooner, and also haven't read the proposal [0] in enough detail to tell if this will lead to more data affecting the anonymity of users. Should be fine though, since it's tied user-to-service and not stored anywhere. I'm wondering how much this will decrease load on the service being proxied vs the nodes themselves though, I assume it'll have more benefit to services sinc…

> I'm surprised something like this wasn't done sooner, It should have been, but was delayed by people shrieking about oceans boiling.

FWIW, we talked about using things like hashcash to prevent abuse and similar attacks for anonymous remailers back in the early 90s. Talking about it is one thing, actually making the commitment to do it is something else entirely. Given interest in cryptocurrencies there has also been a lot more effort devoted to considering the cost/feature tradeoffs of various PoW mechanisms (and a broader familiarity with the general concept among the target population), so it is possible that we are seeing a happy side-effect of years of cryptocurrency hype.

Re: Proof-of-Work Defense for Onion Services

#115
post #68

Earlier quoted context omitted.

Probably by having enough computers that they can overload the server even if the number of requests coming from each individual computer is relatively low, as a multiple of what a normal user would send – low enough that those computers have enough CPU time to solve the challenges.

From https://github.com/tevador/equix/blob/master/devlog.md > The service would give the request a priority value based on the "difficulty" of the puzzle solution. Seems like single clients could increase the difficulty to higher than what the bot net would do (so it gets priority), and hence get access. Operators of the bot net would probably hard code one value as the difficulty, and it would be lower than what you…

> Operators of the bot net would probably hard code one value as the difficulty

Bad assumption.

Assumptions like these never last. People who say “I don’t have any money” are still valuable to hackers as phishing senders, legitimate social media accounts, residential + non-cloud + regionally convenient IP space, etc. If consuming connection / server resources becomes valuable then botnet controllers will find a way to pay the cost. It’s easy because someone else is paying for the hardware, bandwidth, and power costs.

But the effect of a market of PoW is the same — there is game theory involved in bidding (just like a silent auction). Even if a botnet uses a dynamic priority bid system, the cost increases as the botnet tries to starve the server of resources. The server’s resources are always zero-sum and the bidding will get progressively more expensive until the opportunity cost of the botnet changes behavior.

Re: Proof-of-Work Defense for Onion Services

#116
post #102

I'm wondering if there is a more elegant way to solve sybil attacks here. For example: many CPUs are provisioned with key pairs that are unique to the processor and can be verified with the CA root cert of the issuer (Intel, AMD, etc.) You could tie PoW to successive signing and allow it to be verified in parallel. Then the operation couldn't be parallelized to a botnet as all PoWs would be unique to a CPU. It seems…

If you are suggesting solutions based on immutable hardware keys and certified chain of custody from the manufacturer,I have to ask if you understand what TOR is.

In OP's defence, there might be a fully anonymous way to achieve attestation. Related: https://privacypass.github.io/

Re: Proof-of-Work Defense for Onion Services

#117
post #36

Really interesting! Digging into the proposal [1]: > make it harder for attackers to overload the service with introduction request > We hope that this proposal can help us defend against the script-kiddie attacker and small botnets. Sets expectations: does not counter large botnets. > We hope that this proposal will allow the motivated user to always connect A user who really wants to connect can get through durring…

So now you have the drawbacks of both as well, in that the guy who has the most compute to use as a toaster can DoS everyone else. Plus, PoW is nothing but wasted, needless computation . Computing is not free . Every watt spent doing anything PoW is just that much more intensification of our current climate crisis. As someone with temps of 109 with heat index of 120 coming in the next few days, with all due respect,…

This proposal applies a temporary cost to DoS and DDoS — which itself is already a big waste of power. This proposal has the ability (if it works as planned) to destroy DoS + DDoS as an effective tool against this kind of server. Likely a net positive in terms of power usage.

Remember that this PoW proposal is a market. If the server has unconsumed cycles (eg. Is not saturated), the POW spot price can remain 0. The server only needs to set a PoW price after the server’s resources near saturation. For the same reason auctions end because nobody is willing to pay infinity dollars, clients can forego PoW and can opt to check back in on the server later when costs subside.

Re: Proof-of-Work Defense for Onion Services

#118
post #78
post #73

Earlier quoted context omitted.

It's mainly the fact that Bitcoin mining sets a price floor on electricity prices. It's a buyer of last resort. Without it you'll get negative electricity prices and less investment in renewables. See for example what Ercot has to say about Bitcoin mining: https://www.youtube.com/watch?v=gKnRfDeFgr0

Who needs batteries when you have Bitcoin?

Until you can solve the climate crisis with batteries alone you need other solutions to step-in in the meantime.

Also, batteries don't help when the electricity is in the middle of nowhere and not connected to the grid.

Re: Proof-of-Work Defense for Onion Services

#119
post #65

I'm wondering if there is a more elegant way to solve sybil attacks here. For example: many CPUs are provisioned with key pairs that are unique to the processor and can be verified with the CA root cert of the issuer (Intel, AMD, etc.) You could tie PoW to successive signing and allow it to be verified in parallel. Then the operation couldn't be parallelized to a botnet as all PoWs would be unique to a CPU. It seems…

"Waiting for pair client connection". That'd be something. Interesting thought but I can imagine a range of issues. In the same vein, how about the server would hold a pool of IPs in which the client has to return a proof of port knocking? e.g. here is a token, send that to this IP:port and wait for a unique response I can verify. Call this proof of latency. It would be low CPU, would spread the load across various m…

What does this prove about the client? Just that they have a reasonably fast connection (which in TOR-world can be painful to achieve), not that they aren't part of a botnet.

It allows you to scale your workload, but "just pay for more servers and outscale the attacker" isn't generally an acceptable way to deal with DDOS.

Re: Proof-of-Work Defense for Onion Services

#120
post #64

Really interesting! Digging into the proposal [1]: > make it harder for attackers to overload the service with introduction request > We hope that this proposal can help us defend against the script-kiddie attacker and small botnets. Sets expectations: does not counter large botnets. > We hope that this proposal will allow the motivated user to always connect A user who really wants to connect can get through durring…

I never heard of CPP (client puzzle protocol) before. Interesting stuff. How can 'large botnets' go around this, by causing havok on other ports?

From the spec:

> The large botnet is a serious operation with many thousands of computers organized to do this attack. Assuming 100k medium-range computers, we are talking about an attacker with total access to 200 THz of CPU and 200 TB of RAM. The upfront cost for this attacker is about $36k.

They appear to define it by compute capacity, so I'd expect the attacker can solve harder puzzles than legitimate users would attempt.

Post reply on HN