Post‐mortem de l’incident du 3 juin 2018

50
5
juin
2018
LinuxFr.org

Beaucoup d’entre‐vous s’en sont rendus compte, le certificat X.509 utilisé par LinuxFr.org a expiré ce 3 juin 2018. Retour sur cet incident et sur le renouvellement de ce certificat dans la seconde partie de cette dépêche.

Historique des certificats X.509 sur LinuxFr.org

Jusqu’en 2015, LinuxFr.org était accessible en HTTPS grâce à un certificat X.509 provenant de l’autorité de certification communautaire CAcert. Malgré un fonctionnement communautaire et quelque peu décentralisé plaisant beaucoup à notre équipe, la non‐inclusion de cette autorité de certification dans les navigateurs les plus utilisés devenait un frein à l’accès grand public à LinuxFr.org.

En 2015, le bureau d’enregistrement de noms de domaines (registrar) Gandi a fourni gracieusement à LinuxFr.org un certificat X.509 valable pour tout le domaine linuxfr.org (ce que l’on appelle un wildcard, c.‐à‐d. un certificat dont le sujet est *.linuxfr.org) pour une durée de trois ans. Cette dépêche est d’ailleurs l’occasion de les remercier chaleureusement pour cela.

Trois ans plus tard, nous sommes en 2018. Se pose alors la question de renouveler le certificat.

Chronologie de l’incident

La date d’expiration du certificat offert par Gandi est le 3 juin 2018 à 1 h 59. Le 24 mai, Benoît poste un rappel sur la tribune de modération. Personne n’étant disponible, le certificat expire le 3 juin. Les premières alertes sont données par courriel, en direction de la liste des modérateurs, à partir de 9 h 11. D’autres personnes signalent aussi le problème sur Twitter dans la foulée. Les premiers administrateurs au courant n’ayant pas forcément la possibilité de se connecter immédiatement sur les serveurs pour résoudre la situation, il faudra attendre 10 h avant que quelqu’un puisse le faire.

Deux des administrateurs entrevoient les possibilités :

  • commander un nouveau certificat chez Gandi ;
  • utiliser l’autorité de certification gratuite et automatisée Let’s Encrypt.

Après quelques tergiversations, d’envois de demandes de signature de certificats (CSR) pas forcément bien ficelées, c’est vers Let’s Encrypt que les administrateurs se tournent. Du fait de dépendances légères et de connaissances sur ce logiciel, c’est le client dehydrated qui est utilisé, d’abord sur le serveur alpha (préproduction) puis sur le serveur prod (qui porte bien son nom). Le certificat est généré sur la production à 11 h 28, la fin de l’incident peut donc être déclarée vers 11 h 35. À ce moment‐là, décision est prise de ne pas activer le renouvellement automatique, afin de décider de la pérennisation de Let’s Encrypt une fois tous les administrateurs disponibles.

Le certificat sur prod sera de nouveau généré en début de soirée (20 h 39) pour ajouter une entrée CN (celle de prod lui‐même).

À noter que la priorité étant donnée au service HTTPS, les services de messagerie SMTP ne sont pas modifiés à ce moment‐là. Les courriels continuant d’arriver, cela n’est pas considéré comme prioritaire. Le sujet est néanmoins abordé sur le canal IRC des administrateurs du site et des actions auront lieu sur le sujet.

Leçons et actions futures

Suite à cet incident, on peut retenir :

  • que la communauté autour de LinuxFr.org fait un sacré travail de signalement des incidents :) ;
  • qu’il est important d’avoir plusieurs personnes dans l’équipe qui peuvent intervenir ;
  • qu’il ne faut pas oublier de vérifier les dates d’expiration de certains services critiques (certificats X.509, noms de domaines…).

