Quelqu'un se rend compte que Let's Encrypt propose des certificats dont la durée de validité est de 90 jours, mais qu'en fait, la vraie validité est de 90 jours PLUS une seconde.
L'explication grossière, c'est que les certificats ont des champs notBefore et notAfter définis à la seconde près, et que le champ notAfter est calculé en faisant notBefore + 90 jours. Façon classique de faire, mais là ça ne marche pas parce que l'intervalle ]notBefore, notAfter[ est défini comme étant un intervalle ouvert par la norme, ce qui veut dire que le certificat est valide pour toute la seconde de la date notAfter. Pas de bol, les outils de linting / vérification auto étaient configurés pour vérifier que la duré de validité des certificats ne dépassait pas... deux cent et quelques jours. On est loin des 90 jours attendus.
Et du coup, après des années de fonctionnement comme ça sans que personne ne s'en rende compte, une équipe chez Let's Encrypt travaille en pleine nuit, dans l'urgence, pour rectifier le problème en faisant notAfter := notBefore + (90 jours - 1 seconde) pour les nouveaux certificats produits. Une très longue et verbeuse discussion s'en suit avec l'équipe conformité des autorités de certification de Mozilla sur le rapport d'incident chez eux.
Je comprends que c'est, formellement, un problème de sécurité / conformité à résoudre, mais j'ai du mal à voir les implications réelles, et imaginer des cas où ça peut poser problème en pratique, et par conséquent à comprendre pourquoi on fait travailler une équipe de nuit dans l'urgence pour un tel problème qui parait relativement bénin. D'autant qu'à un moment dans cette très longue discussion, une personne se demande « ah mais au fait vous avez pensé aux secondes intercalaires ? » pour que plus tard personne ne sache vraiment si les implémentations garantissent en pratique une granularité aussi fine que la seconde. En parallèle, on sent que les personnes ayant rédigé le rapport sont passablement agacées par le fait que du coup, elles sont obligées de spécifier des paramètres en secondes et plus en heures ou en jour, et plus tard dans les commentaires des gens se demandent si notAfter ne devrait pas être excluant et donc être renommé en un truc du genre before ou quelque chose comme ça.
J'ai l'impression que pour que l'incident pose réellement un problème de sécurité, il faudrait que un certificat affecté ait été volé, et là les attaquants pouvent exploiter le certificat compromis... 1 seconde de plus, à supposer que les implémentations sont aussi fine que ça ? Ou je suis complètement à côté de la plaque ?
Enfin bon, c'est un off-by-one amusant, et c'est un bon exemple de rapport d'incident auprès de l'équipe de conformité CA chez Mozilla facile à comprendre.
Beaucoup de mots pour un décalage d'une seconde (parce que bien sûr ça révèle des problèmes de procédures / vérifs, du coup), c'est là que finalement tu te rends compte que ton autorité de certification n'est probablement pas trop mal si elle en est à ce niveau de problème.
# Résumé
Posté par raphj (site web personnel) . En réponse au lien Let's Encrypt: certificate lifetimes 90 days plus one second. Évalué à 10. Dernière modification le 16 juin 2021 à 19:05.
Quelqu'un se rend compte que Let's Encrypt propose des certificats dont la durée de validité est de 90 jours, mais qu'en fait, la vraie validité est de 90 jours PLUS une seconde.
L'explication grossière, c'est que les certificats ont des champs
notBeforeetnotAfterdéfinis à la seconde près, et que le champnotAfterest calculé en faisantnotBefore+ 90 jours. Façon classique de faire, mais là ça ne marche pas parce que l'intervalle]notBefore, notAfter[est défini comme étant un intervalle ouvert par la norme, ce qui veut dire que le certificat est valide pour toute la seconde de la datenotAfter. Pas de bol, les outils de linting / vérification auto étaient configurés pour vérifier que la duré de validité des certificats ne dépassait pas... deux cent et quelques jours. On est loin des 90 jours attendus.Et du coup, après des années de fonctionnement comme ça sans que personne ne s'en rende compte, une équipe chez Let's Encrypt travaille en pleine nuit, dans l'urgence, pour rectifier le problème en faisant
notAfter := notBefore + (90 jours - 1 seconde)pour les nouveaux certificats produits. Une très longue et verbeuse discussion s'en suit avec l'équipe conformité des autorités de certification de Mozilla sur le rapport d'incident chez eux.Je comprends que c'est, formellement, un problème de sécurité / conformité à résoudre, mais j'ai du mal à voir les implications réelles, et imaginer des cas où ça peut poser problème en pratique, et par conséquent à comprendre pourquoi on fait travailler une équipe de nuit dans l'urgence pour un tel problème qui parait relativement bénin. D'autant qu'à un moment dans cette très longue discussion, une personne se demande « ah mais au fait vous avez pensé aux secondes intercalaires ? » pour que plus tard personne ne sache vraiment si les implémentations garantissent en pratique une granularité aussi fine que la seconde. En parallèle, on sent que les personnes ayant rédigé le rapport sont passablement agacées par le fait que du coup, elles sont obligées de spécifier des paramètres en secondes et plus en heures ou en jour, et plus tard dans les commentaires des gens se demandent si
notAfterne devrait pas être excluant et donc être renommé en un truc du genrebeforeou quelque chose comme ça.J'ai l'impression que pour que l'incident pose réellement un problème de sécurité, il faudrait que un certificat affecté ait été volé, et là les attaquants pouvent exploiter le certificat compromis... 1 seconde de plus, à supposer que les implémentations sont aussi fine que ça ? Ou je suis complètement à côté de la plaque ?
Enfin bon, c'est un off-by-one amusant, et c'est un bon exemple de rapport d'incident auprès de l'équipe de conformité CA chez Mozilla facile à comprendre.
Beaucoup de mots pour un décalage d'une seconde (parce que bien sûr ça révèle des problèmes de procédures / vérifs, du coup), c'est là que finalement tu te rends compte que ton autorité de certification n'est probablement pas trop mal si elle en est à ce niveau de problème.