From 0c6d82c6c6523b7d045e287b907ca5fa7cab8b19 Mon Sep 17 00:00:00 2001
From: Joey Hess <joeyh@joeyh.name>
Date: Tue, 13 Sep 2016 14:17:41 -0400
Subject: Revert "refactor"

This reverts commit 48ec718a6211a71ae0a796eb1c3a6ea091dc6e14.
---
 HTTP/RateLimit.hs | 46 +++++++++++++---------------------------------
 1 file changed, 13 insertions(+), 33 deletions(-)

(limited to 'HTTP')

diff --git a/HTTP/RateLimit.hs b/HTTP/RateLimit.hs
index 7f142be..d8b3dc1 100644
--- a/HTTP/RateLimit.hs
+++ b/HTTP/RateLimit.hs
@@ -92,43 +92,13 @@ bloomMaxSize = 1000000
 -- period, which is especially useful when retrieving keys that were
 -- split into multiple chunks. However, setting this too high lets clients
 -- cheaply store lots of data on a server that has been idle for a while,
--- which could be an attractive way to abuse keysafe servers for general
--- data storage.
+-- which could be an attractive way to abuse keysafe servers.
 burstSize :: Word64
 burstSize = 4 -- 256 kb immediate storage
 
 -- | Rate that the bucket is filled.
 fillRate :: Word64
-fillRate = 2 * 60 * 1000000 -- 1 token every other minute
-
--- This is a second level rate limiter, that limits the rate that
--- RandomSalts are generated.
---
--- This prevents an attacker flooding requests that cause new random 
--- salts to be assigned, in order to fill up the bloom table and cause
--- salts assigned  to other clients to be rejected.
---
--- Since the bloom filters hold 1 million salts, with a 1 token per second
--- fill rate, the attacker would need to send requests for over 10 hours to
--- force a bloom filter rotation, so would not impact many users.
---
--- This also makes there be a hard upper bound on the number of requests
--- per second. In a sitation where an attacker is willing to burn as much
--- CPU as necessary to do proof of work and fill up a keysafe server,
--- this is 
-overallRateLimit :: RateLimiter -> IO ()
-overallRateLimit ratelimiter = tokenBucketWait
-	(randomSaltGenerationLimiter ratelimiter)
-	overallBurstSize
-	overallFillRate
-
--- | This can be quite high; being able to generate a few thousand
--- RandomSalts is not useful to an attacker.
-overallBurstSize :: Word64
-overallBurstSize = 1000
-
-overallFillRate :: Word64
-overallFillRate = 1000000 -- refill 1 token per second
+fillRate = 2 * 60 * 1000000 -- 1 token ever other minute
 
 -- | How much data could be stored, in bytes per second, assuming all
 -- buckets in the rate limiter are kept drained, and all requests are
@@ -192,7 +162,17 @@ assignWork :: RateLimiter -> [Bucket] -> Handler (POWGuarded a)
 assignWork ratelimiter bs = case mapMaybe mkProofReq bs of
 	[] -> throwError err404
 	(mkreq:_) -> liftIO $ do
-		overallRateLimit ratelimiter
+		-- This prevents an attacker flooding requests that 
+		-- cause new random salts to be assigned, in order 
+		-- to fill up the bloom table and cause salts assigned 
+		-- to other clients to be rejected.
+		-- Since the bloom filters hold 1 million salts,
+		-- the attacker would need to send requests for over 10
+		-- hours to force a bloom filter rotation, so would not
+		-- impact many users.
+		tokenBucketWait (randomSaltGenerationLimiter ratelimiter)
+			100 -- burst
+			100000 -- refill 1 token per second
 
 		salt <- liftIO mkRandomSalt
 		withBloomFilter ratelimiter assignedRandomSalts
-- 
cgit v1.2.3