Fix renegotiation with Client Auth (1.1.0) #1983
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
This was referenced Nov 22, 2016
Closed
The flag SSL_VERIFY_CLIENT_ONCE is documented as follows: B<Server mode:> only request a client certificate on the initial TLS/SSL handshake. Do not ask for a client certificate again in case of a renegotiation. This flag must be used together with SSL_VERIFY_PEER. B<Client mode:> ignored But the implementation actually did nothing. After the server sends its ServerKeyExchange message, the code was checking s->session->peer to see if it is NULL. If it was set then it did not ask for another client certificate. However s->session->peer will only be set in the event of a resumption, but a ServerKeyExchange message is only sent in the event of a full handshake (i.e. no resumption). The documentation suggests that the original intention was for this to have an effect on renegotiation, and resumption doesn't come into it. The fix is to properly check for renegotiation, not whether there is already a client certificate in the session. As far as I can tell this has been broken for a *long* time.
In a non client-auth renegotiation where the original handshake *was* client auth, then the client will send a Certificate message anyway resulting in a connection failure.
In a non client-auth renegotiation where the original handshake *was* client auth, then the server will expect the client to send a Certificate message anyway resulting in a connection failure.
mattcaswell
force-pushed
the
fix-reneg-client-auth-110
branch
from
f6acf8c
to
328dff2
Compare
|
Updated this to have the same reneg test as #1982 for consistency reasons. |
|
Is this still current? |
|
Yes - its still current. |
2 tasks
levitte
approved these changes
Jan 18, 2017
levitte
pushed a commit
that referenced
this pull request
Jan 23, 2017
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #1983)
levitte
pushed a commit
that referenced
this pull request
Jan 23, 2017
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #1983)
levitte
pushed a commit
that referenced
this pull request
Jan 23, 2017
Repeat for various handshake types Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #1983)
levitte
pushed a commit
that referenced
this pull request
Jan 23, 2017
The flag SSL_VERIFY_CLIENT_ONCE is documented as follows: B<Server mode:> only request a client certificate on the initial TLS/SSL handshake. Do not ask for a client certificate again in case of a renegotiation. This flag must be used together with SSL_VERIFY_PEER. B<Client mode:> ignored But the implementation actually did nothing. After the server sends its ServerKeyExchange message, the code was checking s->session->peer to see if it is NULL. If it was set then it did not ask for another client certificate. However s->session->peer will only be set in the event of a resumption, but a ServerKeyExchange message is only sent in the event of a full handshake (i.e. no resumption). The documentation suggests that the original intention was for this to have an effect on renegotiation, and resumption doesn't come into it. The fix is to properly check for renegotiation, not whether there is already a client certificate in the session. As far as I can tell this has been broken for a *long* time. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #1983)
levitte
pushed a commit
that referenced
this pull request
Jan 23, 2017
In a non client-auth renegotiation where the original handshake *was* client auth, then the client will send a Certificate message anyway resulting in a connection failure. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #1983)
levitte
pushed a commit
that referenced
this pull request
Jan 23, 2017
In a non client-auth renegotiation where the original handshake *was* client auth, then the server will expect the client to send a Certificate message anyway resulting in a connection failure. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #1983)
levitte
pushed a commit
that referenced
this pull request
Jan 23, 2017
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from #1983)
|
Pushed. Thanks. |
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.
Checklist
Description of change
#1920 describes a problem where a non-client auth reneg handshake that occurs after a client-auth handshake will end up with the client sending a Certificate message when it is not supposed to.
There is another related bug where, in the same situation, the server expects a Certificate message even when it hasn't requested one!
These two bugs together mean that OpenSSL will happily talk to the same version of itself in this scenario, but nothing else.
In adding tests for this I found a third bug in the implementation of SSL_VERIFY_CLIENT_ONCE. The documentation for this flag says:
But the implementation actually did nothing. After the server sends its
ServerKeyExchange message, the code was checking s->session->peer to see if
it is NULL. If it was set then it did not ask for another client
certificate. However s->session->peer will only be set in the event of a
resumption, but a ServerKeyExchange message is only sent in the event of a
full handshake (i.e. no resumption).
The documentation suggests that the original intention was for this to
have an effect on renegotiation, and resumption doesn't come into it.
The fix is to properly check for renegotiation, not whether there is already
a client certificate in the session.
As far as I can tell this has been broken for a long time. I actually wondered whether we would be better off just removing it. But as it turns out I need to use it for my tests to work so I fixed it anyway!!
I also fixed a bug in TLSProxy where zero length messages weren't being recorded properly.
This is the 1.1.0 version of #1982
Fixes #1920