Confidentialité et intégrité des communications
Une fois que le serveur et le client LDAP se sont mutuellement identifiés, en justifiant de manière plus ou moins poussée (simple mot de passe ou certificats) qu’ils étaient bien ceux qu’ils prétendaient être, ils peuvent désormais commencer à communiquer entre eux. Seulement, il faut maintenant s’assurer que cette communication ne puisse pas être interceptée, modifiée ou tronquée. Un annuaire LDAP étant destiné principalement à centraliser l’authentification de divers équipements informatiques (applications et systèmes) dans des environnements souvent vastes et complexes, il est donc difficile de l’isoler avec ses différents clients (par exemple dans des VLANS) afin de garantir qu’aucune personne de l’extérieur ne puisse intercepter les communications échangées. Ceci n’est donc pas envisageable dans un monde où les réseaux sont ouverts... Il convient donc de se tourner vers des protocoles de chiffrement qui garantissent aussi bien la confidentialité des données par l’utilisation d’algorithmes de chiffrement très complexes que l’intégrité de celles-ci en apportant une signature électronique pour chaque communication échangée. OpenLDAP donne la possibilité de s’offrir les services de TLS et SSL qui seront donc en charge de cette mission, mais aussi de certains mécanismes SASL qui peuvent également assurer ce service de chiffrement.
OpenLDAP offre la possibilité d’utiliser SSL/TLS et StartTLS. Il est fortement conseillé d’utiliser ces protocoles de sécurisation des échanges, en particulier lors des phases d’authentification de type simple avec transmission des mots de passe en clair sur le réseau.
1. Présentation de SSL et TLS
SSL et TLS sont des protocoles de sécurisation des échanges sur des réseaux ouverts tels qu’Internet. D’ailleurs, ces protocoles sont très utilisés sur Internet et iconisés par un cadenas dans nos explorateurs Internet.
SSL (Secure Sockets Layer) a été développé par Netscape puis standardisé par l’IETF qui le nomma TLS (Transport Layer Security).
La chronologie de leurs améliorations respectives est la suivante :
SSL1.0, SSL2.0, SSL3.0 puis TLS1.0, TLS1.1, TLS1.2 et enfin TLS1.3.
On peut s’apercevoir ci-dessus que le protocole TLS1.0 a immédiatement succédé à SSL3.0, les rendant approximativement identiques. Ils sont également partiellement compatibles en ce sens qu’un client utilisant TLS peut communiquer avec un service utilisant du SSLv3 (et seulement SSLv3), l’inverse n’étant pas possible. On parle alors de compatibilité descendante.
Pour résumer, lors de paramétrages d’applications ou de systèmes où la configuration de SSL, TLS ou SSL/TLS est évoquée, il s’agit en fait du même protocole.
a. Son fonctionnement
SSL/TLS fonctionne suivant un mode client-serveur qui utilise les technologies cryptographiques symétriques et asymétriques (clé publique). La cryptographie à clé symétrique utilise la même clé pour chiffrer et déchiffrer les messages. La cryptographie à clé publique utilise une paire de clés : une clé publique et une clé privée. Alors que la clé publique de chaque serveur est publiée, la clé privée est gardée secrète par ce dernier... Ainsi pour transmettre un message sécurisé au serveur, les clients vont se servir de la clé publique récupérée auprès du serveur. Ce dernier, à réception, déchiffrera les communications à l’aide de sa clé privée personnelle, connue de lui seul. La confidentialité et l’intégrité des données transportées est garantie car seul le système détenteur de la clé privée est capable de déchiffrer ces dernières.
¬
SSL/TLS utilise la technologie de cryptographie asymétrique pour communiquer une clé de cryptographie symétrique (appelée clé de session) aléatoirement générée et à usage unique pour le cryptage de la communication.
SSL/TLS fournit trois services de sécurité de base :
	•	Authentification mutuelle : processus par lequel le client et le serveur se prouvent mutuellement leurs identités. Les identités des clients et des serveurs sont encodées dans des certificats de clé publique, validés par un organisme de confiance dit autorité de certification (CA), permettant donc de s’assurer de leurs validités. Mais en réalité l’authentification mutuelle qui pourtant assure une sécurité maximale, n’est pratiquement jamais implémentée, car trop complexe à maintenir lors du renouvellement des certificats des clients par exemple... Ainsi on privilégiera essentiellement l’authentification du serveur.
Un certificat de clé publique, dont la structure est normalisée par le standard X.509 de l’UIT, contiendra les informations suivantes :
- La version du certificat X.509, 
- Le numéro de série du certificat. 
- L’algorithme de chiffrement utilisé pour signer le certificat. 
- Le nom distingué (DN) du propriétaire du certificat. 
- Le nom distingué de l’autorité de certification émettrice. 
- La date de début de validité du certificat. 
- La date de fin de validité du certificat. 
- L’usage qui sera fait de la clé publique. 
- La clé publique du propriétaire du certificat. 
- La signature électronique de l’émetteur du certificat (calculée 
sur le certificat dans son intégralité).
¬
La signature électronique d’un certificat est générée en calculant l’empreinte de celui-ci puis chiffrée à l’aide de la clé privée de l’autorité de certification ; la clé publique de l’autorité de certification ayant été au préalable largement diffusée afin de permettre aux utilisateurs de vérifier la signature.
Lorsqu’un utilisateur désire communiquer avec une autre personne, il lui suffit de se procurer le certificat du destinataire. Ce certificat contient le nom du destinataire, ainsi que sa clé publique, et est signé par l’autorité de certification.
Il est alors possible de vérifier la validité du certificat de l’utilisateur simplement en ayant connaissance de la clé publique de l’autorité de certification. En effet, pour qu’un certificat soit valide, il suffit que la signature de l’autorité soit correcte et que les dates de validité le soient également.
	•	Confidentialité des messages : réalisée par un algorithme à clé symétrique négocié lors de la phase de configuration de la session.
	•	Intégrité des messages : garantit que le trafic de la session SSL ne change pas en cours d’acheminement vers sa destination finale. SSL utilise une combinaison de clés publiques/privées et de fonctions d’empreintes numériques pour assurer ce service.
Ainsi, voici les événements qui se produisent pendant la phase d’établissement d’une session LDAPS "LDAP over SSL/TLS" limités volontairement à l’authentification du serveur LDAP :
1.	Le client initie une connexion SSL/TLS auprès du serveur LDAP.	
2.	Le serveur renvoie ses éléments cryptographiques (les algorithmes de cryptage disponibles pour la confidentialité de la communication et les algorithmes de hashing disponibles pour garantir l’intégrité des messages échangés) et un certificat qui comprend, entre autres, la clé publique du serveur, l’identité (le DN) pour laquelle le certificat a été délivré, le nom de l’autorité de certification et la validité de celui-ci. Un certificat peut être considéré comme l’équivalent électronique d’un passeport. Il doit être délivré par une autorité de certification reconnue et de confiance (CA), qui garantit que la clé publique appartient réellement à l’entité mentionnée dans le certificat.	
3.	Le client va ensuite contrôler la validité du certificat, l’autorité de certification qui a signé le certificat et l’identité du serveur. Pour ce dernier, le client va se servir de la clé publique de l’autorité de certification afin de valider la signature du certificat du serveur qui lui est présentée. Puis un dernier test sera de contrôler que le nom de domaine présenté dans le certificat (DN) est bien celui du nom du serveur contacté. Ce dernier test permet d’éviter des attaques du style "Man in the middle". Une fois tous ces tests réalisés, le client valide l’identité du serveur puis s’authentifie si cela lui est demandé, sinon passage à l’étape suivante.	
4.	Ensuite, le serveur et le client doivent se mettre d’accord sur une clé secrète (symétrique) utilisée pour le chiffrement des données. Le chiffrement des données se fait avec un algorithme de clé symétrique, car il est plus efficace que les systèmes de chiffrement à clé privée/publique qui nécessite une forte intensité de calcul. Le client génère donc une clé secrète de type "symétrique" et la transmet en toute sécurité au serveur en la chiffrant avec la clé publique du serveur. Seul ce dernier sera en mesure de déchiffrer la clé secrète à l’aide de sa clé privée.	
5.	Le serveur déchiffre la clé secrète et renvoie un message de test crypté avec la clé secrète au client pour prouver que la clé a bien été transmise en toute sécurité. Ils peuvent maintenant commencer à communiquer en utilisant la clé symétrique pour chiffrer les données.	
¬
Pour résumer, SSL/TLS est utilisé à des fins d’authentification unilatérale (ou bilatérale) et de transmission cryptée des données.
2. StartTLS
Afin de bien comprendre le protocole "StartTLS", il faut tout d’abord revenir sur les définitions suivantes :
	•	Protocole : c’est tout simplement un "langage" permettant à deux machines de communiquer entre elles. En informatique, cela se traduit par des règles de communication (métadata) qui encadre les réelles informations à communiquer. Il existe plusieurs couches de langage (layer) permettant à deux machines de communiquer au travers d’un réseau et chacune a un rôle bien spécifique. SSL/TLS est un protocole de communication sécurisé (chiffré) qui se situe au-dessus de la couche "Transport de données" (par exemple TCP), mais en dessous de la couche "Application" (par exemple LDAP) et peut donc être associé à la couche "Session" du modèle OSI.
	•	Port : un port est en fait un numéro permettant d’identifier l’application à joindre via un protocole précis. Par exemple, le port 389/TCP est référencé pour être utilisé par les applications serveurs LDAP non sécurisées. La communication avec un serveur LDAP à l’aide du protocole LDAP demandera que soit fournie l’adresse IP du destinataire ainsi que le port LDAP 389/TCP/.
