-
Notifications
You must be signed in to change notification settings - Fork 274
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
validate SSL by default #481
base: master
Are you sure you want to change the base?
Conversation
It should be good practice in 2018 to validate SSL certificates by default, and require the user to disable this explicitly if a validation should NOT be performed. Signed-off-by: Florian Klink <[email protected]>
Hi, sorry for answering late. I'm not sure if this is a feasible approach. LDAP very often is used in internal network where certificates are self signed. To check for ssl validation would cause troubles to a lot of people. Perhaps is better to include a clear statement of this in the docs. |
Skipping certificate validation on an internal network doesn't make a lot of sense either - if one really doesn't care, he can very well just go totally unencrypted, instead of keeping a false sense of security by using unverified SSL by default.
IMHO ldap3 should behave in a secure fashion, even if this means some (broken) setups break after the switch - we should document on how to disable SSL verification if really necessary, and encourage admins to deploy and use valid certificates otherwise - for pretty much the same reasons on why other libraries now verify by default as well.
|
I prefer not to change this default because it breaks compatibility with previous v2.x version because I'm following semantic versioning rules. I can change in version 3.x. |
@cannatag understood. Can we still add an issue to a 3.x milestone, so this won't get lost? |
Sure. I’ll create a version 3 milestone and add this as a feature.
Thanks,
Giovanni
… Il giorno 26 feb 2018, alle ore 17:15, Florian Klink ***@***.***> ha scritto:
@cannatag understood. Can we still add an issue to a 3.x milestone, so this won't get lost?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I'm sorry to insist but I definitely agree with this PR : would it be possible to enforce certificate checking by default? If users are using this lib on an internal network, then it's the job of these users to set up an internal PKI and to trust it (in the Windows Certificate Trust Store, or in the Linux folders |
I know, but this would break a lot of running code. For example most of my programs that use the ldap3 library run in Intranets where ldap servers are using self signed certificates and they would stop working if a newer version of the library validates the certificate by default.
This would be a breaking change that require a major release, so I think it will be in version 3 of ldap3.
I will open an issue for suggestion on version 3 new features and depreciations (probably version 3 will abandon the python 2.6 and python 2.7 compatibility).
… Il giorno 30 dic 2020, alle ore 20:14, Augustin FL ***@***.***> ha scritto:
I'm sorry to insist but I definitely agree with this PR : would it be possible to enforce certificate checking by default?
If users are using this lib in an internal network, then it's the job of these users to set up an internal PKI and to trust it (in the Windows Certificate Trust Store, or in the Linux folders /etc/ssl/certs and /etc/pki/ca-trust/ )
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
It should be good practice in 2018 to validate SSL certificates by default, and require the user to disable this explicitly if a validation should NOT be performed.