Très bel article sur le Hanno' blog.
Voici après une traduction rapide en Français: (et il donne les commandes à rajouter dans /etc/apache2/mods-available/ssl.conf pour avoir avec Apache un site qui fonctionne systématiquement, même en cas de panne du serveur OCSP Stapling (OCSP Stapling sera alors désactivé - ok ce n'est pas idéal comme comportement mais cela évite ce qui s'est passé sur LaFibre.info hier)
Le problème avec OCSP Stapling, ou pourquoi la révocation d'un certificat n'est pas fiable
Aujourd'hui , les serveurs OCSP de Let’s Encrypt étaient hors-ligne pendant un certain temps. Cela a causé beaucoup plus de problèmes qu'il ne l'aurait dû, car en théorie, nous avons toutes les technologies disponibles pour gérer un tel incident. Cependant, en raison des échecs dans la façon dont ils sont mis en œuvre, ils ne fonctionnent pas vraiment.
Nous devons comprendre certains antécédents. Les connexions cryptées utilisant le protocole TLS, comme les certificats HTTPS. Ce sont essentiellement des clés publiques cryptographiques, avec une déclaration signée d'une autorité de certification qui appartiennent à un certain nom d'hôte.
CRL et OCSP - deux technologies qui ne fonctionnent pas.
Les certificats peuvent être révoqués. Cela signifie que, pour une raison quelconque, le certificat ne devrait plus être utilisé. Un scénario typique est lorsque le propriétaire d'un certificat apprend que ses serveurs ont été piratés et que leurs clés privées ont été volées. Dans ce cas, il est bon d'éviter que les clés volées et leurs certificats correspondants puissent encore être utilisés. Par conséquent, un client TLS comme un navigateur devrait vérifier qu'un certificat fourni par un serveur n'est pas révoqué.
C'est au moins la théorie. Cependant, l'historique de la révocation des certificats est une histoire de deux technologies qui ne fonctionnent pas vraiment.
Une méthode pour vérifier si un certificat est révoqué est la certificate revocation lists (CRL). C'est assez simple: une autorité de certification fournit une liste de certificats qui sont révoqués. Cela a une limitation évidente: ces listes sont de grande taille. Étant donné qu'une vérification de révocation doit se produire au cours d'une connexion, il est évident que cela n'est pas réalisable de télécharge la liste complète.
La deuxième méthode s'appelle OCSP (Online Certificate Status Protocol). Ici, un client peut interroger un serveur sur l'état d'un certificat unique et obtenir une réponse signée. Cela évite le problème de taille des CRL, mais il a encore un certain nombre de problèmes. Étant donné que les connexions devraient être rapides, il est très coûteux (en temps) pour un client de se connecter à un serveur OCSP pendant chaque connexions. Cela pose également des problèmes pour la confidentialité : L'opérateur d'un serveur OCSP récupère beaucoup d'informations.
Cependant, il y a un problème plus grave: que se passe-t-il si un serveur OCSP n'est pas disponible? Du point de vue de la sécurité, on pourrait dire qu'un certificat qui ne peut pas être vérifié OCSP doit être considéré comme non valide. Cependant, les serveurs OCSP sont trop peu fiables. Donc, pratiquement tous les clients implèmentent OCSP en mode soft fail (ou pas du tout). L'échec doux signifie que si le serveur OCSP n'est pas disponible, le certificat est considéré comme valide.
Cela rend tout le concept OCSP inutile: si un attaquant essaie d'abuser d'un certificat volé et révoqué, il peut simplement bloquer la connexion au serveur OCSP - et donc un client ne peut pas apprendre qu'il est révoqué. En raison de cette panne de sécurité inhérente, Chrome a décidé de désactiver totalement le contrôle OCSP. Comme solution de contournement, ils ont quelque chose appelé CRLsets et Mozilla a quelque chose de similaire appelé OneCRL, qui est essentiellement une grande liste de révocation, pour les révocations importantes gérées par le fournisseur du navigateur. Toutefois, il s'agit d'une solution de contournement faible qui ne couvre pas la plupart des certificats.
L'agrafage OCSP (en anglais : OCSP Stapling) à la rescousse
Il existe deux technologies qui pourraient résoudre ceci: OCSP Stapling (agrafage OCSP en Français) et OSCP Must-Staple.
OCSP Stapling déplace l'interrogation du serveur OCSP du client vers le serveur web. Le serveur web obtient les réponses OCSP puis les envoie dans la poignée de main TLS. Cela présente plusieurs avantages: il y a un gain important de latence en évitant pluisuers aller/retour et un gain de confidentialité. Cela permet également de survivre aux courts arrêts des serveurs OCSP, car un serveur web TLS peut mettre en cache les réponses OCSP (elles sont habituellement valides pendant plusieurs jours).
Cependant, cela ne résout pas encore le problème de sécurité: si un attaquant a un certificat volé et révoqué, il lui suffit de ne pas mettre l'agrafage OSCP. Le navigateur ne le saurera pas et interroge le serveur OCSP directement, cette demande peut encore être bloquée par l'attaquant et le navigateur acceptera le certificat.
Par conséquent, une extension pour les certificats a été introduite qui nous permet d'exiger l'agrafage OSCP. Il est généralement appelé OCSP Must-Staple et est défini dans la RFC 7633 (bien que la RFC ne mentionne pas le nom OSCP Must-Staple, ce qui peut causer une certaine confusion). Si un navigateur voit un certificat avec l'extension OCSP Must-Staple, qui est utilisé sans OCSP Stapling, il ne doit pas l'accepter.
Nous devrions donc être bien. Avec OCSP Stapling, nous pouvons éviter les problèmes de latence et de confidentialité de OCSP et nous pouvons éviter d'échouer, lorsque les serveurs OCSP ont des temps d'arrêt courts. Avec OCSP Must-Staple, nous réparons les problèmes de sécurité. Plus de problème logiciel, n'est-ce pas ?
Les implèmentations OCSP Stapling d'Apache et Nginx sont incorrectes.
Eh bien, voici les implèmentations. Bien que beaucoup de protocoles utilisent TLS, le cas d'utilisation le plus courant est le Web et HTTPS. Selon les statistiques html de Netcraft, la plus grande partie des sites actifs sur Internet utilisent le servuer web Apache (environ 46%), suivi de Nginx (environ 20%). côté du serveur, ce n'est que l'agrégation OCSP Stapling, car OCSP Must Staple doit uniquement être vérifié par le client.
Qu'attendez-vous d'une implèmentation OPSP Stapling opérationnelle ? Elle devrait essayer d'éviter une situation où il n'est pas possible d'envoyer une réponse OCSP valide. Ainsi, un serveur web devrait récupérer une réponse OCSP valide dès que possible et la mettre en cache jusqu'à ce qu'il en voie une nouvelle (ou qu'elle expire). Le serveur web devrait en outre essayer d'obtenir une nouvelle réponse OCSP bien avant que l'ancienne expire (idéalement plusieurs jours). Autre chose : il ne faut jamais jeter une réponse OSCP valide, à moins que le serveur web en ait récupéré une nouvelle qui est valide. Le développeur de Google, Ryan Sleevi, a écrit une description détaillée de la façon dont une implèmentation OCSP Stapling appropriée devrait ressembler.
Le serveur web Apache ne fait rien de tout cela.
Si Apache essaie de renouveler la réponse OCSP et obtient une erreur du serveur OCSP - par exemple, parce qu'il ne fonctionne pas actuellement - il éliminera la réponse OCSP actuelle et toujours valide pour la remplacera par l'erreur. Il enverra ensuite des erreurs OCSP agrafées, ce qui n'a aucun sens. Dans ce cas là, Firefox affichera une erreur et bloquera le chargement du site. Cela a été signalé en 2014 et n'est toujours pas fixé.
Maintenant, il existe une option dans Apache pour éviter ce comportement: SSLStaplingReturnResponderErrors. Il est par défaut. Si vous l'éteignez (off), vous n'obtiendrez pas un comportement sain (c'est-à-dire utiliser la réponse en cours encore en cours) : Apache désactive l'agrafage tant qu'il reçoit des erreurs du serveur OCSP. C'est mieux que d'envoyer des erreurs, mais évidemment, il faut désactiver OCSP Must Staple.
Cela devient encore plus fou. J'ai réglé SSLStaplingReturnResponderErrors à off, mais ce matin, j'ai toujours des plaintes d'utilisateurs de Firefox, voyaient des erreurs. C'est parce que dans ce cas, le serveur OCSP n'èmettait pas d'erreurs, il était complètement indisponible. Pour cette situation, Apache dispose d'une fonctionnalité qui va envoyer une erreur "tryLater" au client. Cela n'a aucun sens: l'erreur "tryLater" d'OCSP est inutile dans TLS, car vous ne pouvez pas essayer plus tard (la poignée de main qui ne peut pas dépasser quelques secondes).
Ceci est contrôlé par une autre option: SSLStaplingFakeTryLater. Cependant, la documentation dit: "Uniquement efficace si SSLStaplingReturnResponderErrors est également activé." Donc, si nous avons désactivé SSLStaplingReturnResponderErrors, cela ne devrait pas fonctionner, n'est-ce pas? Eh bien: la documentation est incorrecte.
Il y a encore d'autres problèmes: Apache n'obtient pas les réponses OCSP lors du démarrage, il ne les récupère que pendant la poignée de main. Cela provoque une latence supplèmentaire sur la première connexion et augmente le risque d'arriver dans une situation où vous n'avez pas une réponse OCSP valide. Les réponses OCSP mises en cache ne survivent pas aux redémarrages du serveur, elles sont conservées dans un cache en mémoire.
Il n'existe actuellement aucun moyen de configurer Apache pour gérer implèmentation OCSP Stapling appropriée. Voici la configuration Apache que j'utilise, qui s'assurera au moins que cela n'èmettra pas d'erreurs et mettra en cache les réponses un peu plus longtemps que par défaut:SSLStaplingCache shmcb:/var/tmp/ocsp-stapling-cache/cache(128000000)
SSLUseStapling on
SSLStaplingResponderTimeout 2
SSLStaplingReturnResponderErrors off
SSLStaplingFakeTryLater off
SSLStaplingStandardCacheTimeout 86400Je suis moins familier avec le serveur web Nginx, mais de ce que j'entends, ce n'est pas beaucoup mieux. Selon blog.crashed.org, il ne récupère pas les réponses OCSP au démarrage et enverra les premières connexions TLS sans agrafage OCSP Staging, même si OCSP Staging est activé. Voici une publication sur le blog qui recommande de contourner cela en se connectant à tous les hôtes configurés après le démarrage du serveur.
Pour résumer: c'est tout un gros désordre. Les serveurs web Apache et Nginx ont tous deux des implèmentations OCSP Staging qui sont incomplètes. Tant que vous utilisez l'un ou l'autre, le fait d'activer OCSP Must-Staple est un moyen de vous tirer sur le pied et d'avoir des problèmes. Ne l'activez pas, si vous prévoyez d'utiliser Apache ou Nginx.
La révocation d'un certificat n'est pas fiable. C'est le cas depuis l'invention de SSL et c'est encore le cas aujourd'hui. OCSP Stapping et OCSP Must-Staple devrait permettre de fiabiliser les révocations, mais cela nécessiterait des implèmentations fonctionnelles et stables dans les produits serveur les plus utilisés.Source :
Hanno' blog, le 19 mai 2017. Traduit de l'Anglais par Vivien Guéant.
Protocoles réseaux sécurisés (https)