Provide a wasm-compatible Rust TLS implementation

[juntao]

Motivation

The WasmEdge networking socket API provides support for TCP and HTTP connections. But many web services today require HTTPS connections. That means we need to support TLS in WasmEdge. The Rustls crate is the most popular TLS implementation in Rust. However, Rustls is based on the Ring library, which cannot be compiled into WebAssembly.

In WasmEdge, we now support the wasi-crypto spec. That allows us to compile the rust-crypto library into WebAssembly and run on WasmEdge. The goal of this project is to create a Rust TLS implementation based on rust-crypto.

Specification

1. Review and understand the Rustls crate and its use.
2. Review wasi-crypto and the Rust API from rust-crypto.
3. Implement the TLS spec similar to Rustls using wasi-crypto.
4. Implement HTTPS support in WasmEdge based on the new TLS library.

Qualifications

To apply this LFX mentorship, there are some minimum qualifications:

1. Experience with the Rust programming language.
2. Experience with the WebAssembly spec.
3. Familiarity with crypto algos.

Appendix

1. wasi-crypto: https://github.com/WebAssembly/wasi-crypto
2. Rustls: https://github.com/rustls/rustls
3. rust-crypto: https://crates.io/crates/crypto
4. WasmEdge socket API: https://github.com/second-state/wasmedge_wasi_socket
5. WasmEdge HTTP examples: https://wasmedge.org/book/en/dev/rust/networking-nonblocking.html

[TieWay59]

Hello, I feel the third stage, Implementing the TLS Spec, is a huge milestone, and I'd like to begin by reviewing the rustls APIs. To take on this topic, one should get to know both rust-crypto and the TLS spec well.
I'm a SE student who hasn't previously concentrated on the TLS protocol. Any advise on how to become more familiar with this task quickly would be greatly appreciated.😀

[juntao]

@TieWay59 I think one way to do is to fork the Rustls library, find out how Ring is used and swap Ring API calls for Rust Crypto. 😃

[sonder-joker]

Here are some of my insights

Adapt rustls rather than reimplement tls.

TLS protocol is very huge. Reimplementation not only means a lot of work, but also may lack of security. Reuse rustls consider more better.

What is problem in rustls

Rustls highly coupled with Ring. However, many users of rustls want to replace Ring, which mean provide a crypto layer. rustls/rustls#521 talk about it.

Which crypto layer to choose?

May RustCrypto as a middle layer is good. However, it depends on the upstream.

So what we need to do

Abstract a set of cryptographic apis (I hope it's RustCrypto) in Rustls and pull request it upstream, so that upstream can use conditional compilation (provide an option like feature = "wasi-crypto") to choose the encryption backend. Then we provide an Wasi-crypto implementation. So rustls can change from Rustls -> Ring to Rustls -> RustCrypto -> Wasi-crypto.

Main problem

The APIs of ring and rust-crypto and wasi-crypto are very different. For rustls, it fully coupled to ring, It also depend on webpki, we also need to adapt it. For wasi-crypto and rust-crypto, design is very different. Rust-crypto assume you owned resource, but wasi-crypto only let you get resource. We probably also need to pull request RustCrypto.

[TieWay59]

Thank you @juntao & @sonder-joker, after simply going through the rustls code base, I agree that TLS protocol is too huge to reimplementation. I‘ll keep investigate into the code base of RustCrypto , rust-crypto and wasi-crypto spec to find more inspiration.

[sonder-joker]

For those who want to start working here, you can start by abstract traits that coupled with ring and webpki (for ring/webpki relative use feature = "ring" and #[config(ring)] or other, any idea you like). You can also compare your design with rust-crypto.

[TieWay59]

Hi @sonder-joker, here is my progress:

Since rustls have lots of dependence on the ring crate, I investigate all related lines to evaluate the scale of re-implementation and listed them in a table. It's a very verbose result so I keep it in my blog post. (see https://www.yuque.com/tieway59/xopdgg/zmkx5g)

you can start by abstract traits

As per my investigation, there are more structs than traits that need to be replaced. May I ask for further information about "abstract traits", I'm still not clear about it. Do you mean I should first focus on the trait provided by the ring crate?

[juntao]

Hi @TieWay59

I think the idea was to create new layer of abstract API interface (traits) between Ring and Rustls. This way, we can use Ring and Rust Crypto to implement the same API.

However, I also think this is perhaps more work than we can do. I think it is probably a good idea to provide WASI-crypto implementations of the same Rust API Ring provides to Rustls. That requires us to fork Rustls. That's what you want to do, right? Thanks.

[TieWay59]

Thank you @juntao

That requires us to fork Rustls. That's what you want to do, right?

Sorry for my late reply, and yes that's what I tend to build for this task. I wonder if it's reasonable to maintain a fork of Rustls in which we would replace all the Ring API with WASI-crypto implementations?

IMHO, When the upstream Rustls updates, it will be difficult to merge incoming updates. Is it acceptable? What do you think of the practice?

Thanks.

[rektide]

The Rustls crate is the most popular TLS implementation in Rust. However, Rustls is based on the Ring library, which cannot be compiled into WebAssembly.

Im just

why is this true? i dont understand this area in general.

i do see related tickets briansmith/ring#918 that indicate ring is partially working in wasm, but i dont see what keeps it from working totally fine in wasm.

[juntao]

@rektide I would love to see Ring get compiled into wASM. But the issue have been under discussion for 3 years. Do you have insights in its latest development? Thanks!

[ipuustin]

Would be great to see this reviewed: briansmith/ring#1568

[jedisct1]

Ring has been ported to wasm: https://github.com/jedisct1/ring-wasi

But I'd really recommend using BoringSSL instead. It has excellent bindings for Rust.

Or implement a new set of host functions specifically to perform HTTP queries. Maybe a safe, minimal subset of libcurl?

[hydai]

Hi @jedisct1
Thanks for the information.
The current implementation of wasi-crypto in WasmEdge uses OpenSSL. Do you mean using BoringSSL to replace it? Or create a new extension based on BoringSSL, said, wasm-boringssl for this?

[GavBog]

briansmith/ring#918 (comment)

[hydai]

Hi @juntao and @L-jasmine
I think this issue is resolved due to the rustls can be compiled into wasm directly. Closing it.