The LDAP StartTLS extended operation

In some cases, it might be possible to establish a non-secure connection and then convert it to a secure one. In LDAP, this can be accomplished with the StartTLS extended operation.

In most cases, when a client wants to use TLS, they establish a connection to a port dedicated to its use, like 636, which is the standard port for LDAPS, or 443, which is the standard port for HTTPS, and the client immediately sends a client hello message over that connection to begin the TLS negotiation process.

There are potential advantages to using the StartTLS extended operation over a dedicated LDAPS connection. It does mean that only one port needs to be opened through a firewall for both secure and insecure communication. It also means that a client can use opportunistic encryption, whereby the client can first query the root DSE to determine whether the server supports StartTLS and then secure the connection if possible. This can be useful in cases like following referrals because LDAP URLs do not officially support “ldaps” as a scheme.

However, we recommend using LDAPS to ensure that the communication is always secure, rather than establishing an initially insecure connection and then securing it with the StartTLS extended operation. If you enable support for unencrypted LDAP communication, which is required for StartTLS, then you run the risk that a client might send sensitive data, such as a bind request containing a password, over that unencrypted connection. The server can be configured to reject any unencrypted communication, but it can’t prevent the client from sending the unencrypted request in the first place.