Make sure we check an incoming reneg ClientHello in DTLS (1.1.0) #5191
Conversation
This file contains hidden or 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 Jan 29, 2018
richsalz
approved these changes
Jan 29, 2018
ssl/record/rec_layer_d1.c
Outdated
Contributor
There was a problem hiding this comment.
side-note: what's the meaning of 4? reneg message len?
Member
Author
There was a problem hiding this comment.
Good question. This is the size of a handshake header message. Probably the 4 here should be SSL3_HM_HEADER_LENGTH. Mind if I change it before I push?
Contributor
There was a problem hiding this comment.
please do. and in the other PR's too, if applicable. reconfirmed.
In TLS we have a check to make sure an incoming reneg ClientHello is acceptable. The equivalent check is missing in the DTLS code. This means that if a client does not signal the ability to handle secure reneg in the initial handshake, then a subsequent reneg handshake should be rejected by the server. In the DTLS case the reneg was being allowed if the the 2nd ClientHello had a renegotiation_info extension. This is incorrect. While incorrect, this does not represent a security issue because if the renegotiation_info extension is present in the second ClientHello it also has to be *correct*. Therefore this will only work if both the client and server believe they are renegotiating, and both know the previous Finished result. This is not the case in an insecure rengotiation attack. I have also tidied up the check in the TLS code and given a better check for determining whether we are renegotiating or not.
ae65fef to
d62ef9e
Compare
Member
Author
|
Grrr. Replacing the magic 4 value (as per above discussion) made me realise that there was a copy&paste error in this code. In TLS the value is |
Contributor
|
:) reconfirm. |
Contributor
|
magic numbers are bad, sometimes for unexpected reasons :) reconfirm. |
Member
Author
|
Pushed. Thanks. |
levitte
pushed a commit
that referenced
this pull request
Jan 30, 2018
In TLS we have a check to make sure an incoming reneg ClientHello is acceptable. The equivalent check is missing in the DTLS code. This means that if a client does not signal the ability to handle secure reneg in the initial handshake, then a subsequent reneg handshake should be rejected by the server. In the DTLS case the reneg was being allowed if the the 2nd ClientHello had a renegotiation_info extension. This is incorrect. While incorrect, this does not represent a security issue because if the renegotiation_info extension is present in the second ClientHello it also has to be *correct*. Therefore this will only work if both the client and server believe they are renegotiating, and both know the previous Finished result. This is not the case in an insecure rengotiation attack. I have also tidied up the check in the TLS code and given a better check for determining whether we are renegotiating or not. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from #5191)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 TLS we have a check to make sure an incoming reneg ClientHello is
acceptable. The equivalent check is missing in the DTLS code. This means
that if a client does not signal the ability to handle secure reneg in the
initial handshake, then a subsequent reneg handshake should be rejected by
the server. In the DTLS case the reneg was being allowed if the the 2nd
ClientHello had a renegotiation_info extension. This is incorrect.
While incorrect, this does not represent a security issue because if
the renegotiation_info extension is present in the second ClientHello it
also has to be correct. Therefore this will only work if both the client
and server believe they are renegotiating, and both know the previous
Finished result. This is not the case in an insecure rengotiation attack.
I have also tidied up the check in the TLS code and given a better check
for determining whether we are renegotiating or not.
This is related to PR #5190, but the same approach used there can't be used in 1.1.0 or below.