On 2/26/20 6:17 AM, patrick.hush(a)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
The protocol for converting "straight 389 clear text" to use TLS is
called STARTTLS and is described in RFC4511:
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.
Rex Consulting, Inc
phone, toll-free: +1 (888) 403-8996 ext 1