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 :
Ça demande une infrastructure coûteuse chez l'autorité de confiance, qui doit répondre à beaucoup de requêtes et doit avoir un uptime en béton.
que se passe-t-il si cette infra tombe ? On laisse passer ou on casse le site ?
ça pose des questions de vie privée : l'autorité de confiance 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.
En plus :
ça ralentit cette première visite
En pratique, parmi les navigateurs répandus, seul Firefox fait cette vérification
Il y a des parades :
l'option Must Staple lors de la demande d'un certificat, qui bloque ce mécanisme de demande à l'infrastructure OCSP au niveau du navigateur. Le serveur web doit alors lui faire la requête, et fournir "l'agrafe" - la preuve que le certificat n'a pas D’abord, un petit résumé pour celles et ceux qui ne seraient pas familiers avec le concept dont il est question, perso je n’en aurais probablement jamais entendu parler si je n’administrais pas moi-même des sites 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é 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 :
Ça demande une infrastructure coûteuse chez l’autorité de confiance, 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 ?
ça pose des questions de vie privée : l’autorité de confiance 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.
En plus :
ça ralentit cette première visite, puisqu’il faut attendre que cette requête OCSP termine avant d'afficher le site
En pratique, parmi les navigateurs répandus, seul Firefox fait cette vérification
Il y a des parades :
l’option Must Staple lors de la demande d’un certificat, qui bloque ce mécanisme de demande à l’infrastructure OCSP au niveau du navigateur. 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.
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.
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 :
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 par les serveurs est affreuse, les navigateurs sauf Firefox s’en tapent...
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 :
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.
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.
é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 :
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 par les serveurs est affreuse, les navigateurs sauf Firefox s'en tapent...
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 :
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.
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.
# Résumé, et incertitudes sur Must-Staple
Posté par raphj (site web personnel) . En réponse au lien Let's Encrypt ne proposera plus OCSP pour des raisons de privacité. Évalué à 10. 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.