Make sure we check an incoming reneg ClientHello in DTLS (1.0.2) #5192
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
2 tasks
richsalz
approved these changes
Jan 29, 2018
Member
Author
|
Same comment here about |
tmshort
reviewed
Jan 29, 2018
ssl/s3_pkt.c
Outdated
Contributor
There was a problem hiding this comment.
This line was originally commented out. Is it necessary for this fix?
Member
Author
There was a problem hiding this comment.
I uncommented it on purpose as I think it is the correct thing to do. We do it in the similar block above dealing with hello retry request. Probably it strictly does not matter because we are not expecting any more handshake messages anyway if reneg is disabled...but relying on that seems fragile.
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.
405b788 to
15a3ddc
Compare
Member
Author
|
Updated to use |
Contributor
|
good catch. 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 #5192)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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. This is the 1.0.2 version of PR #5191.