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

HTTPS Support #20

Open
Moosems opened this issue Mar 29, 2024 · 9 comments
Open

HTTPS Support #20

Moosems opened this issue Mar 29, 2024 · 9 comments
Labels
enhancement New feature or request

Comments

@Moosems
Copy link
Contributor

Moosems commented Mar 29, 2024

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?

@saviorand saviorand added the good first issue Good for newcomers label Apr 14, 2024
@saviorand
Copy link
Collaborator

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!

@saviorand saviorand added enhancement New feature or request and removed good first issue Good for newcomers labels May 28, 2024
@saviorand
Copy link
Collaborator

Actually now that I think about it, it's not a good first issue. But still, would welcome any contributions

@vikramsg
Copy link

vikramsg commented Jul 14, 2024

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.

  1. Wrap OpenSSL or create SSL from scratch.
  2. Wrap socket connections with SSL which will handle the TLS handshake process etc.

Does that sound like the way to go?

@saviorand
Copy link
Collaborator

@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

@vikramsg
Copy link

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

@saviorand
Copy link
Collaborator

@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:

  1. A config struct at a minimum just holding one or more certificates and maybe authorities, although we can use host's root authority set for now. Some parsing primitives e.g. for parsing an X509 keypair, so we can load it from a file
  2. A listener and a server with handshake functions for a client and a server
  3. A connection that can e.g. hold handshake data and has methods for read, write and also does things like encrypt/decrypt.

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.

@saviorand
Copy link
Collaborator

A basic flow to support would be like something described here https://github.com/denji/golang-tls

@saviorand
Copy link
Collaborator

@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

@vikramsg
Copy link

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

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

No branches or pull requests

3 participants