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

Add OpenSSL::SSL::Context#security_level #9831

Merged
merged 2 commits into from
Oct 23, 2020

Conversation

bcardiff
Copy link
Member

On some up to date configurations the ciphers different ciphers lists will not accept tls 1.0 and tls 1.2 connections.

This is because on some platforms the default security level is 2 instead of 1.

This PR exposes OpenSSL::SSL::Context#security_level / OpenSSL::SSL::Context#security_level= so there is no need to change the global system setting.

Ref:

cc: @carlhoerberg

{% if compare_versions(LibSSL::OPENSSL_VERSION, "1.1.0") >= 0 %}
LibSSL.ssl_ctx_get_security_level(@handle)
{% else %}
raise "SSL_CTX_get_security_level not supported"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT of using a macro raise here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to silently ignore with a nop. That's for sure.

I thought that we were on the side of always exposing the same API, despite library versions compiled. If we do a macro raise that is effectively a different API, isn't?

In the recent #cipher_suites= method this is the same situation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, didn't catch it over there :(

Well, I'm not sure how useful a consistent API is if in some environments the compiled binary will just always crash. That's the same as not being able to compile at all right?

So by that standard it would need to print a big fat warning instead of raise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't always crash. This call might happen based on a configuration and it could in fact never be called for a binary.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I just don't trust people to a) make sure their "configuration" is actually consistent to whatever OpenSSL version they happen to have, or b) remember to catch exceptions from this call for the scenario of having the wrong OpenSSL version. Rather it'll run into a cycle of "weird, works on my system" until somebody notices that it depends on the OpenSSL version.

So in that regards printing a warning seems still better then, so people at least know to update their "configuration", no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with a warning and nop in case the operation is not supported due to version mismatch.

It's true that forwarding the responsibility to the user for rescuing or checking the library version is not that comfortable.

Adding require "log" I guess.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if my code calls cipher_suites= and it doesn't work because the openssl version is too old, there's no error? The return value even suggests that the cipher suites was correctly set. Since currently you can't even query the configuration on a context instance, there's litterally no way to know whether a call to cipher_suites= was successful. I'd either have to look for a warning message in the log or check the openssl version myself.
I'm very much in doubt that this is a good solution.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I keep saying this should be a runtime error.

Add docs to allow user discover the need for changing the security_level
@bcardiff bcardiff added this to the 1.0.0 milestone Oct 23, 2020
@bcardiff bcardiff merged commit a1f3d8f into crystal-lang:master Oct 23, 2020
@bcardiff bcardiff deleted the feature/ssl-sec-level branch October 23, 2020 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants