-
-
Notifications
You must be signed in to change notification settings - Fork 645
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
Redbean SSL support #95
Comments
We can't default to port 80 because it requires root permissions. The flags let you configure certain things like redirects. If you want to request a configuration language please file another issue. SSL we might be able to do but it's very large in scope. Redbean is unsecure. That means it's neither secure or insecure. What it does is it gives you the flexibility to choose to bolt on those added layers of security through accompanying means. For example, you can use a cloud frontend load balancer to reverse proxy requests to your redbean instances. Redbean being designed this way means it can fill the niche of being a tiny simple web server you can run locally to spawn a web app in Chrome. SSL detracts from that appeal. For example, linking BoringSSL would add roughly 50mb of code. So it's not clear to me if this is something we should do. But it's something that would certainly be nice. |
@jart Thanks for clarifying. We can definitely add another reverse proxy for the SSL, but that would slowdown the performance of the redbean. |
It sounds like you have requirements that are different from what redbean was designed to do. Thanks for stopping by. |
I opened #179, which compiles MbedTLS using cosmopolitan libraries and given the size of MbedTLS binaries, it may fit the Redbean philosophy better than some other TLS modules. Not sure how its API is different from something like BoringSSL and how much work it would take to implement it though. |
redbean now has ssl support at head however it hasn't been published to a release binary yet. This turned out to be tinier, faster, more pleasant, and easier to implement than originally anticipated. You can now have formally verified munitions grade cryptography in a single point and click executable file that's scp'able across your heterogeneous infrastructure and clocks in at 300k requests per second on a core i9 w/ ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 X25519 in addition to legacy support reaching back over a decade for old machines on your LAN that you might not necessarily be able to upgrade, running things like IE8 or Java 7. See cc19207 and https://redbean.justine.lol/ which is currently self-signed. |
FWIW...
80
conf
file support.html
. Preferably GitHub pages approaches for handling static files)The text was updated successfully, but these errors were encountered: