Tunnel TLS pour ldap

Il y a semble-t-il un bugg récent assez gênant sur la libraire GnuTLS sous Debian 7. Suite à une mauvaise implémentation semble-t-il au niveau de la négociation des algorithmes de chiffrement, il est impossible de générer ou d’utiliser des certificats pour les programmes qui utilisent cette librairie. Et c’est le cas notamment de slapd, le serveur d’annuaire LDAP (OpenLDAP) sous UNIX.

Le problème aurait pu passer presque inaperçu… mais il y eu heartbleed…Et il se trouve donc qu’un certain nombre d’admins systèmes ont dû changer très rapidement les certificats de leurs serveurs, et ont dû tomber sur ce problème.

Il devient ainsi impossible de relier un serveur de messagerie ou un serveur web avec un annuaire LDAP utilisant OpenLDAP. J’ai notamment le problème avec mon serveur postfix

Il est possible de ne pas utiliser la connexion à l’annuaire via TLS. C’est potentiellement un gros problème de sécurité en fonction des différents réseaux que vont traverser ces flux. Bref, ont n’a plus de sécurité sur un flux qui contient toute l’authentification du réseau. C’est assez moyen.

Il est aussi possible de mettre en place une solution de remplacement avec stunnel. Cela revient en fait à faire manuellement la connexion et le tunnel sécurisé par TLS. En plus, on peut conserver les mêmes certificats que le démon slapd.

Côté serveur

Il faut commencer par désactiver l’utilisation du port tcp/636. Pour cela, il faut modifier une ligne dans le fichier /etc/default/slapd :
SLAPD_SERVICES="ldap://127.0.0.1:389/"

Redémarrer le démon slapd.

Ensuite,on concatène le certificat et sa clé dans un seul fichier :
cat /etc/ssl/private/slapd.key /etc/ssl/certs/slapd.crt > /etc/ssl/private/slapd-all.crt

Enfin, on crée le bout du tunnel côté serveur, en réutilisant le certificat :
stunnel -d 636 -r 127.0.0.1:389 -p /etc/ssl/private/slapd-all.crt

Côté client

Le client, c’est le service qui utilise l’annuaire LDAP, par exemple postfix.

On crée le bout du tunnel côté client :
stunnel -c -d 6389 -r ldap.serveur.net:636

Enfin, on dit au client, en l’occurrence postfix, d’utiliser le tunnel. Modifier le fichier /etc/postfix/main.cf (ou équivalent) :
account_server_host = ldap://localhost:6389/

Et on redémarre postfix

CF : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921

MAJ 14/07/2014

Pour rendre permanent les tunnels créés, il faut créer un fichier de configuration côté client et côté serveur. Puis sur les deux activer stunnel en démon en modifiant le fichier /etc/default/stunnel4 :
ENABLED=1

Côté serveur, créer le fichier /etc/stunnel/ldap-ssl.conf :

client = no
verify = 1
CAfile = /etc/ssl/certs/root.crt
cert = /etc/ssl/private/slapd-all.crt
RNDfile = /dev/urandom
options = NO_SSLv2
pid = /stunnel4.pid
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
[ldap-ssl]
accept  = 0.0.0.0:636
connect = 127.0.0.1:389

Côté client, créer le fichier /etc/stunnel/ldap-ssl.conf :

client = yes
verify = 1
CAfile = /etc/ssl/certs/root.crt
options = NO_SSLv2
pid = /stunnel4.pid
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
[ldap-ssl]
accept  = 127.0.0.1:6389
connect = ldap.serveur.net:636

 Le fichier /etc/ssl/certs/root.crt est à copier depuis le serveur.