skip to content

How does the StartTLS extended operation protect an LDAP connection differently from connecting with TLS already in place?

level: juniorimportance: must knowfreq 52%

answer

  1. two routes onto the same protocol
  2. one is negotiated, one is assumed
  3. an extended operation, not a port
  4. the root DSE advertises it
  5. only one of the two has an RFC

basics

~20 s

StartTLS is an LDAP extended operation that negotiates TLS in band on an already-open, initially unprotected connection, so the server may decline it. The alternative connects to a separate, conventional port where TLS runs from the first byte, unnegotiated.

solid answer

~40 s

There are two routes. With StartTLS the client opens an ordinary LDAP connection and sends an `ExtendedRequest` whose `requestName` is the OID `1.3.6.1.4.1.1466.20037`; the server answers with an `ExtendedResponse`, and only on `success (0)` is a TLS layer installed underneath the connection already in progress. Because it is negotiated in band the server can refuse, and a client can check `supportedExtension` in the `root DSE` before it ever sends an LDAP Bind operation. The other route is implicit TLS: a separate, conventional port where the transport carries TLS from the first byte, so no LDAP message is ever exchanged in the clear and nothing is negotiated. The first is defined by RFC 4511 and RFC 4513; the second is a deployment convention that no RFC in the LDAP core suite standardises.

code

asn1 · 4 lines
asn1
ExtendedRequest ::= SEQUENCE {
    requestName   LDAPOID,               -- "1.3.6.1.4.1.1466.20037"
    requestValue  OCTET STRING OPTIONAL  -- absent for StartTLS
}

go deeper

for a junior

Recall that there are two routes: an in-band upgrade on the ordinary connection, and a separate conventional port that is already protected when you connect. Name the upgrade as the StartTLS extended operation.

for a middle

Explain the mechanics: an ExtendedRequest carrying the StartTLS OID, an ExtendedResponse that may refuse it, the root DSE advertising support, and the fact that only the in-band route is in the core suite.

for a senior

Show that you plan for the refusal. The interesting case is the client that asks for the upgrade, is declined, and carries on binding anyway — say how your connection policy forbids that.

for a principal

Frame it as an estate question: an advertised, refusable upgrade gives you per-client visibility, while a protected port gives you a boundary you can enforce without trusting client behaviour.

## What both routes are for An LDAP connection carries an `LDAPMessage` stream with no protection of its own. A `BindRequest` using the name/password authentication mechanism of simple bind puts a bind DN and its password on the wire; a `SearchRequest` and the `SearchResultEntry` messages answering it put people, groups and machines on the wire. Protecting that stream is not part of the LDAP message layer — it is a layer installed **under** it. There are exactly two ways that layer gets there, and they differ in *when* it is installed and *who* agreed to it. ## Route one: the StartTLS extended operation RFC 4511 defines a general extension mechanism, the `ExtendedRequest`, carrying a `requestName` (an OID naming the operation) and an optional `requestValue`. StartTLS is one instance of that mechanism — not a separate protocol, not a separate port: 1. The client opens an ordinary, unprotected connection. 2. Optionally it reads the `root DSE` anonymously and looks for `1.3.6.1.4.1.1466.20037` among the `supportedExtension` values. 3. It sends an `ExtendedRequest` with `requestName` set to that OID and no `requestValue`, and sends nothing further at the LDAP message layer until the answer arrives. 4. The server replies with an `ExtendedResponse`. On `success (0)` both sides start the TLS handshake and the layer is installed under the existing connection. On any other result the connection continues exactly as it was — unprotected. 5. Only now does the client send its LDAP Bind operation. Three properties follow from that shape. It is **in band**: same port, same connection, same protocol. It is **refusable**: the server is entitled to decline, and a client that shrugs and binds anyway has just sent a password in the clear. And it is **advertised**: the `root DSE` tells a client what to expect before any credential is exposed. ## Route two: implicit TLS on a separate port The other deployment is blunter. The server listens on a second, conventional port; a client connecting there completes a TLS handshake before the first LDAP byte, and every `LDAPMessage` on that connection is protected from the outset. Nothing is negotiated, nothing is advertised and nothing can be refused, because protection is a property of the port rather than of an operation. Here the honest statement matters, because the market rarely makes it: **no RFC in the LDAP core suite standardises this**. The suite specifies the StartTLS extended operation and how it interacts with authentication; the separate-port convention grew up beside it, is near-universally implemented, and is defined by convention rather than by a core-suite document. ## Comparing them | | StartTLS | implicit TLS | |---|---|---| | Where it runs | the ordinary connection, same port | a separate, conventional port | | How protection starts | an `ExtendedRequest` the server may decline | the transport handshake, before any LDAP message | | Discoverable? | yes, `supportedExtension` in the `root DSE` | no, it is configuration the client is told | | Specified by | RFC 4511 and RFC 4513 | no RFC in the LDAP core suite | | First bytes on the wire | LDAP in the clear until the upgrade | a TLS handshake | | Failure mode to watch | a declined upgrade the client ignores | a client that quietly falls back to the plain port | ## What neither route changes Once the layer is installed the two are indistinguishable at the LDAP message layer: the same operations, the same result codes, the same controls. Neither route authenticates anybody — protecting the channel and setting the connection's authentication state are separate steps, and the LDAP Bind operation is still required. Neither route changes what a bound identity is allowed to read. And a protected connection does not make an anonymous search less readable to whoever is allowed to perform it. ## Why an interviewer asks this Because the answer separates a candidate who has configured a directory client from one who knows what the protocol does. The configured-it answer is 'one is plain, one is secure'. The protocol answer is: one is an extended operation negotiated in band on a connection that begins unprotected and that the server may refuse; the other is an unnegotiated convention where the transport is protected before LDAP starts — and only the first of the two is written down in the core suite.

  • What should a client do when the server answers the StartTLS extended operation with something other than success (0)?
    Treat the connection as unprotected and decide deliberately. The connection is still usable, which is the trap: a client configured to try the upgrade and continue on failure will send the password from its next LDAP Bind operation in the clear. A client that requires protection should close the connection instead of binding.
  • Why can a client read the root DSE before it has bound at all?
    The `root DSE` is the server's own entry describing what it supports — `supportedExtension`, `supportedControl`, `supportedSASLMechanisms`, `namingContexts` — and servers normally allow it to be read by an unauthenticated caller precisely so a client can discover capabilities before choosing how to authenticate.
  • Once TLS is installed by either route, does anything about the LDAP messages change?
    No. The same `LDAPMessage` envelope, the same operations and the same result codes travel inside the layer. The difference is only in when the layer was installed and whether its installation was negotiable — which is why the choice between the two routes is about deployment and enforcement, not about protocol capability.

saying these in an interview costs you the question

  • Says the separate TLS port is defined by its own LDAP RFC.
  • Claims credentials are exposed because a StartTLS connection begins in the clear.
  • Thinks a server must accept the StartTLS extended operation whenever a client asks.
  • Treats StartTLS as a different protocol rather than an extended operation.
  • Assumes the LDAP messages differ between the two routes once TLS is up.