TCP Port 636 – LDAPS (LDAP over TLS)

Port 636 is the standard port for LDAPS, the TLS-wrapped version of the Lightweight Directory Access Protocol used to query and modify directory data. The plaintext version of LDAP runs on port 389. Port 636 carries the same protocol over an encrypted connection.

LDAP itself originated at the University of Michigan in the early 1990s as a lighter alternative to the X.500 Directory Access Protocol, with version 3 standardized in RFC 2251 in 1997 and updated in RFC 4511 in 2006. LDAPS, the implicit-TLS variant on port 636, was never standardized in its own RFC. Vendors deployed it as a practical solution to the problem of encrypting directory traffic before LDAP version 3 added the StartTLS extension. The current IETF recommendation (RFC 4513) is to use StartTLS on port 389 rather than implicit TLS on 636, but in practice both deployment models remain widespread.

The most prominent LDAPS deployment is Microsoft Active Directory. Domain controllers in an Active Directory environment commonly accept connections on both port 389 (LDAP, often with StartTLS) and port 636 (LDAPS), and many enterprise applications query AD over LDAPS to authenticate users, look up group memberships, and resolve distinguished names. Other directory products such as OpenLDAP, 389 Directory Server, and Oracle Internet Directory follow similar patterns.

The clients that connect to LDAPS are typically server-side processes: web applications doing single-sign-on, mail servers looking up addresses, file servers checking group membership, and other applications that need to authenticate users or retrieve directory data. Direct LDAPS connections from end-user workstations are uncommon outside specialized administration contexts.

Inbound TCP/636 to a designated directory server is normal and continuous in environments that use LDAPS. Inbound TCP/636 to any other host is unusual. UDP/636 is also registered in the IANA registry but is rarely encountered in practice; LDAP and LDAPS are TCP protocols.

About TCP Port 636

Port 636 is registered with the Internet Assigned Numbers Authority (IANA) for ldaps. The IANA description reads: ‘ldap protocol over TLS/SSL (was sldap)’.

Security Considerations

Our data shows 31 IDS rules referencing port 636, all on TCP. The dominant pattern is OpenSSL Heartbleed (CVE-2014-0160) detection, the same rule family seen on other TLS-wrapped services in our dataset.

Heartbleed was disclosed in April 2014 and was one of the most impactful single TLS implementation bugs in internet history. The vulnerability was a missing bounds check in OpenSSL’s implementation of the TLS heartbeat extension that allowed an attacker to read arbitrary blocks of memory from the server’s process. On a directory server running LDAPS, the consequences were particularly severe: the leaked memory could contain authentication data passed in recent LDAP bind requests, session state, query results containing user attributes, and potentially the server’s TLS private key. The directory’s role in identity infrastructure made compromise of an LDAPS server one of the higher-impact Heartbleed scenarios. The rules are classified as reconnaissance because Heartbleed was an information-disclosure attack.

The directory infrastructure context shapes the broader threat picture for port 636. An attacker who gains read access to an LDAP directory (whether through a TLS implementation bug, a compromised application credential, or anonymous-bind misconfiguration) can enumerate users and groups, learn organizational structure, identify privileged accounts to target, and in some Active Directory configurations retrieve password hashes that can be cracked offline. LDAPS encryption protects directory traffic in transit; it does not, on its own, address authorization weaknesses on the server side.

Defensive practice for LDAPS centers on keeping TLS libraries current, restricting which clients can reach port 636, requiring authenticated binds for any non-trivial query, limiting which directory attributes are exposed to unprivileged binds, and monitoring for unusual query patterns. In Active Directory environments, LDAP signing and channel binding requirements provide additional protection against relay attacks and unsigned-bind abuse. Network controls should restrict TCP/636 to the server-side processes that legitimately need it.

Inbound TCP/636 to a host that is not a designated directory server is unusual. Inbound TCP/636 from end-user workstations to a directory server is generally normal in Active Directory environments where workstation authentication runs through the directory; inbound TCP/636 from a workstation to a non-directory host is unusual and worth investigating.

IDS Rule References

31 IDS / security rules reference TCP port 636. Treat that number as context, not a danger score. Many detection rules are written against groups of ports rather than one service, web ports especially, so common web alternate ports inherit large counts while genuinely sensitive services can show few rules or none. Presence in IDS rules does not mean traffic on this port is malicious.

Rule categories (top 2): attempted-recon (26), bad-unknown (5).

Sample rule descriptions for TCP port 636:

• SERVER-OTHER OpenSSL SSLv3 heartbeat read overrun attempt
• SERVER-OTHER OpenSSL TLSv1 heartbeat read overrun attempt
• SERVER-OTHER OpenSSL TLSv1.1 heartbeat read overrun attempt
• SERVER-OTHER OpenSSL TLSv1.2 heartbeat read overrun attempt
• SERVER-OTHER OpenSSL SSLv3 large heartbeat response – possible ssl heartbleed attempt

Data Sources

This information is compiled from: IANA Service Name and Transport Protocol Port Number Registry, Emerging Threats Open Ruleset (BSD 2-Clause / GPLv2 per SID range), and Snort Community Rules (GPLv2).