feat: TLS 1.3 session resumption #6182
Conversation
link2xt
force-pushed
the
link2xt/tls-session-resumption
branch
from
e682833 to
3b2f18f
Compare
link2xt
force-pushed
the
link2xt/tls-session-resumption
branch
from
643a3c6 to
5a315d3
Compare
link2xt
force-pushed
the
link2xt/tls-session-resumption
branch
3 times, most recently
from
270558e to
5227345
Compare
link2xt
force-pushed
the
link2xt/tls-session-resumption
branch
from
5227345 to
53f7fce
Compare
If scheduler is not connected, use `send_msg_sync` to create a dedicated connection and send a single message. This allows easily testing SMTP connection establishment.
link2xt
force-pushed
the
link2xt/tls-session-resumption
branch
from
53f7fce to
c0067f8
Compare
link2xt
changed the title
|
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. |
| chat::send_text_msg(&context, sel_chat.as_ref().unwrap().get_id(), msg).await?; | ||
| if context.is_running().await { | ||
| chat::send_text_msg(&context, sel_chat.as_ref().unwrap().get_id(), msg).await?; | ||
| } else { |
There was a problem hiding this comment.
I'm afraid this can break manual testing of some scenarios, maybe add a separate command?
| .lock() | ||
| .entry((port, alpn.to_string())) | ||
| .or_insert_with(|| { | ||
| // This is the default as of Rustls version 0.23.16, |
There was a problem hiding this comment.
"This" == not to share tickets across different ports/ALPNs?
There was a problem hiding this comment.
In this case I refer to session storage configuration, memory cache with 256 sessions max.
|
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 ( |
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: sfackler/rust-native-tls#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: rustls/rustls#2196
Connection reestablishment can be tested for SMTP using deltachat-repl command
send(sendcommand now establishes a dedicated connection if disconnected) and for IMAP using deltachat-repl commandfetch.To see internal Rustls logs, run with
RUST_LOG=rustls=debug cargo run -p deltachat-repl -- deltachat-db.Configure an account with
setqr dcaccount:...andconfigure.Then instead of connecting select self-chat with
chat 10and send messages withsendor download withfetch.While testing this I discovered that Dovecot on chatmail servers does not support TLS session resumption: deltachat/chatmail#455
Postfix supports TLS session resumption but only issues one ticket when session is not resumed: deltachat/chatmail#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 5sI 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.