Posté par raphj .
É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 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.
Posté par gUI (Mastodon) .
Évalué à 6.
Dernière modification le 16 juin 2021 à 19:25.
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 ?
À priori ça doit être ça oui.
Mais un truc que j'ai appris avec la sécurité, c'est que tu auras toujours moins d'imagination que un attaquant, voire moins de moyens (là où tu passes quelques jours à implémenter/tester, lui peut y passer des mois si la carotte en vaut le prix). Donc quand tu laisses un truc ouvert, que ce soit facile ou dur à exploiter n'est pas un critère : ferme-le.
Et là on ne parle pas d'une application quelconque qui laisserait une faille de 1 secondes (boarf, c'est bon, ça va le faire), là on parle d'un système de sécurité, voire DU système de sécurité du Web qui a une faille de 1 seconde. Je pense que pour ces gens-là, c'est tout simplement inadmissible (et ils ont vraisemblablement raison).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Je suis bien d'accord qu'il ne faut pas laisser des failles de sécurités connues pour le plaisir. Mais la question, est-ce que ça valait la peine de corriger ça dans l'urgence.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Posté par raphj .
Évalué à 4.
Dernière modification le 16 juin 2021 à 19:55.
Oui, on parle d'un problème présent depuis les débuts de Let's Encrypt si j'ai bien compris, donc depuis cinq-six ans, donc quelques heures de plus…
Après, je comprends qu'on demande à une autorité d'être impeccable niveau temps de réponse et réactivité. J'imagine que dans ce milieu, ça la fout mal que dans un rapport d'incident, tu dises « ouais, ben on a été se coucher et on a étudié l'affaire qui impacte nos XXX millions de certificats actuellement valides le lendemain matin tranquilou bilou ».
Et je comprends aussi que dans ce domaine, on a besoin de gens attachés aux règles et aux procédures et à leur application stricte.
# Résumé
Posté par raphj . É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.
[^] # Re: Résumé
Posté par gUI (Mastodon) . Évalué à 6. Dernière modification le 16 juin 2021 à 19:25.
À priori ça doit être ça oui.
Mais un truc que j'ai appris avec la sécurité, c'est que tu auras toujours moins d'imagination que un attaquant, voire moins de moyens (là où tu passes quelques jours à implémenter/tester, lui peut y passer des mois si la carotte en vaut le prix). Donc quand tu laisses un truc ouvert, que ce soit facile ou dur à exploiter n'est pas un critère : ferme-le.
Et là on ne parle pas d'une application quelconque qui laisserait une faille de 1 secondes (boarf, c'est bon, ça va le faire), là on parle d'un système de sécurité, voire DU système de sécurité du Web qui a une faille de 1 seconde. Je pense que pour ces gens-là, c'est tout simplement inadmissible (et ils ont vraisemblablement raison).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Résumé
Posté par claudex . Évalué à 7.
Je suis bien d'accord qu'il ne faut pas laisser des failles de sécurités connues pour le plaisir. Mais la question, est-ce que ça valait la peine de corriger ça dans l'urgence.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Résumé
Posté par raphj . Évalué à 4. Dernière modification le 16 juin 2021 à 19:55.
Oui, on parle d'un problème présent depuis les débuts de Let's Encrypt si j'ai bien compris, donc depuis cinq-six ans, donc quelques heures de plus…
Après, je comprends qu'on demande à une autorité d'être impeccable niveau temps de réponse et réactivité. J'imagine que dans ce milieu, ça la fout mal que dans un rapport d'incident, tu dises « ouais, ben on a été se coucher et on a étudié l'affaire qui impacte nos XXX millions de certificats actuellement valides le lendemain matin tranquilou bilou ».
Et je comprends aussi que dans ce domaine, on a besoin de gens attachés aux règles et aux procédures et à leur application stricte.
[^] # Re: Résumé
Posté par claudex . Évalué à 8.
Non, mais tu peux dire "pas d'exploitation connue pour le moment, on prend le temps de réfléchir pour corriger ça proprement"
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Résumé
Posté par Anonyme . Évalué à 3.
Oui, parce que ça permet de prouver que tu respectes bien les procédures en vigueur en tant que CA.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.