Encrypted communication to DC

[Jannis Mann]

Hi,

I am using sssd with out a domain join.
So I am using a binding account which is working fine.

I use our root CA to encrypt the communication to use ldaps over port 636.

I found this FAQ https://docs.pagure.org/SSSD.sssd/users/faq.html (refering
to the Authentication fails against LDAP section)

Do I understand correctly that the communication is encrypted over TLS when
I dont use ldaps?When this is the case I would not need the root ca
certificate and can avoid the problem in running into an expiring
certificate?

Just for my understanding.. How is the TLS encryption to the DC possible if
I don't have a certificate?
When I dont use ldaps is every communication encrypted or only the
transmission of the users password?

What would speak for a ssl encryption over 636 if ldap over 389 is
encrypted aswell with out certificate?

Thank you and have a nice day!

When 389 is used for start_tls, think of it as a unecrypted handshake sort of like this:
client: Yo bro sup, want to encrypt our connections?
server: Ya man, what can you do?
client: I support these ciphers
server: no shit, me too, lets do AES-Foo56
server: here is my cert
client: oh sweet I can read that and it matches my certificate authority
client: okay let's do this shit

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.

cheers
> On February 26, 2020 at 12:01 AM Jannis Mann  wrote:
> Hi,
>
> I am using sssd with out a domain join. 
> So I am using a binding account which is working fine.
>
> I use our root CA to encrypt the communication to use ldaps over port 636.
>
> I found this FAQ  https://docs.pagure.org/SSSD.sssd/users/faq.html (refering to the Authentication fails against LDAP section)
>
> Do I understand correctly that the communication is encrypted over TLS when I dont use ldaps?When this is the case I would not need the root ca certificate and can avoid the problem in running into an expiring certificate?
>
> Just for my understanding.. How is the TLS encryption to the DC possible if I don't have a certificate? 
> When I dont use ldaps is every communication encrypted or only the transmission of the users password?
>
> What would speak for a ssl encryption over 636 if ldap over 389 is encrypted aswell with out certificate?
>
> Thank you and have a nice day!
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]

[Christopher Paul]

On 2/26/20 6:17 AM, [e-mail] 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: [e-mail]
web: http://www.rexconsulting.net http://www.rexconsulting.net/
phone, toll-free: [phone] ext 1