Server Support

[stevefan1999-personal]

Is it possible to support server one day? Here's a no_std implementation of TLS called SaiTLS but it runs on smoltcp which is not exactly what I needed

[lulf]

I agree, having server support would be great, so thanks for raising the issue! I'm not aware of anyone working on a server implementation right, but I think it should be easy to reuse most of the client implementation for establishing the handshake.

[jonasBoss]

I have been looking into this on https://github.com/jonasBoss/embedded-tls/tree/tls-server and would continue working on this.

But first I would like to get some feedback on my current plan to integrate the server, since this does involve changing a bunch of existing code.

I would separate the implementation into three parts.

1. Change the naming and struct concepts from Client/Server to Local/Remote
   Many things are the same on the server and the client, so a distinction between remote (received) and local (to be sent) data makes much more sense. With this, all the logic for serializing and deserializing can be reused between server and client.
   This involves only renaming stuff. See: 8c77c82, 2934c95, 610c87b
2. Rework the extensions so that they have a local and a remote variant.
   This is probably the most complicated part. Many extension structs, especially the KeyShareClientHello, come with a generic length. Currently the Client-Hello Key-Share is set to 1, which is fine for a client, but as a server, we expect a client to send multiple key shares.
   So I would like to rework the heapless::Vec based extension data to have two variants: a remote variant that is zerocopy and provides an iterator for reading data, and a local variant that stores nothing but provides an associated encode<F: FnOnce(&mut CryptoBuffer)> function for encoding data. This will probably change the macro-based encoding/decoding to a trait-based approach.
   My current implementation idea is this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=21cdee0026be01134998e7a006dfc75b
3. Implement the server. With the previous changes, this can be implemented by the same TlsConnection struct as the client, but with a different open() implementation. So I think it should be rather straightforward.

Please give me some feedback on whether you think this is a workable plan for a server that can be merged into this project.