Let's Encrypt continue de supporter OSCP, notamment pour rester compatible avec MS… Mais ils annoncent leur intention de l'arrêter dès possible, c'est à dire dès que MS ne le rendra plus obligatoire, ce qu'ils estiment à 6 à 12 mois, mais ça ne reste que leur avis.
En pratique, c’est tout moisi parce que ça ne marche pas bien : sa prise en charge par les serveurs est affreuse, les navigateurs sauf Firefox s’en tapent…
En pratique, c'est tout moisi parce que ça ne marche pas bien : sa prise en charge par les serveurs est affreuse, les navigateurs sauf Firefox s'en tapent…
# Trop rapide, petit scarabée !
Posté par aiolos . Évalué à  3 (+1/-0).
Let's Encrypt continue de supporter OSCP, notamment pour rester compatible avec MS… Mais ils annoncent leur intention de l'arrêter dès possible, c'est à dire dès que MS ne le rendra plus obligatoire, ce qu'ils estiment à 6 à 12 mois, mais ça ne reste que leur avis.
Ils recommandent donc pour l'instant aux utilisateurs de faire en sorte de ne plus dépendre de OSCP, mais ils n'en arrêtent pas encore le support !
# Résumé, et incertitudes sur Must-Staple
Posté par raphj . Évalué à  10 (+14/-0). Dernière modification le 28 juillet 2024 à 00:04.
D'abord, un petit résumé (edit: wou pinaise, pas si petit, déso) pour celles et ceux qui ne seraient pas familier avec le concept dont il est question, perso je n'en aurais jamais entendu parlé si je n'administrais pas moi même des site web donc je pense que ça peut être utile.
Pour sécuriser les connexions avec HTTPS, il faut un certificat qui dit "c'est bon, ce site web est bien servi par serveur vérifié, et la page n'a pas été modifié". Ce certificat est délivré par une autorité dont le navigateur (ou plus généralement le client HTTPS) fait confiance, et Let's Encrypt est l'une d'elle. C'est même la plus grosse aujourd'hui en termes de sites couverts.
Mais les certificats peuvent être révoqués, par exemple parce qu'ils ont été compromis. 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.
Problèmes :
C'est pour ces raisons que Let's Encrypt veut se débarrasser d'OCSP.
En plus :
Il y a des parades :
Pour sécuriser les connexions avec HTTPS, il faut un certificat qui dit « c’est bon, ce site web est bien servi par serveur vérifié, et la page n’a pas été modifié ». Ce certificat est délivré par une autorité en laquelle le navigateur (ou plus généralement le client HTTPS) fait confiance, et Let's Encrypt est l’une d’elles. C’est même la plus grosse aujourd’hui en termes de sites couverts.
Mais les certificats peuvent être révoqués, par exemple parce qu’ils ont été compromis. 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.
Problèmes :
C’est pour ces raisons que Let's Encrypt veut se débarrasser d’OCSP.
En plus :
Il y a des parades :
Actuellement, la situation n’est pas très rose :
L’article 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 :
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.
été révoqué très récemment - au navigateur.
- 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.
- CRL et CRLite, un mécanisme proposé par Mozilla où les navigateurs téléchargent la liste des certificats révoqué à 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.
- un temps de renouvellement très court des certificats. 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.
Actuellement, la situation n'est pas très rose :
L'article 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 :
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.
[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par raphj . Évalué à  7 (+5/-0).
Gros bug d'édition, j'ai dupliqué des paragraphes… si l'équipe de modération veut bien corriger ça ce serait le top. Désolé pour le loupé.
[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par abriotde (site web personnel, Mastodon) . Évalué à  3 (+2/-0).
Ce n'est pas très grave on comprend vite qu'il y a du doublon et on passe à la suite.
Par contre l'explication est super-utile…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par devnewton 🍺 (site web personnel) . Évalué à  3 (+0/-0).
Quel est le texte à mettre ? C'est pas évident de savoir ce qui a été coupé / dupliqué :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par sebas . Évalué à  2 (+0/-0). Dernière modification le 28 juillet 2024 à 08:37.
Selon moi, c'est ça :
1)
la preuve que le certificat n'a pas
[D’abord, un petit résumé (…) la preuve que le certificat n’a pas]été révoqué très récemment - au navigateur.2)
peu pressé que ça arrive.
[été révoqué très récemment - au navigateur (…) peu pressé que ça arrive.]<EoF>[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par Jean-Baptiste Faure . Évalué à  4 (+2/-0).
Ce serait bien de reprendre ce commentaire dans un journal.
[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par raphj . Évalué à  3 (+1/-0).
Ouais, ok, je vais essayer de faire ça ! Merci pour la suggestion. Et ça « règlera » le bug.
Je ne vois pas comment indiquer efficacement les corrections à apporter au commentaire sans devoir reposter entièrement le bon contenu de toute façon. L'espace de rédaction ne permet que d'envoyer des petits messages sur une ligne, ce n'est pas adapté.
[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par jseb . Évalué à  2 (+0/-0).
Merci pour l'explication. Pour le doublon, ce n'est pas grave, j'ai mieux compris en relisant :-)
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par Zenitram (site web personnel) . Évalué à  2 (+1/-1).
Corrige moi si je me trompe, mais ça ne me semble pas des plus gênant, avec "must staple" qui arrive :
- Dans un premier temps, en palliatif l'admin fait (manuel ou automatisé) des premières requêtes au redémarrage, tout en remontant le bug ou "+1" sur le bug ouvert pour dire que ça devient prioritaire
- Dans un deuxième temps, l'update qui ne doit pas être le plus long à faire (il semble qu'il a le principal déjà la) est déployée (et ça devrait aller vite pour les gens qui utilisent "must staple" car ils sont à la pointe)
Donc il me semble que c'est surtout qu'il faut s'y lancer et qu'il n'y a pas besoin de chercher une "meilleure" solution, on l'a, non?
[^] # Re: Résumé, et incertitudes sur Must-Staple
Posté par raphj . Évalué à  5 (+3/-0).
J'ai un palliatif en place, à base de cron qui lance des requêtes régulièrement, mais ce n'est pas totalement fiable :
Dès qu'on redémarre manuellement nginx après un changement de config, c'est niqué. Peut-être qu'on peut déclencher des actions avec systemd après le redémarrage d'un service. À creuser ! Ou pas, si ça disparait bientôt…
Pour faire proprement, il faudrait certainement garder trace de l'expiration de l'agrafe et faire la requête au bon moment juste après l'expiration et espérer qu'aucune requête ne s'est glissée entre temps. Le problème, c'est que l'agrafe n'est mise à jour que quand elle est expirée, donc tu as beau faire des requêtes souvent, ça va quand même échouer entre l'expiration et la prochaine requête… si elle arrive assez tôt.
l'alternative imparfaite, c'est de bourriner et lancer des requêtes vraiment très souvent à intervalle très court et quand-même espérer que des requêtes n'arrivent pas au bon moment.
Concernant le bug nginx, si j'ai bien compris, les dev nginx considèrent que la perf est plus importante et que cette requête à faire avant de répondre, c'est pénible, et apparemment ça demande une réarchitecture majeur, ou en tout cas beaucoup de boulot, donc c'est pas sûr qu'on voit le bug corrigé de sitôt. Ça fait déjà des années que les gens se plaignent.
Peut-être que quelqu'un pourrait fournir un patch, mais il faudrait déjà que les devs d'nginx soient convaincus que c'est une bonne idée.
Et au final, si ça disparait bientôt au profit d'une « meilleure » solution, peut-être autant pas trop s'embêter…
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.