LDAPs vs starttls

tbowan

9 Novembre 2020

Le premier est sensé être déprécié au profit du second. C’est ce qu’on dit partout mais qu’est-ce que ça change ?

Tout comme les autres serveurs LDAP, aprè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 :

Subtile… Et le truc, c’est qu’on lit partout que « LDAPs est déprécié » et qu’il faudrait donc lui privilégier starttls. Du coup, on se pose plein de questions… Pourquoi garder LDAPs s’il est moins bien ? Et si c’est un problème de sécurité, c’est 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, Peg+Cat.

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

Dualité, illustration de darksouls1

Pour tout dire, la question s’est posée après une discussion sur twitter et, après avoir trouvé la même affirmation partout sur Internet sans jamais en trouver la justification, je me suis tourné vers la norme officielle et lorsque j’ai enfin trouvé la réponse, je me suis dit que ça vaudrait la peine de le documenter pour les prochains qui se poseront la question.

Divulgâchage : Mis à part quelques subtilités, ils sont en fait aussi sûrs l’un que l’autre.

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

LDAPs

Initialement, dans les années 90, lorsque s’est posée la question de sécuriser LDAP, les gens ont été au plus simple et appliqué la technique habituelle :

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

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 pour le protocole qui sécurise tous les autres) et il a donc fait l’objet de mises à jour régulières. Un renommage au passage plus tard et on utilise maintenant TLS.

Par vieilles habitudes et abus de langage, même si on utilise maintenant exclusivement TLS, on parle encore souvent de SSL, dans les noms, les documentations et les options de configuration. Ne vous y fiez pas, même si on parle de « LDAP dans SSL », si votre système est à jour, c’est bien TLS qui est utilisé.

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é en mai 2020 avec la RFC 2830. Elle introduit une extension du protocole LDAP constituée de la fameuse commande « Start TLS » (qu’on écrit starttls pour faire plus court). 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 passe en TLS et on s’échangera les autres messages dedans ».

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 d’ailleurs 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. »1 Section 6 de la RFC 2830.

Par contre, comme c’est le client qui a l’initiative de la promotion en connexion sécurisée, il faudra configurer le serveur pour refuser les commandes tant que ça n’est pas fait. C’est plus contraignant mais c’est le prix à payer pour une norme, on peut pas tout avoir.

En attendant, 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.

En fait, ça a surtout été communiqué par les éditeurs de logiciels pour justifier la nouvelle option de leur produit. Ils ont poussé cette histoire d’obsolescence auprès de leurs clients et petit à petit, l’idée s’est imposée.

Et maintenant ?

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é.
  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.

Mais en fait, ce seront vos logiciels qui vous dicteront quoi faire suivant leurs possibilités. Suivant leur âge, vous serez peut être bloqué à LDAPs mais maintenant, vous savez que ça ne change rien à la sécurité des connexions.

Et après ?

Vous voilà donc rassuré pour configurer vos systèmes. En attendant d’autres articles sur ce thème, en voici quelques uns qui pourraient vous intéresser…

Configurer LDAPs sur un Active Directory

2 Novembre 2020 Centraliser l’authentification, c’est bien, mais en protégeant ses communications, c’est mieux. Parce que, par défaut, Active Directory n’utilise pas TLS, on va devoir lui fournir un certificat.


  1. « La sécurité gagnée grâce à l’opération Start TLS l’est grâce à TLS lui-même. L’opération Start TLS, en elle-même, ne fourni aucune sécurité additionnelle. » Traduction des arsouyes.↩︎