chatmail
feat: TLS 1.3 session resumption
This PR enables TLS 1.3 session resumption on the client for Rustls connections. For native-tls there is no support for session resumption, but it is only used for connections without strict TLS: https://github.com/sfackler/rust-native-tls/issues/308
Only TLS 1.3 session resumption is supported, TLS 1.2 is out of scope. It has worse security than TLS 1.3 mechanisms so not worth increasing attack surface as commented in the code.
Session storage is separated by port and ALPN because Rustls itself only separates by hostname: https://github.com/rustls/rustls/issues/2196
Connection reestablishment can be tested for SMTP using deltachat-repl command send (send command now establishes a dedicated connection if disconnected) and for IMAP using deltachat-repl command fetch.
To see internal Rustls logs, run with RUST_LOG=rustls=debug cargo run -p deltachat-repl -- deltachat-db.
Configure an account with setqr dcaccount:... and configure.
Then instead of connecting select self-chat with chat 10 and send messages with send or download with fetch.
While testing this I discovered that Dovecot on chatmail servers does not support TLS session resumption: https://github.com/deltachat/chatmail/issues/455 Postfix supports TLS session resumption but only issues one ticket when session is not resumed: https://github.com/deltachat/chatmail/issues/456
Because of this, with chatmail server I only managed to test Postfix. However, I did not see expected 1 RTT reduction that should happen in theory.
Even with artificial delay tc qdisc del dev <device> root netem delay 5s I did not see the diffierence between resumed and not resumed connection.
No idea why connection time is not reduced, maybe has to do with IMAP and SMTP starting using the server banner rather than contact request like in HTTP(S) or initial TCP window is too low.
Actually looking at the TLS 1.3 handshake, I don't see how session resumption can reduce latency for IMAP and SMTP. The server is the first to talk in these protocols and it can always send the banner together with the Server Hello even if session resumption is not used. 0-RTT is useless for IMAP and SMTP unless we pretend that we already received the banner and send the first command in early data.
So we gain some reduction in data transferred because we no longer need to send server certificate if session is resumed, but that is only visible for bandwidth-limited connections. And cut some CPU load, but this is only interesting for server with a lot of client constantly reconnecting.
I now think session storage should also be separate per-context. It is not a good idea to have multiple profiles that you want to keep separate inside a single Delta Chat application, but users might still do this. It is even possible to use Tor circuit isolation already by configuring separate usernames (IsolateSOCKSAuth) for SOCKS5 proxy and reusing TLS session across circuits makes it possible to link such accounts.
I moved CLI commit used for measurement into a separate PR https://github.com/chatmail/core/pull/7310, so the rest can be merged already.