On 2/26/20 6:17 AM, patrick.hush@comcast.net wrote:
When 389 is used for start_tls, think of it as a unecrypted handshake sort of like this:
[...]

So there is quite a bit more going on than just 636 (LDAPS). Straight 389 is clear text and should be avoided.

It's a bit more complicated that my explanation, but it gives an idea.

Yes that's a good explanation and translation of a STARTTLS negotiation to English.

The protocol for converting "straight 389 clear text" to use TLS is called STARTTLS and is described in RFC4511: https://tools.ietf.org/html/rfc4511#section-4.14.

I know it's a few more packets of initialization to set up STARTTLS with the cleartext TCP/389 listener over the LDAPS TCP/636 listener (note also in modern implementations will use the TLS 1.2 or 1.3 encryption protocol, not SSL), but otherwise each should be as good as the other. If you capture either you can see the certificates, but not much else (without the server key anyway) since of course after the negotiation, all data is encrypted.

A lot of implementations (RedHat IDM, Windows AD) set up SRV records for LDAP at 389 and don't set up LDAPS SRV records for 636. This sort of presumes everyone will use 389. Or course you can adjust and presume as you would wish to do (even make an LDAPs listener on 6943 if you wanted).

I think a lot of network/firewall admins like to only allow one port. I would not argue with someone who said that it should be 389 that's blocked and not 636, and adjust everything to not use STARTTLS but "pure" TLS on the LDAPS TCP/636 listener, but I think it's OK if you use STARTTLS on 389 if you are sure all your clients use it, or your server is able to prohibit BINDs without TLS (or "channel binding").

The one mistake I see a lot is people turning off server validation. That's a bad idea and a bad practice. Services and servers should be authenticated to clients as much or more so than clients should be authenticated to servers and services.

CP

Chris Paul
Rex Consulting, Inc
email: chris.paul@rexconsulting.net
web: http://www.rexconsulting.net
phone, toll-free: +1 (888) 403-8996 ext 1