pfSense

One of the places where it should be fixed is openvpn's configuration with LDAPS (see bug #1037)

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.

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

the selection of CA for LDAPS should be in the auth server settings, then everything else should point appropriately to that.

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'

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.

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.

HAve you tested with latest snapshots?

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

Committed.

Hi Ermal,

You have commited v1 of the patch, can you please use v2 instead?

Thanks
Florent

For me it is ok as is I do not see any loosing on having what i committed.

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.