-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider TLS support? #1
Comments
Synchronous I/O makes the server susceptible to certain types of attacks, which is makes putting it behind an async reverse proxy is pretty important. Maybe for your case that isn't as much of an issue, but considering that I'm not sure built-in TLS is a good idea. |
It wouldn't hurt to put it behind a feature flag, and would make this project more useful, hopefully increasing number of people that can help maintain it. |
The other option that was suggested is driving the hyper connections asynchronously, and only running user code on the blocking pool. That way we can offer TLS while avoiding the need for a reverse proxy (as it's essentially built-in). |
Oh. Right I keep forgetting that There seem to be 3 separate decisions involved here:
Right now the difference between If I was a person that very much cares about minimal dependencies and "trust base", I would probably already go with In comparison:
The If astra was to run the executor it could become "don't sacrifice almost any benefit of async IO, without having to deal with any of its problems". Which is appealing to me at least. The price, I guess would be some extra bloat... I mean code, that it would probably pull from tokio, which is already a dependency anyway through hyper. |
Actually, after looking a bit more into how the polling is handled (mio), maybe what astra is doing currently is perfectly sufficient. BTW. Isn't Slowloris conquered by just having a total timeout on each connection, proportional to the size of the response? If peer is unable to consume the response on time, well sucks to be them. The whole thing could also be dynamically adjusted. Timeouts would get more aggressive as the number of workers in use increases. If it's just a handfull of connections done by time travelers from the past using a dialup modem, fine, the server can keep sending things slowly. But if it looks like we're running short on workers, too bad, it might be an attack. That can be combined with built in per-IP connection limiting of some kind, to at least require distributed attack to even make an attempt of DoS. |
Slowloris attacks can also be performed by sending in a large number of partial requests, slowly sending in the headers, or the body. Hyper doesn't currently expose many internal timeout settings, but we can at least set read/write and overall connection timeouts, and a http1 header timeout. |
It would also be useful to expose a rate-limiting API that buffers requests before pushing them to the threadpool. |
This project looks very interesting; I'm writing a CLI app that needs to serve one single request (for OAuth), and in principle I'd like to avoid having to spin up Tokio and go full async just for that, and Astra fits the bill. But of course I must have TLS, and whereas for a normal server I'd just use a reverse proxy I can't do that here. Would you be willing to offer built-in TLS?
The text was updated successfully, but these errors were encountered: