Does ONTAP support LDAPs??
StartTLS is insecure compared to LDAPS, right?
Well, let me tell you something........
LDAPS is sooo 90's. There! I said it! 90's? really? Yep! RFC1777 was published in 1995! And guess what? There was no standard written for LDAP over SSL! This was just assumed and taken from HTTPS at the time. The LDAP vendors took it, and rolled with it.
Enter LDAPv3.
RFC2251 was started and completed in 1997. That didn't have any additional verbiage for on-the-wire encryption, but when RFC2830 was written in 2000, it made an extension for LDAPv3 specifically for StartTLS. RFC4511 combined them into one LDAP v3 standard in 2006. Once LDAP v3 was ratified and made it into mainstream in the early 2000's, LDAP vendors started to deprecate the LDAPS encryption method for StartTLS.
Deprecate. That's a big word. But what that means is that to "be usable but regarded as obsolete and best avoided, typically due to having been superseded." Don't believe me? Check it out:
https://www.openldap.org/faq/data/cache/605.html
https://directory.apache.org/api/user-guide/5.1-ldaps.html
https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Protocol_overview
I can go on.... Just do a Google search for LDAPS deprecated and see.
Clustered Data ONTAP started without any LDAPS support in favor of StartTLS because of the above reasons. All LDAP vendors had to support the StartTLS extension because it was part of the standard. Also, because LDAPS was deprecated, it could be yanked at any time.
But.... StartTLS is not as secure as LDAPS!! It runs over a plaintext port!
Well, if you leave your LDAP install wide open, sure. Your LDAP is still insecure. But there are countermeasures that you can deploy to make sure StartTLS is secure.
- Make sure that StartTLS is enabled. DUH.
This requires certificates. Certificates are hard, but learn them. They make things secure. For internal, self-signed certs are OK as long as the domains and permutations of them are accounted for. - Prevent queries without StartTLS.
Now that StartTLS is enabled, you can set up LDAP servers to prevent LDAP commands unless the connection is StartTLS upgraded. This can be done on a DIT (directory information tree) basis. - Prevent LDAP binds without StartTLS
There is also a way to prevent BINDs from happening in plaintext. Consult your LDAP vendor's documentation on how to do this. - Prevent LDAP clients to send plaintext creds
You still want to prevent your clients from sending their credentials in plaintext. This means setting the minimum bind level at SASL. The credentials passed will also be encrypted.
Doing all this will ensure that the LDAP communication is always secure.
How do you configure LDAP to work with StartTLS in ONTAP? Easy. Install the root certificate for the LDAP server's enterprise and then change the LDAP client config for -use-start-tls true and you are set to go.
Here's how your traffic looks:
I don't see any holes in there. Application data means its encrypted and is all buttoned up!
How do you configure LDAP to work with StartTLS in ONTAP? Easy. Install the root certificate for the LDAP server's enterprise and then change the LDAP client config for -use-start-tls true and you are set to go.
Here's how your traffic looks:
What about ONTAP and LDAPS? Well... low and behold...... 9.5 introduced the ability to do LDAPS. Even though its deprecated and there are alternatives, the ability to do LDAPS was granted.
How do we do it?
Change the port in the ldap config to port 636. Make sure -use-start-tls is turned to false and the same enterprise root cert is installed into ONTAP. Is this more secure? Less secure? Who knows. Not my debate.
Here's what your traffic looks like:
How do we do it?
Change the port in the ldap config to port 636. Make sure -use-start-tls is turned to false and the same enterprise root cert is installed into ONTAP. Is this more secure? Less secure? Who knows. Not my debate.
Here's what your traffic looks like:
You decide. They look almost identical to me except for the LDAP START_TLS packets at the beginning.
As I understand your packet trace, once set up properly both should be reasonably safe.
ReplyDeleteBut with the complex setup of StartTLS for LDAP there are a lot of things that human error can lead to insecure configurations.
You didn't really elaborate about the LDAPS setup procedure. If that is easier and if not done right just does not work - instead of giving plain text access - then I would rate LDAPS more secure just on account of avoiding human error.
my 2Ct.
Great post! Really loved reading it and it's written amazingly! Thanks for the cool share :) Appreciate it.
ReplyDeleteutility kilt
I agree with @mboris. We use HAproxy to front-end LDAPS-to-ActiveDirectory, and LDAPS "just works". I don't think there's a way, given the layer that HAproxy operates in, to add STARTTLS negotiation and SASL and secure bind etc.
ReplyDeleteHopefully, LDAPS will never die. But AverageGuy might be happy to know that a certain CRM vendor is using his page to justify their position that customers should be using STARTTLS.
Nice post, and I agree with most of it, but the one thing LDAPS prevent that StartTLS with LDAP simply cannot is the thing that the server side folks can never fix: clients accidentally leaking connection information when they try to use LDAP WITHOUT StartTlS. Even if the server side rejects it, the client has already sent its sensitive information onto the wire where bad guys can sniff it like any other cleartext data (telnet, ftp) from the 1990s. LDAPS forces a TLS/SSL handshake prior to any credentials being sent, which StartTLS cannot force, since it is part of the LDAP (application layer) protocol rather than a part of something just above TCP below the application layer.
ReplyDeleteAlso, the links cited are not primary sources. OpenLDAP, Wikipedia, and Apache Directory Studio did not define the RFC, and following their links to RFCs I have yet to see anything stating that LDAPS is deprecated, obsolete, or otherwise less-good. Sure, StartTLS is part of LDAPv3, and it does what is needed, but until clients force StartTLS (or at least try it by default, which they still do not normally) it's a problem requiring everybody to learn the right and harder way over the wrong and easier way. Combine that with human nature and you end up with security issues.
As a final point, this year I've had three (3) clients asking me about the feasibility of disabling TCP 389 on all their LDAP servers, defaulting to LDAPS only, and then implementing by a couple months ago (late 2020), and these are big companies you've heard of every year since you were born. The primary reason is to make sure clients are not leaking credentials, since the work to setup either StartTLS or LDAPS is the same without the risk of leaking credentials if misconfiguring StartTLS.