Support for TLS sockets

[yorickpeterse]

Inko's sockets are just regular sockets, without any built-in support for TLS (as in SSL/TLS, not thread-local storage). Combine that with the lack of built-in support for various ciphers/cryptographic functions, and using encrypted connections is a real challenge.

To make this possible, Inko should provide a TLS stack of some sort which can be used with its non-blocking sockets. As first sight the best option may appear to be using rustls and exposing it through the VM. While this would likely save us time, I'm not a fan of it, for a few reasons:

• Our API would largely be dictated by the API exposed by rustls, and the resulting API may be annoying to use
• We'd increase the number of VM/non-Inko dependencies, and I want to keep those to a minimum
• A TLS stack requires various features/functions/etc we'd likely have to support anyway, such as cryptographic functions. Instead of exposing all that through the VM, I want to write as much in Inko as possible
• We'd likely have to wrap various Rust types in raw pointers and heap allocate them. I'd like to keep this to a minimum, only using it where absolutely necessary

A first step towards this it to identify what exactly we'd need. After that we need to figure out if there's some sort of shared test suite/reference we can use to determine if we're implementing things correctly. The last thing I want to do is implement this wrong.

Related issues:

• https://github.com/inko-lang/inko/issues/574
• https://github.com/inko-lang/inko/issues/573
• https://github.com/inko-lang/inko/issues/572

Related links:

• https://docs.rs/rustls-platform-verifier
• https://docs.rs/rustls/latest/rustls/
• https://docs.rs/rustls/latest/rustls/struct.StreamOwned.html
• https://www.openssl.org/docs/man3.3/man7/ossl-guide-tls-client-non-block.html
• https://github.com/openssl/openssl/blob/master/demos/guide/tls-client-non-block.c

[yorickpeterse]

marked this issue as related to #283

[yorickpeterse]

While the original desire was a pure Inko TLS stack, I'm currently leaning more towards just using OpenSSL 3.x instead. For one, writing such a stack is a massive effort. Second, it will probably be a long time before we can guarantee constant-time operations needed for various crypto bits, potentially opening us up for timing attacks until then.

Using OpenSSL does mean that cross-compilation becomes more of a challenge, whereas a pure Inko stack wouldn't suffer from this.

Of course wrapping rustls is still a promising option, and would probably make cross-compilation a heck of a lot easier.

[yorickpeterse]

Based on https://github.com/rustls/rustls/blob/main/examples/src/bin/simpleclient.rs, I think wrapping rustls shouldn't be too hard. Essentially TLS sockets would need to store three values: a file descriptor to the raw socket, the rustls wrapper reader/writer, and a reference to the rustls connection object.

[yorickpeterse]

https://github.com/fres621/inko-tls/ might prove useful as a reference.

[yorickpeterse]

Per the source code of rustls' Stream type (https://docs.rs/rustls/latest/src/rustls/stream.rs.html#11-17), it seems we can just create a Stream ad-hoc for every TLS read/write, instead of having to keep it around. This means that for a TLS socket we only need to persist a ClientConnection and ClientConfig somewhere.

[yorickpeterse]

Writing an entire TLS stack from scratch is going to be way too much work, and probably isn't a good idea to begin with as Inko has nothing to allow constant-time operations (as needed for correct encryption). As such, we'll start with basing TLS sockets on either OpenSSL or rustls, whichever works best.