Don't cache stateless tickets in TLSv1.3 #6293
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In TLSv1.2 and below we always cache new sessions by default on the server side in the internal cache (even when we're using session tickets). This is in order to support resumption from a session id. In TLSv1.3 there is no session id. It is only possible to resume using the ticket. Therefore, in the default case, there is no point in caching the session in the internal store. There is still a reason to call the external cache new session callback because applications may be using the callbacks just to know about when sessions are created (and not necessarily implementing a full cache). If the application also implements the remove session callback then we are forced to also store it in the internal cache so that we can create timeout events. Otherwise the external cache could just fill up indefinitely. This mostly addresses the issue described in openssl#5628. That issue also proposes having an option to not create full stateless tickets when using the internal cache. That aspect hasn't been addressed yet.
mattcaswell
added
branch: master
richsalz
approved these changes
May 18, 2018
richsalz
added
the
approval: done
kaduk
approved these changes
May 18, 2018
|
Won't this change cause the check at https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1154 to always fail? |
No, because we still cache the session if early data is switched on in this PR, i.e. we check the value of |
|
Pushed. Thanks. |
levitte
pushed a commit
that referenced
this pull request
May 21, 2018
In TLSv1.2 and below we always cache new sessions by default on the server side in the internal cache (even when we're using session tickets). This is in order to support resumption from a session id. In TLSv1.3 there is no session id. It is only possible to resume using the ticket. Therefore, in the default case, there is no point in caching the session in the internal store. There is still a reason to call the external cache new session callback because applications may be using the callbacks just to know about when sessions are created (and not necessarily implementing a full cache). If the application also implements the remove session callback then we are forced to also store it in the internal cache so that we can create timeout events. Otherwise the external cache could just fill up indefinitely. This mostly addresses the issue described in #5628. That issue also proposes having an option to not create full stateless tickets when using the internal cache. That aspect hasn't been addressed yet. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from #6293)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In TLSv1.2 and below we always cache new sessions by default on the server
side in the internal cache (even when we're using session tickets). This is
in order to support resumption from a session id.
In TLSv1.3 there is no session id. It is only possible to resume using the
ticket. Therefore, in the default case, there is no point in caching the
session in the internal store.
There is still a reason to call the external cache new session callback
because applications may be using the callbacks just to know about when
sessions are created (and not necessarily implementing a full cache). If
the application also implements the remove session callback then we are
forced to also store it in the internal cache so that we can create
timeout events. Otherwise the external cache could just fill up
indefinitely.
This mostly addresses the issue described in #5628. That issue also proposes
having an option to not create full stateless tickets when using the
internal cache. That aspect hasn't been addressed yet.