Skip to content
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

Closed
wants to merge 3 commits into from

Conversation

mattcaswell
Copy link
Member

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
  • tests are added or updated

Copy link
Contributor

@kaduk kaduk left a 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))) {
Copy link
Contributor

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.

Copy link
Member Author

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.
@mattcaswell
Copy link
Member Author

New commit pushed addressing @davidben's comment. Also rebased.

@bernd-edlinger and/or @kaduk can you reconfirm?

@mattcaswell
Copy link
Member Author

Pushed. Thanks.

levitte pushed a commit that referenced this pull request Jul 18, 2017
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)
levitte pushed a commit that referenced this pull request Jul 18, 2017
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from #3954)
levitte pushed a commit that referenced this pull request Jul 18, 2017
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants