[TLS 1.3] Support Session Resumption for TLS Server

[reneme]

Pull Request Dependencies

• [TLS 1.3] Basic Server Implementation #3053
• [TLS 1.3] Prepare for Session Consolidation #3244
• [TLS 1.3] Consolidate the Session Manager #3150

Description

This adds facilities for PSK-based session resumption to the TLS 1.3 server implementation. The resumption mechanism of TLS 1.3 differs substantially from previous protocol versions: Therefore, this required changes in the Session_Manager API that can be found in #3150.

New Public API

TLS::Server::send_new_session_tickets(const size_t tickets)

When called on TLS 1.3 server channel that finished its handshake, this sends "tickets" NewSessionTicket messages to the peer. Note that applications may call this at any time after the handshake was completed and as often as they need (up to 2^16 times -- then the ticket nonce depletes).
On any other channel object (i.e. TLS 1.2 server), this throws.

TLS::Server::new_session_ticket_supported()

Returns false if the channel object is not capable of TLS 1.3 session tickets (e.g. because it is a TLS 1.2 server or the TLS 1.3 client did not advertise support for any PSK key exchange mode). If ::send_new_session_ticket() would likely succeed, this will return true.

TLS::Policy::new_session_tickets_upon_handshake_success()

Once a TLS 1.3 server successfully established a TLS connection with a compatible client, it will automatically send as many session tickets as defined by this policy. This is a convenience function to enable session resumption support without the using application needing to call ::send_new_session_ticket(). By default the TLS 1.2 implementation offers session resumption, so this returns 1 by default: I.e. clients will receive a single session ticket after a successful handshake.

[codecov-commenter]

Codecov Report

Patch coverage: 87.06% and project coverage change: +0.02 🎉

Comparison is base (67b8651) 88.04% compared to head (40d3747) 88.07%.

❗ Current head 40d3747 differs from pull request most recent head 44ba343. Consider uploading reports for the commit 44ba343 to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3140      +/-   ##
==========================================
+ Coverage   88.04%   88.07%   +0.02%     
==========================================
  Files         615      601      -14     
  Lines       69740    67366    -2374     
  Branches     6913     6737     -176     
==========================================
- Hits        61405    59333    -2072     
+ Misses       5443     5200     -243     
+ Partials     2892     2833      -59     

Impacted Files	Coverage Δ
src/lib/tls/tls12/tls_channel_impl_12.cpp	79.93% <0.00%> (-0.69%)	⬇️
src/lib/tls/tls13/tls_transcript_hash_13.cpp	94.04% <0.00%> (-0.21%)	⬇️
...c/lib/tls/sessions_sql/tls_session_manager_sql.cpp	57.28% <23.52%> (-17.91%)	⬇️
src/lib/tls/msg_client_hello.cpp	79.13% <40.00%> (+1.32%)	⬆️
src/lib/tls/tls_server.cpp	75.92% <50.00%> (-2.08%)	⬇️
src/lib/tls/tls_session_manager.cpp	57.14% <57.14%> (-37.69%)	⬇️
src/lib/tls/msg_server_hello.cpp	82.51% <75.00%> (+0.66%)	⬆️
src/tests/test_tls_cipher_state.cpp	99.31% <84.61%> (-0.69%)	⬇️
src/lib/tls/msg_session_ticket.cpp	85.00% <85.18%> (+5.51%)	⬆️
src/lib/tls/tls_session_manager_memory.cpp	77.77% <88.23%> (-4.99%)	⬇️
... and 319 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[randombit]

Approving - just reviewed the last few commits here.

[randombit]

Your outline for a new session manager interface seems a better match with the realities of how TLS 1.3 does session management. I'm guessing here but it feels like having the implementation notify the session manager that a session was used is a more flexible approach with regards to policy. It also enables LRU style cache pruning.

We may also want to rethink what facilities are offered by the session manager base class itself. In particular right now we do offer out of the box encryption for SQL session managers derived from Session_Manager_SQL which seems to me a nice convenience, but if someone need to write say a flatfile session manager they would have to completely reinvent this.

[reneme]

Re: Session Management revamp

My central idea is to give the Session_Manager more control over the session handling. Particularly, it should be in charge of the Session_ID and Session_Ticket. Hopefully we'll be able to strike a good balance with user convenience, reusability and expected technical understanding to implement application-specific session managers. Providing low-level building blocks (and some safe guards) to facilitate custom implementations is certainly in line with what I have in mind.

I'm currently putting together a working prototype that (roughly) follows the interface I sketched above. Once that is remotely presentable, I'll open a draft PR. Hopefully this will still happen this year. 🤡

[reneme]

This should be fixed in a follow-up PR. It seems to be an issue in the selection of signature schemes with client auth (?). The test was not enabled before, as it required session resumption

[reneme]

Note: Lets move the Session_Manager discussion over to #3150.

[reneme]

This is now rebased (finally) onto the Session_Manager overhaul and also the various recent enum-class changes. The new API integrated nicely and this should converge soon. Still, I expect some CI breakage (nope) and will do another round of self-review and clean-ups (done).

Nevertheless, this PR chain (#3244, #3150 and #3140) comes together and should be ready for review. Some refactorings or prep-work could probably be moved from here down to #3244 though I'm a bit unsure whether this is worth the head ache.

Also I'd like to have another look at the BoGo tests. Maybe we could enable a few more.

The base branch was changed.

[reneme]

Rebased after enum changes prevented a clean merge. Ready for review after #3150 is merged.

[reneme]

Rebased to master, after #3150 was merged.

[reneme]

Rebased yet again after #3323 caused a conflict. Also fixed the last bogo test for this PR.