After having set up our Active Directory to use TLS, it is now reachable through one secure channel. To be exact, I should say “through two secure channels”:

• With LDAPs: on port 636, by doing LDAP through TLS,
• With starttls: on port 389, by doing TLS through LDAP.

Subtle.

The thing is, we read everywhere that “LDAPs is deprecated” and that we should privilege starttls. Suddenly, we ask ourselves lots of questions … Why have they kept LDAPs if it is less good? But since it’s security, it’s obviously important! But why keep LDAPs in this case? So it’s got something better !? But what ???

I am totally freaking out!

Peg in Peg+Cat

Come to think of it, wouldn’t it be a little “Tweedledum or Tweedledee”?

To be honest, the question arose after a discussion on twitter. No matter how hard we looked on the Internet, we could find this statement, but never its justification. We finally found the end of the story and figured it would be worth documenting it so that others would waste less time searching.

Thanks: @xhark (originally from blogmotion.fr) for the idea and the discussion that followed.

LDAPs

Initially (in the 90s) when we dealt the question of securing LDAP, the engineers followed the simplest path and applied the usual technique:

Let’s establish a secure channel with SSL and pass all LDAP through it. And we add an s to the acronym to show that it’s secure.

Engineers

And bam, they invented LDAPs.

To do this, the server opens another port (636). The client connects to it and after an all-classic SSL negotiation phase, the two will exchange LDAP messages without having to worry about these cryptographic details.

The protocols having their small diseases, we then discovered vulnerabilities in SSL (it’s rather annoying) which we corrected in a new version which we took the opportunity to rename to TLS. By old habits and abuse of language, we still often talk about SSL even when we do TLS…

The problem is, this method has never been standardized. People have set it up in a kind of happy anarchist consensus that the Internet has a secret. And in the end, it worked pretty well.

Except that without “official version of the myth” each one could go there of its small variation.

Starttls

Frankly, I find it hard to see how a stack as classic as LDAP through TLS could be ill-suited to the point of being incompatible with other implementations, but nature abhors a vacuum…

Vacuum filled by the IETF in May 2020 with its RFC 2830. It introduces an extension of the LDAP protocol made up of the famous “Start TLS” command (which we write starttls). It’s full of technical details, obviously, but I’ll give you the simplified version:

At the start of a normal LDAP connection, the client says that from now on, we create a TLS channel and we will exchange the other LDAP messages in it.

RFC 2830 (simplified version)

It is therefore the same as before except that instead of opening a dedicated TCP port, we reuse the same as for LDAP (389).

The standard itself recognizes that this new method adds nothing more than a classic TLS connection:

All security gained via use of the Start TLS operation is gained by the use of TLS itself. The Start TLS operation, on its own, does not provide any additional security.

Section 6 of RFC 2830

An IETF standard looking better than an arrangement of sysadmins on a corner of a cosmic table, LDAPs was therefore considered deprecated in favor of starttls.

However, since it is the client who sends this command, the server must be configured to refuse to respond until the client sends starttls (otherwise, it would go unencrypted). It’s a shame and much more restrictive than changing the TCP port, but that’s the price to pay for a standard, you can’t have everything.

If you want our opinion, this story of obsolescence of LDAPs has been imposed by software companies to justify the super and too secured new option of their product.

And after ?

As you have seen, the two methods are cryptographically equivalent and therefore provide the same level of security. The difference is therefore to be found in the small details …

1. On the one hand, starttls. If you favor normalization. The risks of incompatibilities are certainly very low, but who knows? Remember to setup the server to refuse commands before receiving starttls.
2. On the other hand, LDAPs. If you prefer to establish TLS connections straight away without having to touch the server. A port restriction in the firewall and you have peace of mind, no one will be able to communicate in cleartext.

In fact, it will be your client software that dictates what to do. Depending on its possibilities, you may be forced to use one of those methods. But now you know it doesn’t change connection security.