-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix SSL_clear() for TLSv1.3 #3954
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't wait for SSL_clear() to be gone...
I guess this does rely on the session machinery for us to enforce that session reuse does retain the TLS version of the previous session, but that is probably okay.
SSL_clear() does not reset the SSL_METHOD if a session already exists in the SSL object. However, TLSv1.3 does not have an externally visible version fixed method (only an internal one). The state machine assumes that we are always starting from a version flexible method for TLSv1.3. The simplest solution is to just fix SSL_clear() to always reset the method if it is using the internal TLSv1.3 version fixed method.
ssl/ssl_lib.c
Outdated
&& (s->method != s->ctx->method)) { | ||
if (s->method != s->ctx->method | ||
&& (SSL_IS_TLS13(s) | ||
|| (!ossl_statem_get_in_handshake(s) && s->session == NULL))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can remove this condition altogether and just do the s->method != s->ctx->method
. The session-id mess as a remnant of SSL_set_session
locking you to that version. The check exists so you do not accidentally undo the behavior remove here:
ccae4a1#diff-1d72223f932d41f617c50222791649ec
But since that behavior is removed, SSL_clear
should follow suit and not special-case session behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah! Nice! Thanks @davidben
We now allow a different protocol version when reusing a session so we can unconditionally reset the SSL_METHOD if it has changed.
d11f8a3
to
cdeec89
Compare
New commit pushed addressing @davidben's comment. Also rebased. @bernd-edlinger and/or @kaduk can you reconfirm? |
Pushed. Thanks. |
SSL_clear() does not reset the SSL_METHOD if a session already exists in the SSL object. However, TLSv1.3 does not have an externally visible version fixed method (only an internal one). The state machine assumes that we are always starting from a version flexible method for TLSv1.3. The simplest solution is to just fix SSL_clear() to always reset the method if it is using the internal TLSv1.3 version fixed method. Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from #3954)
Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from #3954)
We now allow a different protocol version when reusing a session so we can unconditionally reset the SSL_METHOD if it has changed. Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from #3954)
SSL_clear() does not reset the SSL_METHOD if a session already exists in
the SSL object. However, TLSv1.3 does not have an externally visible
version fixed method (only an internal one). The state machine assumes
that we are always starting from a version flexible method for TLSv1.3.
The simplest solution is to just fix SSL_clear() to always reset the method
if it is using the internal TLSv1.3 version fixed method.
[Aside: SSL_clear() is a horrendous abomination that should be deprecated at some point in the future]
Checklist