Bug #1052
closed
Certificate validation of the LDAPS servers is not enforced
Added by Florent Daigniere almost 14 years ago. Updated about 7 years ago.
0%
Description
Hi,
Looking around in the source code, it seems that the certificate validation for LDAPS servers is not enforced.
LDAPTLS_REQCERT=never
is set in many places in the source code. The only secure configuration is :
LDAPTLS_REQCERT=hard
were the ssl connection is broken if the certificate verification fails, ensuring that the credentials are not leaked to a third party in case of active MitM attack.
Please fix it.
Files
| pfsense-fix-bug1052.diff (1.37 KB) pfsense-fix-bug1052.diff | Florent Daigniere, 11/13/2011 08:32 AM | ||
| pfsense-fix-bug1052_v2.diff (1.26 KB) pfsense-fix-bug1052_v2.diff | Florent Daigniere, 11/13/2011 09:15 AM |
Updated by Florent Daigniere almost 14 years ago
One of the places where it should be fixed is openvpn's configuration with LDAPS (see bug #1037)
Updated by Chris Buechler almost 14 years ago
- Priority changed from Urgent to Normal
- Target version set to 2.0
Updated by Scott Ullrich almost 14 years ago
- Target version changed from 2.0 to 2.1
Updated by Chris Buechler almost 14 years ago
- Target version changed from 2.1 to 2.0
Updated by Ermal Luçi almost 14 years ago
You suggested TLS_REQCERT=never while it seems that default setting is 'try' which is the recommended one!?
TLS is hard to get right so i would say either leave it as is for now and later on do properly on 2.1 through the gui.
Updated by Florent Daigniere almost 14 years ago
Let me clarify:
The situation was that ALL openvpn authentication requests were failing when it wasn't specified (bug #1037). Setting it to 'never' fixed that problem (in the sense that now the authentications succeed) but is insecure. Since http://redmine.pfsense.org/issues/1037#note-3 I have suggested 'hard', which is secure but won't work if the openvpn CA is different from the LDAPS CA.
To be pendantic, the current scheme sucks. The CA for the LDAPS server might be different from the one used by Openvpn... To fix both bugs properly, you'd have to ask for wich CA to use on the LDAPS configuration panel and to enforce its verification everywhere (openvpn is not the only service which can interface with LDAPS).
This is a security bug. It's not specific to openvpn or the openvpn plugins; it's specific to "using LDAPS". If any service is using it and the pfsense server is being man-in-the-middled, credentials will be leaked. See /etc/inc/auth.inc
Updated by Chris Buechler almost 14 years ago
the selection of CA for LDAPS should be in the auth server settings, then everything else should point appropriately to that.
Updated by Ermal Luçi over 13 years ago
- Status changed from New to Feedback
Just committed a fix for this.
You have to select the CA where you configure LDAP settings for it to be used.
This solves even the issue of OpenVPN where the CA might be different.
Updated by Florent Daigniere over 13 years ago
I've upgraded to today's nightly: It doesn't work for openvpn nor diag_authentication.php
for openvpn: ldap_setup_caenv is always setting 'LDAPTLS_REQCERT=never'
Updated by Ermal Luçi over 13 years ago
That is because you have to select the CA to use under system->User manager->Servers.
That will force to use a policy of hard with the save CA.
Updated by Florent Daigniere over 13 years ago
Ermal Luçi wrote:
That is because you have to select the CA to use under system->User manager->Servers.
That will force to use a policy of hard with the save CA.
I've tried that as well as creating a new LDAP server; it still doesn't work.
I suspect the problem is in auth.inc:ldap_setup_caenv($authcfg)
the condition is
if (empty($authcfg['ldap_cacert']) || !strstr($authcfg['ldap_urltype'], "SSL")) {
$authcfg['ldap_cacert'] is never set as far as I can tell; is that a typo? was it supposed to be $authcfg['ldap_caref'] ? There's a couple of other occurrence of it the same in the function.
Btw, when I force it to check the certificate, the call to ldap_bind() fails; I suspect there's another problem somewhere. I will try to investigate further and will keep you posted.
Updated by Ermal Luçi about 13 years ago
HAve you tested with latest snapshots?
Updated by Florent Daigniere about 13 years ago
Ermal Luçi wrote:
HAve you tested with latest snapshots?
Hi Ermal,
No, I haven't; just came back from holidays. I will try to in the next few days...
Florent
Updated by Chris Buechler about 13 years ago
- Target version changed from 2.0 to 2.0.1
Updated by Florent Daigniere about 13 years ago
- File pfsense-fix-bug1052.diff pfsense-fix-bug1052.diff added
What is in master is still not working; There's two problems:
1) the environment variables need to be set before you call ldap_set_option() or they will be ignored
2) TLS_CACERT= and TLS_CACERTDIR= need to be prefixed by LDAP
The patch attached fixes these two problems (works for me)
Florent
Updated by Florent Daigniere about 13 years ago
In fact TLS_CACERTDIR shouldn't be set at all in this case. Here is v2 of the same patch.
I know it's late ... but I hope it will make the cut for 2.0.1; What is in master so far doesn't work at all (the LDAPS binding will fail with a non-explicit error message)
Updated by Florent Daigniere about 13 years ago
Hi Ermal,
You have commited v1 of the patch, can you please use v2 instead?
Thanks
Florent
Updated by Ermal Luçi about 13 years ago
For me it is ok as is I do not see any loosing on having what i committed.
Updated by Florent Daigniere about 13 years ago
In the following scenario:
LDAP server 1 has a certificate signed by CA1 and is used on openvpn1
LDAP server 2 has a certificate signed by CA2 and is used on openvpn2
If an attacker can convince CA1 to sign a certificate for server2's FQDN, it will be valid and usable to connect to openvpn2 whereas it shouldn't be. Same thing the other way around.
Updated by Jim Pingle about 7 years ago
- Status changed from Feedback to Resolved
This is working fine on current versions and has been for some time now. Closing.