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:

• Implement ChaCha20-Poly1305 and XChaCha20-Poly1305 #574
• Implement AES in Inko #573
• Implement X.509 in Inko #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
• https://github.com/ThomasMertes/seed7/blob/master/lib/tls.s7i
• https://github.com/rustls/rustls-ffi

TODO:

• Basic setup using rustls
• Add std.base64, needed to parse PEM files
• Add std.crypto.pem for parsing PEM files
• Add std.crypto.x509 for defining basic certificate and private key types. For the time being these are just wrappers around a ByteArray
• Change std.net.tls such that ClientConfig and ServerConfig accept Certificate and PrivateKey types instead of file paths, such that you can provide these from memory. The actual validation/parsing of the underlying data is still done by rustls

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

[yorickpeterse]

Dumping some OpenSSL related resources:

• Thread Local Storage Leak in openSSL 1.1.0b openssl/openssl#3033
• https://codereview.stackexchange.com/questions/108600/complete-async-openssl-example
• https://stackoverflow.com/questions/18179128/how-to-manage-the-error-queue-in-openssl-ssl-get-error-and-err-get-error
• https://stackoverflow.com/questions/37980798/openssl-error-handling
• Is it recommended/best practice to call ERR_clear_error before SSL_read SSL_write et al? openssl/openssl#23025
• Getting to zero global mutable state long-term openssl/openssl#23451
• https://hynek.me/articles/apple-openssl-verification-surprises/

[yorickpeterse]

Regarding splitting libraries, I think that might actually make things worse: Rust doesn't have a stable ABI, so the separate TLS crate producing libinkotls.a would have to include the standard library as well. The result is that we end up linking with two .a libraries both including the exact same standard library code, resulting in an executable that's actually larger than when using a single library.

[yorickpeterse]

It seems Rustls is doing some blocking IO under the hoods, which could mess up the scheduler/performance:

• Asynchronous calls to user-provided code rustls/rustls#850
  • SecureSocket handshake can stall the main thread for long time dart-lang/sdk#41519 (comment)
• Handling behaviors implemented in platform verifier rustls/rustls-native-certs#25 (comment)
• crypto/x509: use platform verifier on Windows, macOS and iOS golang/go#46287

edit: to clarify, Rustls itself doesn't perform the blocking IO, but the underlying OS-specific routines used to verify certificates might.

[yorickpeterse]

To add to the above: this affects macOS and Windows, as both Linux and FreeBSD have a rather straightforward system that doesn't involve expensive IO calls under the hoods.

How a few languages handle this differs (here "OpenSSL" as the technique means it uses/mimics OpenSSL behaviour):

Language	Technique
Node.js	🔴 OpenSSL
Go	🟢 System
Ruby	🔴 OpenSSL (as far as I can tell)
Python	🔴 OpenSSL, with a manual workaround
Deno	🟢 System, using this crate and this crate
Java	🟡 System, provided this is explicitly enabled, not sure about the default

Based on this (and assuming this pattern holds for other languages), it seems a little inconsistent as to what approach is used.

[yorickpeterse]

The choices come down to the following:

• rustls-platform-verifier: does what users might expect on macOS and Windows, but potentially slow down certificate validation depending on the underlying IO work done. This in turn can degrade application performance (example)
• rustls-native-certs able to load the certificates from the system root, but does its own validation. This should result in consistent performance, but may result in surprising validation results (i.e. a certificate still being treated as valid when it has in fact been revoked, requiring a restart)

I'm not sure yet which option would be better.

[yorickpeterse]

Per rustls/rustls-native-certs#30, it seems that if we use rustls-native-certs then loading the certificates (which happens when creating a client config) could potentially take a long time.

[yorickpeterse]

I'm inclined to just stick with rustls-platform-verifier, as the (potential) performance implications only apply on macOS, and even then it's not clear how likely they are to happen.

What we could do is fork the project and modify the code that does the verification such that it's wrapped in a Process::blocking call. This way any delays introduced by it won't hog an entire OS thread. The challenge here is that we have to somehow inject the current process into that code, preferably without the use of thread-locals.

[yorickpeterse]

I ended up with vendoring and patching rustls-platform-verifier, such that it handles potentially blocking calls on macOS. It's not great that we have to vendor and patch things, but it seems to be the only working approach at this stage. Some additional details are found in this comment.