Les actions actuellement envisagées :

  • un passage permanent à Let’s Encrypt, sur chaque serveur en ayant besoin ;
  • pourquoi pas l’installation d’un serveur de supervision pour alerter l’équipe de ce genre de problème (et d’autres ?).
  • # Acronymes

    Posté par . Évalué à 1 (+8/-9).

    Retour intéressant mais…

    CSR? CN? J'ai pas compris…

    Après recherche: CSR: https://en.wikipedia.org/wiki/Certificate_signing_request
    CN (Common Name) : https://www.ssl.com/faqs/common-name/ ex:linuxfr.org

    Lorsqu'on s'adresse à un public qu'on ne connait pas, on évite d'employer des acronymes ou alors on les explique (encore mieux car c'est formateur)…

  • # Compléments

    Posté par (page perso) . Évalué à 10 (+8/-0). Dernière modification le 05/06/18 à 13:39.

    La correction du www.linuxfr.org a été faite le 4 juin à 22:52 (Paris). (Cette conf un peu inutile du www n'existe pas sur le serveur de dev, et il est facile de l'oublier).

    La correction sur la partie messagerie électronique (postfix/sympa) a été faite le 5 juin à 00:29 (Paris).

    Dix certificats sur quatorze (smtp et https pour les différents domaines) sont à jour actuellement, les quatre derniers étant invisibles de l'extérieur. Et il reste encore un peu de taf pour finaliser l'automatisation de l'installation et du renouvellement (crontab, script ansible, mise à jour de la doc, mise à jour de la FAQ, etc.).

    • [^] # Re: Compléments

      Posté par . Évalué à 3 (+3/-0).

      La correction du www.linuxfr.org a été faite le 4 juin à 22:52 (Paris)

      J'en conclus que le nouveau certificat n'est pas un wildcard comme le précédent. Pourquoi ne pas avoir refait un wildcard ? Est-ce une volonté de l'équipe, ou juste dû au délai un peu court pour corriger le problème ?

      • [^] # Re: Compléments

        Posté par (page perso) . Évalué à 9 (+6/-0). Dernière modification le 05/06/18 à 16:00.

        Wildcard ou pas, ça n'aurait rien changé dans ce cas, c'est juste un autre bloc de config pour le www. pour une redirection, il est caché tout en bas d'un long fichier, et il pointait encore vers l'ancien certificat. Le nouveau certificat était déjà prévu pour linuxfr.org www.linuxfr.org prod.linuxfr.org img.linuxfr.org. Écraser l'ancien certificat avec le nouveau aurait pu éviter le souci par contre (mais dehydrated préfère sans doute avoir son propre répertoire).

        Sinon sur la question du wildcard, c'est mieux de ne pas partager un certificat magique entre tous les serveurs (*), et quitte à avoir un certificat différent par serveur, ce n'est pas plus compliqué de préciser les domaines et d'éviter le wildcard.

        (*) pour au moins deux raisons, la sécurité, et aussi le fait qu'ils vont tous expirer en même temps, comme un dimanche 3 juin par exemple.

        • [^] # Re: Compléments

          Posté par (page perso) . Évalué à 6 (+5/-0).

          Perso, avec Dehydrated, je laisse l’outil stocker les fichiers dans son répertoire à lui, avec ses droits à lui, etc. tout ceci absolument inaccessible de l’internet d’aucune façon que ce soit.

          Puis dans un script « HOOK » de Dehydrated, je fais du déploiement, c’est à dire que je vais placer pour chaque serveur (Exim, HAProxy, Nginx, Prosody…) les fichiers dont il a besoin (privé, publique, mélangé…) de la façon la plus standard possible pour ce serveur (emplacement, nommage), en propriété exclusive de ce serveur et en mode 400.

  • # Merci Dehydrated

    Posté par (page perso) . Évalué à 6 (+5/-0).

    Tiens, moi aussi j’utilise dehydrated !

    Ce client ACME a l’avantage d’être complet, souple et efficace, et suffisamment petit pour que j’aie pu me permettre de lire intégralement le code source avant de l’installer. Un client ACME a en effet des droits non négligeables sur la machine…

    • [^] # Re: Merci Dehydrated

      Posté par (page perso) . Évalué à 8 (+6/-0).

      C'est très bien de pouvoir lire ce genre de code :) D'ailleurs, c'est le but des clients acme-tiny et de mon fork acme-dns-tiny.

      Ce dernier n'a d'ailleurs besoin que de très peu de droits sur la machine locale (en gros, lire la clé ACME et le CSR), mais doit pouvoir gérer les entrées DNS "_acme_challenge.*" sur une machine distante.

  • # regarder ses emails

    Posté par . Évalué à 4 (+3/-0).

    qu’il ne faut pas oublier de vérifier les dates d’expiration de certains services critiques (certificats X.509, noms de domaines…).

    à rephraser: "qu'il faut prendre en compte des emails de rappels envoyé automatiquement par la plupars des services commerciaux". Quite à se créer une adresse mail d'équipe avec des crédentials partagés (bitwarden, …).

    Ce genre d'erreur est classique et ça aurait pu être pire (vol du domaine, etc).

    • [^] # Re: regarder ses emails

      Posté par . Évalué à 3 (+3/-0).

      dans ma boite on gere plusieurs centaine de certificat, il y a 1 personne qui est chargé de suivre tout le cycle de vie de tous les certificats (privée ou publique)
      pour mon périmètre j'ai un ptit script qui m'envoie un mail quand un certificats expire moins d'un mois, ca me laisse le temps de le renouveller tranquillement ( en le demandant a celui qui gere tous les certificats)

  • # Supervision

    Posté par (page perso) . Évalué à 4 (+2/-0).

    pourquoi pas l’installation d’un serveur de supervision

    Otez moi d'un doute … dlfp n'est pas déjà monitoré ?

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Supervision

      Posté par (page perso) . Évalué à 6 (+3/-0).

      Le minimum est fait : courbes de charge serveur, mémoire et réseau, plus les vérifications périodiques des conteneurs lxc, des processus, des ports en écoute et des flux TCP/UDP connus/inconnus. Plus la très efficace supervision par les utilisateurs (nous y compris).

      • [^] # Re: Supervision

        Posté par (page perso) . Évalué à 4 (+2/-0).

        Si ça vous intéresse (et en échange d'un email de contact) je peux vous mettre un check_http sur un des icinga que j'administre. Ça peut notamment vérifier la date de validité des certs TLS.

        Adhérer à l'April, ça vous tente ?

        • [^] # Re: Supervision

          Posté par (page perso) . Évalué à 3 (+1/-0).

          Let's Encrypt envoie un courriel de rappel 20 jours avant l'expiration.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: Supervision

            Posté par (page perso) . Évalué à 4 (+2/-0).

            Mouais, sauf que :

            • l'email donné à l'inscription n'est pas nécessairement lu avec attention
            • les certificats re-générés* ne sont pas pris en compte donc ça fait plein de faux positifs
            • c'est du mailchimp donc faut que ça arrive à bon port

            [*] Typiquement, tu veux ajouter un domaine à un cert, donc tu le regénères avec tous les domaines inclus, plus le nouveau. LE ne reconnais pas la parenté entre l'ancien et le nouveau et à l'échéance de l'ancien tu te fais spammer.

            Adhérer à l'April, ça vous tente ?

            • [^] # Re: Supervision

              Posté par (page perso) . Évalué à 3 (+1/-0).

              Merci des précisions ! Je surveille ça d'un peu trop loin.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Supervision

                Posté par (page perso) . Évalué à 5 (+3/-0).

                Beh basiquement, c'est infiniment plus fiable pour détecter une panne de faire une requête proche de celle que ferait un usager lambda. Le script check_http ne fait pas tout, loin de la, mais te permet de tester depuis un bout arbitraire de l'internet si ton serveur répond (tu peux contrôler le code), s'il répond la bonne page (tu peux chercher un string ou une regex), et s'il répond avec un certificat qui n'a pas expiré.

                Le courriel de letsencrypt en comparaison c'est pipo.

                Adhérer à l'April, ça vous tente ?

            • [^] # Re: Supervision

              Posté par (page perso) . Évalué à 4 (+3/-0).

              Merci pour ces infos. Je me demande : qu’est-ce qu’implique le fait que ce soit du Mailchimp ? Est-ce que cette entité que je ne connais pas (et qui, je le crains, pourrait être source de pubs et spam…) connait ainsi la liste exhaustive de tous les admins utilisateurs de Let’s Encrypt ?

              • [^] # Re: Supervision

                Posté par (page perso) . Évalué à 4 (+2/-0).

                Autant pour moi c'est mandrill.com ; pas mailchimp.

                Est-ce que cette entité que je ne connais pas (et qui, je le crains, pourrait être source de pubs et spam…) connait ainsi la liste exhaustive de tous les admins utilisateurs de Let’s Encrypt ?

                A priori oui. Il faut s'en remettre à leur déontologie.

                Adhérer à l'April, ça vous tente ?

    • [^] # Re: Supervision

      Posté par . Évalué à 3 (+1/-0).

      La supervision est faite par la communauté :)

      • [^] # Re: Supervision

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Beh elle a échoué à prévenir que le certificat échouerait dans 2 semaines. :)

        Adhérer à l'April, ça vous tente ?

        • [^] # Re: Supervision

          Posté par . Évalué à 4 (+2/-0).

          D’autres personnes signalent aussi le problème sur Twitter dans la foulée.

          En fait j'avais compris que des gens avaient alerté linuxfr en avance, mais en relisant la phrase effectivement c'est arrivé après.

          Je ne vous jette pas la pierre, à chaque expiration de mon certificat j'ai la même chose (toujours des surprises avec le renouvellement auto let's encrypt + flemme).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.