Le protocole "StartTLS" est en fait utilisé comme une extension de protocole et ne peut donc pas être considéré comme un protocole à part entière. L’intérêt de ce protocole est de permettre la coexistence d’une connexion sécurisée et non sécurisée d’un service sur un même port, simplifiant la configuration des règles sur les Firewalls, la configuration des clients LDAP, mais aussi limite un certain gaspillage d’attribution de port de service.
Ainsi, StartTLS permet aux clients LDAP se connectant sur le port LDAP non sécurisé (389/TCP) de poursuivre les communications de manière sécurisée en SSL/TLS, si bien entendu le serveur le supporte.
¬
StartTLS n’est pas propre au protocole LDAP, il est également disponible et populaire pour des protocoles dédiés au service courrier tel que : IMAP, POP et SMTP.
Par contre, bien que cette extension puisse paraître très pratique, il convient en termes de sécurité de supprimer tout simplement le port non sécurisé du serveur LDAP. En effet, l’extension StartTLS ne serait d’aucun intérêt dans le cas d’un serveur et d’un client LDAP configurés pour l’utilisation du protocole de chiffrement SSL/TLS, car s’ils utilisent l’extension StartTLS pour se connecter, ils deviennent vulnérables à une attaque du type "Man in the middle" où une personne intercepterait les messages du serveur (rappelons que la communication initiale débute en clair) afin d’indiquer qu’il ne supporte pas SSL/TLS. La communication entre ces deux machines pourrait alors s’établir en clair. Cette attaque est connue sous le nom "STRIPTLS".
3. Présentation du programme OpenSSL
OpenSSL est un utilitaire multiplateforme issue de la communauté des logiciels libres et contient tous les outils liés à la cryptographie. C’est-à-dire qu’une fois installé sur un système il sera alors possible d’utiliser le protocole SSL/TLS avec les différents algorithmes de chiffrement symétrique, asymétrique, et les fonctions d’empreinte digitale. OpenSSL offre aussi tous les outils nécessaires afin de créer et de gérer les certificats x509, et également de nombreux outils de dépannage du protocole SSL/TLS. Sa disponibilité sur la plupart des systèmes d’exploitation, car développé en C et la réactivité de la communauté des développeurs lors de découverte de failles liées au protocole SSL/TLS (exemple : heartbleed) le rendent très populaire. D’ailleurs, OpenLDAP le conseille fortement pour la configuration du protocole sécurisé LDAPS.
OpenSSL supporte donc les algorithmes de chiffrement suivant :
	•	Chiffrement symétrique : AES, Blowfish, Camellia, ChaCha20, SEED, CAST-128, DES, IDEA, RC2, RC4, RC5, Triple DES, GOST 28147-89
	•	Chiffrement asymétrique : RSA, DSA, Diffie-Hellman, courbe elliptique, GOST R 34.10-2001
	•	Chiffrement empreinte numérique : MD5, MD4, MD2, SHA-1, SHA-2, RIPEMD-160, MDC-2, GOST R 34.11-94
