[SSSD-users] Re: Encrypted communication to DC

[Christopher Paul]

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 
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(a)rexconsulting.net
web: http://www.rexconsulting.net <http://www.rexconsulting.net/>
phone, toll-free: [phone] ext 1