Avoid errors with a priori inapplicable protocol bounds (1.1.1 backport) #12507
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
The 'MinProtocol' and 'MaxProtocol' configuration commands now silently ignore TLS protocol version bounds when configurign DTLS-based contexts, and conversely, silently ignore DTLS protocol version bounds when configuring TLS-based contexts. The commands can be repeated to set bounds of both types. The same applies with the corresponding "min_protocol" and "max_protocol" command-line switches, in case some application uses both TLS and DTLS. SSL_CTX instances that are created for a fixed protocol version (e.g. TLSv1_server_method()) also silently ignore version bounds. Previously attempts to apply bounds to these protocol versions would result in an error. Now only the "version-flexible" SSL_CTX instances are subject to limits in configuration files in command-line options. Expected to resolve openssl#12394
vdukhovni
added
branch: 1.1.1
paulidale
approved these changes
Jul 22, 2020
paulidale
added
the
approval: done
mattcaswell
approved these changes
Jul 22, 2020
openssl-machine
pushed a commit
that referenced
this pull request
Jul 22, 2020
The 'MinProtocol' and 'MaxProtocol' configuration commands now silently ignore TLS protocol version bounds when configurign DTLS-based contexts, and conversely, silently ignore DTLS protocol version bounds when configuring TLS-based contexts. The commands can be repeated to set bounds of both types. The same applies with the corresponding "min_protocol" and "max_protocol" command-line switches, in case some application uses both TLS and DTLS. SSL_CTX instances that are created for a fixed protocol version (e.g. TLSv1_server_method()) also silently ignore version bounds. Previously attempts to apply bounds to these protocol versions would result in an error. Now only the "version-flexible" SSL_CTX instances are subject to limits in configuration files in command-line options. Expected to resolve #12394 Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Matt Caswell <matt@openssl.org> GH: #12507
|
Many thanks for the reviews. |
|
Just noting that there should be a 24 hour grace period from approval until pushing :) |
Sorry, I had assumed that passed, but while you approved yesterday, and then Matt approved today, your approval was still less than 24 hours ago when I pushed. I'll endeavour to pay closer attention. I did actually think about that, but jumped the gun anyway it turns out. :-( |
openssl-machine
pushed a commit
that referenced
this pull request
Jul 29, 2020
This commit adds a new test (run on all the built-in curves) to create `EC_GROUP` with **unknown** *explicit parameters*: from a built-in group we create an alternative group from scratch that differs in the generator used. At the `EC_GROUP` layer we perform a basic math check to ensure that the math on the alternative group still makes sense, using comparable results from the origin group. We then create two `EC_KEY` objects on top of this alternative group and run key generation from the `EC_KEY` layer. Then we promote these two `EC_KEY`s to `EVP_PKEY` objects and try to run the derive operation at the highest abstraction layer, comparing results in both directions. Finally, we create provider-native keys using `EVP_PKEY_fromdata` and data derived from the previous objects, we compute an equivalent shared secret from these provider keys, and compare it to the result obtained from the previous steps. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from #12507)
openssl-machine
pushed a commit
that referenced
this pull request
Jul 29, 2020
Minor changes to `custom_generator_test`: - this is to align to the 1.1.1 version of the test (simplify the code as there is no need to use `EC_GROUP_get_field_type()`) - add comment to explain how the buffer size is computed Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from #12507)
swenkeratmicrosoft
pushed a commit
to swenkeratmicrosoft/openssl
that referenced
this pull request
Sep 1, 2020
This commit adds a new test (run on all the built-in curves) to create `EC_GROUP` with **unknown** *explicit parameters*: from a built-in group we create an alternative group from scratch that differs in the generator used. At the `EC_GROUP` layer we perform a basic math check to ensure that the math on the alternative group still makes sense, using comparable results from the origin group. We then create two `EC_KEY` objects on top of this alternative group and run key generation from the `EC_KEY` layer. Then we promote these two `EC_KEY`s to `EVP_PKEY` objects and try to run the derive operation at the highest abstraction layer, comparing results in both directions. Finally, we create provider-native keys using `EVP_PKEY_fromdata` and data derived from the previous objects, we compute an equivalent shared secret from these provider keys, and compare it to the result obtained from the previous steps. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from openssl#12507)
swenkeratmicrosoft
pushed a commit
to swenkeratmicrosoft/openssl
that referenced
this pull request
Sep 1, 2020
Minor changes to `custom_generator_test`: - this is to align to the 1.1.1 version of the test (simplify the code as there is no need to use `EC_GROUP_get_field_type()`) - add comment to explain how the buffer size is computed Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from openssl#12507)
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.
The 'MinProtocol' and 'MaxProtocol' configuration commands now silently
ignore TLS protocol version bounds when configurign DTLS-based contexts,
and conversely, silently ignore DTLS protocol version bounds when
configuring TLS-based contexts. The commands can be repeated to set
bounds of both types. The same applies with the corresponding
"min_protocol" and "max_protocol" command-line switches, in case some
application uses both TLS and DTLS.
SSL_CTX instances that are created for a fixed protocol version (e.g.
TLSv1_server_method()) also silently ignore version bounds. Previously
attempts to apply bounds to these protocol versions would result in an
error. Now only the "version-flexible" SSL_CTX instances are subject to
limits in configuration files in command-line options.
Backport of #12472
Expected to resolve #12394
Checklist