Open Moosems opened 8 months ago
This also came up in #28 , I think this is very important to drive adoption more generally.
Added a good first issue
label, contributions very welcome!
Actually now that I think about it, it's not a good first issue
. But still, would welcome any contributions
Hi,
Thanks for creating this lib. I was curious about HTTP libraries in Mojo and came across this one. While going through this issue I realized that other languages have stuff in their standard library that is missing in Mojo to enabled HTTPS.
I tried to figure out how for eg. starlette
does it and it turns out starlette
doesn’t and outsources it to the underlying http server which usually is uvicorn
. And how does uvicorn
do it? It outsources the TLS part to asyncio
which in turns outsources it to the Python SSL library.
I don’t have enough Go understanding, but I think FastHTTP also does the same thing and outsources the TLS part to crypto/TLS.
I feel like to get HTTPS support will require the following steps.
Does that sound like the way to go?
@vikramsg you're completely right, this requires spinning up a separate TLS library at this point. I think it makes sense to keep that one in a different repo/project similar to how it's done in Go or Python like you shared. I've also asked in Modular Discord, Jack confirmed that team doesn't plan to add TLS to the stdlib any time soon and they welcome community contributions there. If you're up for the challenge happy to collaborate on the OpenSSL wrapper library, and of course once that's available happy to start working on adding TLS socket wrapper to Lightbug as soon as possible
@saviorand thanks for the reply.
Yes, I think it makes sense to do a separate repo for this. Do you have some ideas on the scope of what we want. I wouldn't want to try to support all of OpenSSL, just the bits that are required for HTTPS.
@vikramsg what would be nice to have in a hypothetical TLS library are the utilities for wrapping connections/listeners into their "secure" versions that would conduct handshakes/checks when needed. I imagine for that we'll need things like (modeling off of Lightbug's types, although these don't have to match directly); examples are from Go's crypto/tls
:
A crypto
package is in general missing from the Mojo stdlib, so we cannot call things like crypto/aes
, crypto/ecdsa
, crypto/rsa
or crypto/x509
like done here from within Go's crypto/tls
. I've searched for community libraries for this but couldn't find anything we could use.. So also a major gap looks like.
Another challenge of course is keeping such a TLS library general/not tied to TCP/HTTP since TLS can potentially be used to secure any kind of transport format, not just in the form of HTTP. Since not much is implemented in Mojo in terms of other protocols in my opinion we can go easy on the universality part for now.
A basic flow to support would be like something described here https://github.com/denji/golang-tls
@vikramsg thought it might be interesting for you, we're collaborating on a Rustls-FFI based TLS implementation with @thatstoasty and @lsh here https://github.com/thatstoasty/mojo-rustls/ , once it's done I could import it as a dependency into Lightbug and try making an HTTPS client/server
@saviorand thanks for the update. Unfortunately I haven't been able to spend any time on this.
Wish you good luck and looking forward to the implementation.
Is your feature request related to a problem? Please describe. Would be nice to be able to say that a website I made with this is "secure" (the s in HTTPS)
Describe the solution you'd like A way to make HTTPS connections OR HTTP connections
Describe alternatives you've considered Just dealing with the current implementation?