Consider TLS support? about astra HOT 7 OPEN

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.

from astra.

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.

from astra.

Oh. Right I keep forgetting that astra is only using hyper logic, but actually doesn't run the executor at all (IIUC).

There seem to be 3 separate decisions involved here:

• using hyper as a mature and well supported http stack (or not, going with something custom like tiny_http does)
• actually using async executor to achieve good network scalability
• not having users suffer writting async code.

Right now the difference between tiny_http and astra seems to be mostly about custom http vs hyper. Other than this both are not driving async executor and downstream user doesn't write async code.

If I was a person that very much cares about minimal dependencies and "trust base", I would probably already go with tiny_http, because of that hyper + tokio "bloat".

In comparison:

~/git/tiny-http(master)$ cargo tree
tiny_http v0.12.0 (/home/casatta/git/tiny-http)
├── ascii v1.1.0
├── chunked_transfer v1.4.1
├── httpdate v1.0.3
└── log v0.4.20

The tiny_http mostly misses a framework around it that would have a better DX. Otherwise it seems in a way like "better astra than astra" (sorry, just thinking aloud and being honest). hyper vs custom http handling code ... seems like a minor detail, especially if you're going minimal anyway.

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.

from astra.

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.

from astra.

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.

from astra.

It would also be useful to expose a rate-limiting API that buffers requests before pushing them to the threadpool.

from astra.

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).

from astra.