5

I am just wondering why is LDAP with STARTTLS is a more preferred industry standard over LDAPS. LDAPS start the communication with encrypted information to begin with whereas STARTTLS only upgrades to an encrypted connection once the authentication is successful.

2 Answers 2

7

I am just wondering why is LDAP with STARTTLS is a more preferred industry standard over LDAPS.

It actually isn't. Current best practice regarding STARTTLS is, according to RFC8314:

In brief, this memo now recommends that:
[...]
o Connections to Mail Submission Servers and Mail Access Servers be made using "Implicit TLS" (as defined below), in preference to connecting to the "cleartext" port and negotiating TLS using the STARTTLS command or a similar command.

The reason is explained at the end - https://www.rfc-editor.org/rfc/rfc8314#appendix-A:

Although STARTTLS appears only slightly more complex than separate-port TLS, we again learned the lesson that complexity is the enemy of security in the form of the STARTTLS command injection vulnerability (Computer Emergency Readiness Team (CERT) vulnerability ID #555316 [CERT-555316]). Although there's nothing inherently wrong with STARTTLS, the fact that it resulted in a common implementation error (made independently by multiple implementers) suggests that it is a less secure architecture than Implicit TLS.

Yes, this RFC talks about e-mail and not LDAP, but e-mail is the protocol that STARTTLS was invented for, so this RFC is absolutely relevant for any protocol that supports STARTTLS, including LDAP.

From what I can gather, the unfortunate reason why this hasn't made it into any (new) LDAP RFC is quite simply: no one has bothered yet. To make it worse, people like to quote this ancient OpenLDAP FAQ article that recommends STARTTLS over LDAPS, but unfortunately fail to realize that the OpenLDAP FAQ has been unmaintained, outdated and wrong for years.

An additional disadvantage of LDAP+STARTTLS vs e-mail+STARTTLS: e-mail protocols are designed in a way where the server can prevent a misconfigured client to send authentication data over plaintext, by simply not advertising authentication support before encryption has been negotiated. The LDAP protocol is not designed this way, so an LDAP server with STARTTLS support has absolutely no way to prevent a misconfigured client to send authentication data over the unencrypted connection.

If you want up-to-date information, search the OpenLDAP mailing list instead, and regarding STARTTLS, especially this thread.

1

STARTTLS only upgrades to an encrypted connection once the authentication is successful

Are you sure? With SMTP, TLS is started first and authentication is performed over the encrypted connection. This suggests LDAP works the same way:

This value activates STARTTLS encryption for any server-side traffic that requires STARTTLS encryption. In this case, the BIG-IP system activates STARTTLS when a successful connection is made.

In general regarding STARTTLS:

I am just wondering why is LDAP with STARTTLS is a more preferred industry standard over LDAPS.

Some reasons to use STARTTLS over always using an encrypted connection:

  • Clients that do not support STARTTLS can still connect and receive a protocol-valid error, which they can show to the user. Clients that don't support encryption will not be able to connect to a LDAPS server at all. This means when TLS is required, STARTTLS provides better diagnostics.
  • STARTTLS could potentially also provide better diagnostics when TLS is required and the client supports it, but the handshake fails for whatever reason.
  • STARTTLS can be optional. When it is, one port services both encrypted and plain text clients. With LDAPS the client must get the port right or connection fails.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .