Journal Fin d’OCSP chez Let’s Encrypt : quid ?

Sommaire

• Contexte
  • Certificat X.509 et autorité de certification
  • Let’s Encrypt
  • Validation du certificat
• OCSP - Online Certificate Status Protocol, pour vérifier qu’un certificat n’est pas révoqué
  • Des défauts plus ou moins critiques
  • Must-Staple – ça aurait pu être bien
• Alternatives à OCSP
  • Certificate Revocation Lists – CRL et CRLite
  • Petite durée de validité
• Une situation pas très rose

Récemment, Let’s Encrypt a annoncé leur intention d’arrêter prochainement leur service OCSP, et cette annonce a été partagée sous la forme d’un lien sur LinuxFr.

Cette annonce mérite démystifications, explications et est l’occasion de parler un peu de ces concepts, en particulier pour celles et ceux qui ne seraient pas familiers avec OCSP ou même comment toute cette infrastructure de confiance fonctionne. Je l’avais un peu fait dans un commentaire complètement buggué, et on m’a suggéré d’en faire un journal. Je prends enfin le temps de m’en occuper. Si vous aviez déjà lu mon commentaire, vous avez l’essentiel, j’ai juste réparé le gros bug d’édition et enrobé et nettoyé un peu.

Petit avertissement avant de commencer : je suis loin d’être expert dans ce domaine, j’ai juste un peu l’habitude de ces choses parce que j’administre un certain nombre de sites web. Mais c’est ça qui est bien, j’imagine :-). Mais donc il pourrait y avoir des inexactitudes, des petites erreurs voire des pans entiers de fiction dans ce journal. Je compte sur vous pour les relever et crier respectueusement dans les commentaires.

Contexte

Avant de se lancer tête baissé dans OCSP, on fait une petite piqûre de rappel sur ce qu’est un certificat, et sur Let’s Encrypt.

Certificat X.509 et autorité de certification

On parle souvent de « certificat SSL ». C’est, pour simplifier, une attestation numérique émise par une autorité de certification qui « prouve » à un usager d’internet que son correspondant, généralement un serveur web, mail, XMPP ou autre a bien l’identité qu’il prétend avoir. Le correspondant dit « Je suis le serveur web tournant à l’adresse example.com, voici d’ailleurs le certificat produit par l’Autorité Machin en laquelle tu fais confiance ».

Les détails de comment le certificat est produit et est récupéré sont hors sujet de ce journal déjà trop long, surtout parce que je suis presque totalement ignorant en la matière, mais en gros la personne qui gère le serveur fait une demande auprès de l’autorité de certification pour obtenir un certificat pour un nom de domaine donné, l’autorité fait une vérification plus ou moins manuelle ou automatique sur le fait que la personne qui demande le certificat contrôle bien le nom de domaine concerné, et émet le certificat avec une durée de validité plus ou moins longue, après laquelle le certificat expire et ne peut plus être utilisé.

Dans le monde du web, on utilise le certificat pour sécuriser les connexions avec HTTPS. Le certificat permet de dire au navigateur « C’est bon, ce site web est bien servi par ce serveur vérifié », et le tout permet aussi de garantir l’intégrité et la confidentialité des échanges.

Let’s Encrypt

C’est une de ces autorités de certification. C’est un organisme à but non lucratif apparu en 2015. À cette période, beaucoup de sites étaient servis à travers HTTP en clair sans chiffrement, surtout les sites un peu moins gros :

• Les spécifications du Web demandant à ce qu’on ait un certificat valide pour utiliser le chiffrement
• Les certificats étaient généralement payants. Il y avait des solutions gratuites mais assez imparfaites, notamment :
  • StartCom / StartSSL, mais avec des limitations, en particulier une durée de validité de 3 ans combinée à des frais de révocation - pas top pour garantir la sécurité, ça décourage la révocation, et ça avait particulièrement posé question pour les certificats touchés par Heartbleed. Cette autorité s’est tuée en se faisant racheter secrètement par WoSign, qui avait perdu la confiance des navigateurs suite à des mauvaises pratiques, et donc a perdu elle-même leur confiance à cause du rachat.
  • CACert, une autorité de certification communautaire qui n’est pas reconnu par la plupart des navigateurs sur la plupart des systèmes d’exploitation. Ce qui veut dire qu’en pratique, on avait le choix entre un site non sécurisé sans avertissement, ou un site sécurisé mais avec un gros avertissement menaçant.
• Leur gestion peu pratique car manuelle (il fallait aller se connecter sur le site web de l’autorité de certification, sortir sa carte de crédit, faire des manipulations techniques sur le DNS, télécharger des fichiers, les transférer sur le(s) serveur(s), retrouver la procédure pour mettre à jour le certificat, et ne pas oublier de se mettre un rappel pour dans 1, 2 ou 3 ans pour recommencer. Une galère, quand on a juste besoin d’un certificat de base et qu’on n’a pas besoin de validation d’identité poussée qui demanderait de toute manière des vérifications manuelles (des certificats à validation d’organisation (OV), validation individuelle (IV), validation étendue (EV)).

Let’s Encrypt arrive avec un protocole qu’elle standardise, ACME, permettant de faire cette fameuse vérification de manière automatique, et de renouveler les certificats automatiquement aussi, simplifiant grandement la gestion des certificats, et en plus émet des certificats gratuitement. Cette gratuité et cette simplification démocratise HTTPS (HTTP sécurisé), dont l’utilisation explose.

Let’s Encrypt est aujourd’hui la plus grosse autorité de certifications en termes de sites couverts. Elle est financée par un grand nombre de boites plus ou moins grosses, et par des dons.

Validation du certificat

Quand on arrive sur un site web servi en HTTPS, on se retrouve donc avec un certificat à valider.

Pour valider un certificat, il faut entre autres :

• Vérifier les dates de début et fin de validité du certificat. Si c’est dans le passé ou dans le futur, ce n’est pas bon (oui, c’est pour ça que quand votre appareil n’est pas à l’heure, beaucoup de choses cassent).
• Reconnaitre l’autorité de certification qui l’a émis. Sinon, aucune chance que ça passe. C’est le problème qu’avait CACert, qui, avant l’arrivée de Let’s Encrypt, émettait des certificats mais n’était pas reconnu par la plupart des navigateurs sur la plupart des systèmes d’exploitation. Les éditeurs des principaux navigateurs web ont mis des règles en place pour qu’un organisme soit reconnu comme autorité de certification, ça demande de passer des audits, de réagir rapidement aux problèmes, d’avoir des processus robustes et sécurisés, de ne pas émettre des certificats aux mauvaises entités, ne pas antidater, etc.
• Vérifier que le certificat n’a pas été révoqué. Il arrive parfois qu’un certificat doive être révoqué, quand ils ont été compromis ou qu’un risque existe : on trouve une faille dans le processus de vérification de l’autorité de certification, ou, plus probablement, la partie privée du certificat a fuité ; on ne peut et doit donc plus faire confiance à ce certificat.

Ce dernier point nous amène enfin au cœur du sujet.

OCSP - Online Certificate Status Protocol, pour vérifier qu’un certificat n’est pas révoqué

OCSP permet de vérifier qu’un certificat n’a pas été révoqué. Pour cela, le navigateur peut aller interroger une URL au moment de la première visite d’un site web depuis un certain temps pour aller voir si c’est le cas.

Des défauts plus ou moins critiques

OCSP demande une infrastructure coûteuse chez l’autorité de certification, qui doit répondre à beaucoup de requêtes et doit avoir un uptime en béton. Eh oui, que se passe-t-il si cette infra tombe / que des requêtes OCSP échouent ? On laisse passer ou on casse le site avec un avertissement inquiétant ou obscure à l’utilisateur ?

Ce mécanisme pose aussi des problèmes de confidentialité et de vie privée : l’autorité de certification sait alors que telle personne a visité tel site. Elle n’a pas besoin de garder de logs (et Let’s Encrypt s’efforce de ne pas garder les traces), mais elle est toujours susceptible d’être interrogée par des services de renseignements, et toutes les autorités ne sont pas aussi tatillonnes sur la protection de la vie privée, et même, on ne devrait pas avoir besoin de faire confiance à une autorité pour ça.

C’est pour ces raisons que Let’s Encrypt veut se débarrasser d’OCSP.

On ajoute à cela des problèmes de performance et d’adoption: lors de la première visite d’un site, il faut attendre que la requête OCSP termine avant d’afficher le site, donc ça ralenti la navigation. Et en pratique, parmi les navigateurs répandus, seul Firefox fait cette vérification (c’est optionnel, et activé par défaut).

Must-Staple – ça aurait pu être bien

L’option Must Staple lors de la demande d’un certificat permet d’éviter au navigateur de faire une requête OCSP lors de la première visite à un site. Le serveur web doit alors, lui, faire la requête, et fournir « l’agrafe » – la preuve que le certificat n’a pas été révoqué très récemment – au navigateur. Ça résout d'une pierre deux coups les problèmes de confidentialité, et d'utilisation des ressources du service OCSP. En tout cas, ça aurait pu.

En pratique, les serveurs répandus n’implémentent pas bien ce mécanisme. Notamment, Nginx ne fait la demande OCSP qu’après la première requête vers un site après son démarrage (ou après l’expiration des données OCSP), et cette requête part alors sans l’agrafe, ce qui fait échouer la vérification. Apache 2 n’est pas meilleur. Et cela nécessite des contournements et bidouilles aussi infâmes qu’incomplètes.

Alternatives à OCSP

Certificate Revocation Lists – CRL et CRLite

CRL et CRLite, un mécanisme proposé par Mozilla où les navigateurs téléchargent la liste des certificats révoqués à intervalle régulier (4 fois par jour par exemple), avec des techniques de compression et de mises à jour incrémentales de fou pour que ça soit réalisable. Plus besoin alors d’OCSP si le navigateur sait déjà quel certificat est révoqué. Mais ce n’est pas encore en place.

Petite durée de validité

Un temps de renouvellement très court des certificats permet de limiter fortement la nécessité de pouvoir les révoquer. Si ton certificat a une durée de validité de 7 jours ou moins, finalement il y a beaucoup moins besoin de le révoquer. Mais ce n’est pas encore très répandu.

Une situation pas très rose

SSL Labs, qui fournit un diagnostic pour évaluer la qualité de la sécurisation de son site, pousse à mettre en place Must Staple pour avoir un score parfait.

En théorie, c’est une bonne chose, parce que ça respecte mieux la vie privée des utilisateurs et c’est mieux au niveau des performances et de l’utilisation des ressources communes (chaque client n’a pas à faire sa requête OCSP, le serveur le fait pour tout le monde). En pratique, c’est tout moisi parce que ça ne marche pas bien : sa prise en charge affreuse par les serveurs, les navigateurs sauf Firefox s’en tapent…

L’annonce de Let’s Encrypt sur son intention d’arrêter leur service OCSP dit que les gens qui hébergent des sites web ne sont pas concernés par ce changement, mais ce n’est pas tout à fait vrai : on ne sait pas encore comment cette option « Must Staple » sera gérée, et les solutions envisagées ont des inconvénients :

1. L’option pourrait être simplement ignorée. Le certificat sera créé, ça va continuer à marcher, juste qu’il n’y aura plus Must Staple ». Ça veut dire que si le système dépendait de ce mécanisme, ça va casser, et ça peut casser silencieusement. Mais au moins, la livraison des certificats va continuer à fonctionner sans changement partout où ça n’importe pas tellement.
2. L’option pourrait causer un échec de certificat. Dans ce cas, ce sera clair ce qu’il se passe, par contre ça va obliger plein de gens à déboguer et mettre à jour une configuration qui vivait toute seule depuis potentiellement longtemps.

De mon côté, je ne sais pas ce que je préférerais. Peut-être que les navigateurs adoptent un truc comme CRL, ou que les certificats aient encore une durée de validité plus courte, pour rendre OCSP et Must-Staple inutiles.

Ce qui est sûr, c’est que ça résoudra mes problèmes de gestion cassée de Must-Staple par Nginx sans devoir me poser la question de si je dois désactiver ça. Peut-être que SSL Labs mettra aussi à jour son diagnostic pour arrêter de pousser cette option. Au moins, si elle ne fonctionne plus, la question ne se pose plus. Donc je suis un peu pressé que ça arrive.