a. Commande de création de certificats
La commande ci-dessous permet de créer un certificat issu de l’algorithme de chiffrement asymétrique (dit à clé publique) RSA associé à une paire de clés : l’une privée, contenue dans le fichier ".key", l’autre publique contenue dans le fichier ".csr" de 2048 bits. Plus la longueur de la clé sera longue, plus elle sera dur à "casser", mais en contrepartie cela implique une réduction des performances lors de la communication (phase de chiffrement/déchiffrement).
openssl req -new -newkey rsa:2048 -nodes -keyout ldap01.key 
-out ldap01.csr
La clé publique sera donc proposée dans un fichier ".csr" qu’il faudra faire signer par une autorité de certification connue. Dès qu’il sera signé, le certificat sera remis dans un fichier avec une extension en ".crt" ou ".pem" pour le format ASCII, ou ".der" pour le format binaire qu’il sera possible maintenant de charger dans l’application pour l’utilisation du protocole SSL/TLS.
Il est également possible de créer un certificat sans signature d’une autorité de certification : ce sont des certificats autosignés. Ils n’ont donc d’intérêt que pour une utilisation interne.
openssl req -x509 -sha256 -nodes -newkey rsa:2048 -keyout  
privateKey.key -out certificate.crt
Les certificats publics étant accessibles à toute personne souhaitant se connecter au serveur, il convient donc de limiter leurs utilisations dans le temps afin de les rendre inutilisables une fois la date de validité dépassée. Un simple renouvellement de ceux-ci sera nécessaire, inutile donc de regénérer une nouvelle paire de clés "privée/publique"... ceci dit, il ne faut pas hésiter à le faire si la clé privée est compromise.
Voici la commande pour renouveler un certificat public :
openssl x509 -x509toreq -in certificate.crt -out CSR.csr 
-signkey privateKey.key
Parfois, certaines clés privées sont protégées par une phrase secrète (passphrase) afin d’être totalement inexploitables en cas de récupération à des fins frauduleuses. Mais la contrepartie est que cela pourrait compromettre le redémarrage automatique de certaines applications/services (par exemple Apache) pusqu’il faudrait une intervention manuelle pour insérer cette passphrase
Voici donc une commande (utile) permettant de supprimer cette "passphrase" :
openssl rsa -in privateKey.pem -out newPrivateKey.pem
b. Commande de contrôle des certificats
Afin de vérifier les informations contenues dans un certificat, un CSR ou une clé privée, il faudra utiliser les commandes ci-dessous :
# Contrôler un ’CSR’ : 
openssl req -text -noout -verify -in CSR.csr 
 
# Contrôler une clé privée: 
openssl rsa -in privateKey.key -check 
 
# Contrôler un certificat : 
openssl x509 -in certificate.crt -text -noout 
 
# ou bien : 
cat /etc/openldap/cacerts/DigiCertCA.crt | openssl x509 -text -noout
c. Recherche de pannes
Si des erreurs telles que la clé privée ne correspondent pas au certificat, un certificat installé sur un site n’est pas (plus) approuvé ou bien que le certificat est expiré, alors essayer d’utiliser l’une des commandes ci-dessous :
# Vérifier que le serveur répond en SSL/TLS 
openssl s_client -connect hostname:443 
 
# Vérifier avec quelles versions du protocole SSL/TLS le serveur 
est configuré 
# Utile pour tester si votre service est vulnérable au « POODLE » 
openssl s_client -connect hostname:443 -ssl2 
openssl s_client -connect hostname:443 -ssl3 
openssl s_client -connect hostname:443 -tls1 
 
#  Pour récupérer toute la chaîne de certificats (serveur +  
autorité de certification) 
openssl s_client -connect 190.8.37.120:10443 -ssl3 -showcerts 
 
# Vérifier la validité d’un certificat 
# Pour LDAPS 
echo | openssl s_client -connect localhost:636 2>/dev/null | 
openssl x509 -noout -enddate 
# Pour HTTPS 
echo | openssl s_client -connect localhost:443 2>/dev/null | 
openssl x509 -noout -enddate
d. Commandes de conversion de certificats
Ces commandes permettent de convertir des certificats et des clés en différents formats pour les rendre compatibles avec différents serveurs et applications. Par exemple, il est possible de convertir un fichier PEM normal qui fonctionne avec Apache dans un fichier PFX (PKCS # 12) afin de l’utiliser avec Tomcat ou IIS.
# Convertir un certificat de DER à PEM 
openssl x509 -inform der -in certificate.der -out certificate.pem 
 
#  Convertir PEM au format DER 
openssl x509 -outform der -in certificate.pem -out certificate.der
Le cas le plus souvent rencontré par un administrateur informatique sera de convertir un format ".crt" en format ".pem".
Pour cela, il est conseillé de convertir d’abord le fichier ".crt" en ".der" puis le fichier ".der" en ".pem".
# Convertir un certificat de CRT à PEM 
# .crt vers .der 
openssl x509 -outform der -in star_sharp_exemple_com.crt -out 
star_sharp_exemple_com.der 
 
# .der vers .pem 
openssl x509 -inform der -in star_sharp_exemple_com.der -out 
star_sharp_exemple_com.pem