-
Notifications
You must be signed in to change notification settings - Fork 251
Addresses the LDAPS vulnerability to MITM attacks by properly authenticating the hostname #259
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
Conversation
…e against the CN or SAN in X509 Cert if OpenSSL::SSL::VERIFY_NONE is *not* set. Effectively, it bundles the proper host authentication step people mistakenly assume happens when OpenSSL::SSL::VERIFY_PEER is set.
One thing, in case it makes it to the official docs.
I believe that users who want TLS/SSL just for encryption don't have to do anything as in Ruby, the default OpenSSL params include VERIFY_NONE (which is part of the problem on the first place). |
I think I failed to check/regression test if the patch breaks non-SSL connections, so I'll need to re-submit. ```
|
…ts otherwise a nil error results for connections without encryption
ruby 1.9 & 2.x has insecure SSL/TLS client defaults and Changed default settings of ext/openssl suggests newer ruby versions are more secure by default, so the pull request/patch could cause net-ldap users to bump into issues if they previously didn't bother or want to validate the sever cert properly, but that's a ruby-wide SSL default issue and the potential 'backward compatibiltiy' bug reliant on insecure defaults will impact the whole ruby community, not just net-ldap. So allowing users to explicitly set Example below shows new versions have
|
#262 pull request that aims to address the same issue. |
…tive manual test cases
Okay, found some time to test this more extensively. I noticed the following is causing the CI build tests to fail for this pull due to:
which happens because
Wrote test-ldaps.rb to run a number of positive and negative test cases for our org's use case (load balanced LDAPS with Active Directory). Positive TestingWhen correct hostname is used
NegativeTesting - hostname missmatchWhen intentionally incorrect hostname is used
NegativeTesting - cert not validWhen intentionally incorrect .pem file is used
Regression test LDAP (non SSL/TLS) connection and bindMake sure code changes don't break how the connection for plain LDAP was handled
|
else | ||
@conn.post_connection_check(host) | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JPvRiel what was your reasoning for putting this check in #open_connection
rather than .wrap_with_ssl
? It looks like that code path is always used when setting up SSL connections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's just a matter of not knowing much about the internals of the lib, we just found the issue while doing some SSL verification. Feel free to move it where ever is the right place for this code (you know the code better than us), we're just trying to help out on the SSL-verification case. Makes sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jch, I also wanted to put the code into .wrap_with_ssl
initially. However, the current .wrap_with_ssl
function doesn't have access to any variable with the FQDN/hostname used to make the connection in order to pass that to post_connection_check
. There was another PR that attempted address this passing around the extra host info by adding an extra host parameter for the .wrap_with_ssl
function.
See: #262 (comment). However, that PR had a few other unresolved questions about how it handled default validation...
One of the reasons I didn't go that way is I noticed the connection.rb code is flagged for some major refactoring anyhow, and yeah, as above, you'd be in a better place to make a call where best to inject post_connection_check
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I forgot that it's a class method.
@JPvRiel thanks for opening this PR and also including a test manifest. Could you look into converting your test script into an integration test? .travis.yml runs an openldap install and sets the INTEGRATION environment variable for tests that live under test/integration. The install currently does not configure tls, so would need to be updated to support that. |
@jch to add that into your test code, I'd have to learn the ropes with travis and test/integration. I suppose it's a nice task to learn, but that's going to take me much longer than someone who's already familiar with the projects test harness. Hence I've made my test example available https://github.com/JPvRiel/test-ruby-ldaps hoping it'll be easy to port by a dev already familiar with the ruby-net-ldap test suite... |
@JPvRiel sorry for the slow feedback cycle. I still haven't had time to work on this, and don't see that changing soon. I'm going to leave this PR open so people can find it easily and apply the patch to their local install as needed. If anyone is interested in working on this, please let me know and I can help walk you through it. |
This attempts to address LDAPS vulnerable to MITM - failure to validate hostname against CN or SAN in X509 Cert.
It has been briefly tested and when connecting or binding via LDAP against a , the following exception occurs
Users who want TLS/SSL just for encryption and don't care about hostname validation should be able to use
:tls_options => { :verify_mode => OpenSSL::SSL::VERIFY_NONE }
to allow for insecure connections.