summaryrefslogtreecommitdiffhomepage
path: root/HTTP
diff options
context:
space:
mode:
authorJoey Hess <joeyh@joeyh.name>2016-09-13 14:17:41 -0400
committerJoey Hess <joeyh@joeyh.name>2016-09-13 14:17:41 -0400
commit0c6d82c6c6523b7d045e287b907ca5fa7cab8b19 (patch)
treef144e8e4dabb842351e11194736a62b480f29414 /HTTP
parentb1ca9b89e2c0d987b438433b6783b794dc6e9d85 (diff)
downloadkeysafe-0c6d82c6c6523b7d045e287b907ca5fa7cab8b19.tar.gz
Revert "refactor"
Diffstat (limited to 'HTTP')
-rw-r--r--HTTP/RateLimit.hs46
1 files changed, 13 insertions, 33 deletions
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