Arès avoir configuré notre Active Directory pour utiliser TLS, il est maintenant joignable de manière sécurisée. Pour être exact, je devrais plutôt dire « de deux manières sécurisées » :

• En LDAPs : sur le port 636, en faisant du LDAP à travers du TLS,
• Avec starttls : sur le port 389, en faisant du TLS à travers du LDAP.

Subtile.

Le truc, c’est qu’on lit partout que « LDAPs est déprécié » et qu’il faudrait lui privilégier starttls. Du coup, on se pose plein de questions… Pourquoi avoir gardé LDAPs s’il est moins bien ? Mais vu que c’est de la sécurité, c’est forcément important ! Mais pourquoi garder LDAPs dans ce cas ? Donc c’est qu’il a quelque chose de mieux !? Mais quoi ???

Je sens que je vais paniquer !

Peg, dans Peg+Chat

En y réfléchissant, est-ce que ça ne serait pas un peu « bonnet blanc, blanc bonnet » cette histoire ?

Pour tout dire, la question s’est posée après une discussion sur twitter. On a eu beau chercher partout sur Internet, on trouvait bien cette affirmation mais jamais sa justification. On a finalement trouvé le fin mot de l’histoire et on s’est dit que ça vaudrait la peine de le documenter pour que les prochains y perdent moins de temps à chercher.

Remerciements : @xhark (à l’origine de blogmotion.fr) pour l’idée et la discussion qui a suivi.

LDAPs

Initialement (dans les années 90) lorsqu’on s’est posé la question de sécuriser LDAP, les ingénieurs ont été au plus simple et appliqué la technique habituelle :

Établissons un tunnel sécurisé avec SSL et faisons passer LDAP dedans. Et on ajoute un s à l’acronyme pour montrer que c’est sécurisé.

Les ingénieurs

Et paf, on a inventé LDAPs.

Pour faire ça, le serveur ouvre un autre port (le 636). Le client s’y connecte et après une phase de négociation SSL tout ce qu’il y a de plus classique, les deux s’échangeront les messages LDAP sans plus avoir à se soucier de ces détails cryptographiques.

Les protocoles ayant leurs petites maladies, on a ensuite découvert des vulnérabilités dans SSL (c’est plutôt gênant) qu’on a corrigé dans une nouvelle version qu’on a profité pour renommer en TLS. Par vieilles habitudes et abus de langage, on parle encore souvent de SSL alors même qu’on fait du TLS…

Le problème, c’est que cette méthode n’a jamais été normalisée. Les gens l’ont mise en place dans un espèce de joyeux consensus anarchiste dont Internet a le secret. Et au bout du compte, ça marchait plutôt bien.

Sauf que sans « version officielle du mythe » chacun pourrait y aller de sa petite variante.

Starttls

En toute franchise je vois mal comment un empilement aussi classique que LDAP à travers TLS pourrait être mal adapté au point d’en être incompatible avec d’autres implémentations mais la nature a horreur du vide…

Vide comblé par l’IETF en mai 2020 avec sa RFC 2830. Elle introduit une extension du protocole LDAP constituée de la fameuse commande « Start TLS » (qu’on écrit starttls). C’est plein de détails techniques, forcément, mais je vais vous faire la version simplifiée :

Au début d’une connexion LDAP normale, le client dit qu’à partir de maintenant, on crée un canal TLS et on s’échangera les autres messages LDAP dedans.

RFC 2830 (version simple)

C’est donc pareil qu’avant sauf qu’au lieu d’ouvrir un port TCP dédié, on réutilise le même que pour LDAP (389).

La norme elle-même reconnaît que cette nouvelle méthode n’ajoute rien de plus qu’une connexion TLS classique :

All security gained via use of the Start TLS operation is gained by the use of TLS itself. The Start TLS operation, on its own, does not provide any additional security.¹

Section 6 de la RFC 2830

Une norme de l’IETF ayant meilleure allure qu’un arrangement d’admins sur un coin de table cosmique, LDAPs a été considéré comme dépréciée au profit de starttls.

Par contre, comme c’est le client qui envoie cette commande, il faut configurer le serveur pour refuser de répondre tant que le client n’envoie pas starttls (sinon, ça passerait en clair). C’est dommage et bien plus contraignant que de changer de port TCP mais c’est le prix à payer pour une norme, on peut pas tout avoir.

Si vous voulez notre avis, cette histoire d’obsolescence de LDAPs s’est imposée par les éditeurs de logiciels pour justifier la super nouvelle option trop sécurisée de leur produit.

Et après ?

Comme vous l’avez vu, les deux méthodes sont cryptographiquement équivalentes et fournissent donc le même niveau de sécurité. La différence est donc à chercher dans les petits détails…

1. D’un côté, starttls. Si vous privilégiez la normalisation. Les risques d’incompatibilités sont sûrement très faibles mais c’est toujours ça de gagné. Pensez à configurer le serveur pour refuser les commandes avant de recevoir starttls.
2. De l’autre, LDAPs. Si vous préférez établir d’emblée des connexions TLS sans devoir toucher au serveur. Une restriction de port dans le pare-feu et vous être tranquille, personne ne pourra communiquer en clair.

En fait, ce sera votre logiciel client qui vous dictera quoi faire. Suivant ses possibilités, vous serez peut être contraint à utiliser l’une des deux méthodes. Mais maintenant, vous savez que ça ne change rien à la sécurité des connexions.