deltachat-core-rust
deltachat-core-rust copied to clipboard
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.