-
Hi! I'm mostly just curious (we will use it behind another trusted L7 proxy), but is workerd intended to be able to serve as an "edge" ingress proxy where it is taking traffic from untrusted clients? For what it's worth, I did a brief assessment on one class of misbehaviors, using slowhttptest, which can run "slow" dos attacks, e.g. slowloris (neverending http headers), slow POST (neverending body), etc. As far as I can tell, slowloris is mitigated (seems there is a fixed 15s timeout on receiving all the headers somewhere, though I wasn't able to find it, looking briefly), and it is possible to implement mitigations against body attacks by timing out stream operations in JavaScript, though there's no direct support from workerd in this regard; there is some warning/error output when you stop reading a Request body stream and return a Response, but it didn't seem to result in any actual server degradation. Regardless of what the answer is, it may be worth clearly stating it in the README or somewhere else in the documentation. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
Yes, workerd is intended to be able to handle malicious direct clients. That said, in Cloudflare's production usage, it does not do so -- workerd sits behind Cloudflare's usual proxy stack which is probably more hardened. workerd's HTTP implementation comes from KJ, a library bundled with Cap'n Proto, which I personally wrote. It is admittedly not widely used outside of Cloudflare Workers. workerd uses an event-driven architecture where the resources allocated to each connection are fairly minimal, so it should have no problem with "slow loris" attacks. That said, the application must play a part in this too: if the application allocates a large amount of state before fully reading the request body, this could lead to a vulnerability. In production on Cloudflare Workers, our usual proxy stack (outside of workerd) buffers requests and does not deliver them until the entire body is received; workerd itself does not implement any such mitigation and leaves it up to the app or a reverse proxy. Returning a repsonse without reading a whole request should work fine. There is code in KJ that will attempt to read and discard the rest of the request in order to allow connection reuse, but it applies both a time limit and a byte limit to this. |
Beta Was this translation helpful? Give feedback.
Yes, workerd is intended to be able to handle malicious direct clients. That said, in Cloudflare's production usage, it does not do so -- workerd sits behind Cloudflare's usual proxy stack which is probably more hardened. workerd's HTTP implementation comes from KJ, a library bundled with Cap'n Proto, which I personally wrote. It is admittedly not widely used outside of Cloudflare Workers.
workerd uses an event-driven architecture where the resources allocated to each connection are fairly minimal, so it should have no problem with "slow loris" attacks. That said, the application must play a part in this too: if the application allocates a large amount of state before fully reading the re…