nginx-auth-ldap
nginx-auth-ldap copied to clipboard
Any plans to support StartTLS?
Hi, are there any plans to implement StartTLS (over port 389)? Reason I'm asking is ldaps over port 636 is deprecated and it would be nice to still have the connection encrypted. I've set up my LDAP server to require StartTLS before it will send back any information on port 389.
Thanks!
+1
StartTLS would be great.
I would also like to express that StartTLS would be extremely usable - without that I am being forced to use Apache instead of my server of choice - Nginx because I do not accept sending user data (like passwords) via non encrypted channel.
Hi, I've noticed some activity in this issue. Any chance for a comment if/when starttls will be supported? That really is the only acceptable way to use ldap auth in most envs I work on.
Same here, STARTTLS would be extremely useful.
:+1:
If anyone takes this up, my (lack of) progress so far has been:
I tried adding a call to ldap_start_tls_s ( c->ld, NULL, NULL) in ngx_http_auth_ldap_connection_established() after the sockbuf provider is set and before the initial bind. It didn't work. Watching the tcpdumps it appears that TLS gets started but not completely set up, then ldap_start_tls_s() returns and ngx_http_auth_ldap just goes back to sending clear text.
In the dump I saw the SERVER_HELLO and CLIENT_HELLO, and also the SERVER_CERTIFICATE but around the same time as the cert, ngx_http_auth_ldap sent the bind attempt as clear text instead of completing the TLS negotiation. It would appear that the openldap tls sockbuf io layer or the negotiation in ldap_start_tls_s() doesn't work right the way ngx_http_auth_ldap is using it.
This was on ubuntu 14.04.02, which I think is gnutls based.
How about that StartTLS? We're also missing it here.
FYI- I switched to NGINX Auth PAM because of the lack of STARTTLS support with this module. SSSD + PAM + NGINX Auth PAM module was a much better solution overall. It requires a bit more knowledge of Linux, but provides enormous set of options, including two factor authentication, etc... plus PAM in general has a ton of support.
I've actually went the other way around - I used the auth_request module and created a custom app, that allows me to handle basic auth via my python webapp, that DOES support StartTLS and allows me to easily select which groups should have access to which locations (by defining a custom header with group names).
I don't know if it's the most optimal solution, but it gave me a bit more controll over who and how is able to authenticate, and since this is MY app, I can decide how caching works, etc.
And I've went a third way - I've just dropped the Nginx in favor of Apache, that with all its drawbacks, when compared to Nginx, have at least ldap auth module fully functional...
kvspb still commits to the repo, but I don't know if this issue is considered important :( There's been no input from the author.
Three years later and no updates :(
I'm here to add my +1. We're looking at switching from using this module to auth_pam because we require StartTLS support.
Especially when OpenLDAP says, I quote: ldaps:// is deprecated in favor of Start TLS [RFC2830]
. I have moved all SMTP and LDAP servers to STARTTLS long time ago.
Especially when OpenLDAP says, I quote:
ldaps:// is deprecated in favor of Start TLS [RFC2830]
. I have moved all SMTP and LDAP servers to STARTTLS long time ago.
Hey don't feel bad, Atlassian Jira is still stuck on ldaps://
. There's been a ticket for 10 years to get that changed and they've not done a thing!
Yeah, like the adoption of SSL that took decades until the browsers started penalizing websites that don't support it so people take it seriously. Sometimes you need to smack people so they start doing the things properly ;-)
Any news on adding StartTLS support to nginx-auth-ldap? It looks like a pretty nifty authentication module, but I just can't use it until it supports StartTLS to connect to the LDAP server.
You could just use ldap and run through stunnel. It supports all of the tls stuff natively. Just set your local endpoint to 127.0.0.1 xxxx (xxxx being a port of your choice) and you don't have to contend with any modifications of the base nginx.