Skip to content
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

Open
bstrie opened this issue Jun 27, 2022 · 7 comments
Open

Consider TLS support? #1

bstrie opened this issue Jun 27, 2022 · 7 comments

Comments

@bstrie
Copy link

bstrie commented Jun 27, 2022

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?

@ibraheemdev
Copy link
Owner

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.

@dpc
Copy link
Contributor

dpc commented Aug 31, 2023

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.

@ibraheemdev
Copy link
Owner

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

@dpc
Copy link
Contributor

dpc commented Sep 8, 2023

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.

@dpc
Copy link
Contributor

dpc commented Sep 9, 2023

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.

@ibraheemdev
Copy link
Owner

ibraheemdev commented Sep 9, 2023

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.

@ibraheemdev
Copy link
Owner

ibraheemdev commented Sep 9, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants