Un incident et des opérations de maintenance sur le site

Posté par (page perso) . Édité par ZeroHeure et Davy Defaud. Modéré par Xavier Claude. Licence CC by-sa.
Tags :
40
24
juin
2018
LinuxFr.org

Hier, le serveur principal de LinuxFr.org a eu un problème qui a nécessité de le redémarrer électriquement. Nous avons également profité d’un peu de temps libre ces derniers jours pour faire diverses opérations de maintenance (détails dans le journal des modifications) :

  • le site est désormais accessible uniquement en HTTPS ;
  • nous avons remplacé le dépôt admin-LinuxFr.org par du Ansible (c’est un travail commencé il y a un bout de temps, mais c’est effectif sur le serveur de production depuis peu) ;
  • nous avons migré le code de Rails 4.2 vers la version 5.2 ;
  • nous avons intégré des contributions externes : merci à nud, seeschloss, voxdemonix et zeroheure !

Il est possible que cela ait entrainé quelques régressions (comme pour l’API OAuth). N’hésitez pas à nous les signaler dans le suivi.

  • # IPv6

    Posté par (page perso) . Évalué à 7.

    Et à quand le support d’IPv6 sur le site ? L’entrée est ouverte depuis 2012 : https://linuxfr.org/suivi/support-ipv6

    • [^] # Re: IPv6

      Posté par (page perso) . Évalué à 10.

      ça fait clairement partie des choses à faire (et attendues). Par contre à court terme, ça vient après 4 mises à jour de distrib à faire, la mise en ligne du repo ansible et la mise au propre de la config Let's Encrypt web/mail (et en parallèle d'une conf pour les RMLL, des travaux autour du RGPD, les 20 ans, et j'en oublie sûrement). Dis autrement, il reste encore un peu de dette technique à apurer, mais ça avance pas mal ces derniers temps.

  • # http >> https

    Posté par (page perso) . Évalué à 2. Dernière modification le 25/06/18 à 01:28.

    Bonsoir, bonjour et tutti quanti,

    Ce n'est pas trop compliqué de passer du http au https ?

    Ça serait intéressant au niveau pédagogique, de publier votre cheminement technique et éthique à ce niveau.
    Sûr que ça intéresserait un grand monde ; moi le premier :-)

    Ceci dit, si vous ne le faîte pas, je le ferai ; force est de constater que je n'aurai plus le choix bientôt :-/

    Pas besoin d'être un pro pour aider la communauté Débiane : utilisez simplement apt-p2p

    • [^] # Re: http >> https

      Posté par (page perso) . Évalué à 9.

      Ce n'est pas trop compliqué de passer du http au https ?

      Le site propose depuis très longtemps du https. C'était à l'utilisateur de taper https://linuxfr.org dans la barre d'adresse de son navigateur s'il voulait accéder au https. Maintenant, nous avons mis en place une redirection de la partie http vers la partie https pour que les utilisateurs accèdent automatiquement en https au site (et il faut que je regarde pour mettre en place du HSTS).

      • [^] # Re: http >> https

        Posté par . Évalué à 4.

        Une remarque et une question.

        La remarque : pour mettre en place HSTS, c'est assez simple. Mozilla fournit un super outil pour configurer son serveur web préféré avec ses versions installées. Ça prend en charge HSTS directement. Et avec ça, on a un beau A+ chez SSL Labs. Je pense qu'il serait aussi intéressant d'ajouter une entrée DNS CAA. C'est assez simple et ça assure un peu plus la sécurité.

        La question : je pensais que pour le renouvellement des certificats Let's Encrypt, il était nécessaire de conserver le http (pour les challenges), apparemment ce n'est pas le cas. Est-ce moi qui me suis trompé ?

        • [^] # Re: http >> https

          Posté par . Évalué à 2. Dernière modification le 25/06/18 à 20:50.

          Je pense qu'il serait aussi intéressant d'ajouter une entrée DNS CAA. C'est assez simple et ça assure un peu plus la sécurité.

          Je découvre CAA et j'ai beau chercher, je n'en vois pas encore l'intérêt. En tout cas du point de vue de la sécurité.
          Apparemment les enregistrements DNS de CAA ne sont pas destinés à être consultés par le navigateur Web mais par l'autorité de certification au moment d'émettre un nouveau certificat pour un domaine.

          Donc le seul intérêt que je vois pour l'instant c'est d'éviter une erreur humaine chez les employés d'une autorité de certification.

        • [^] # Re: http >> https

          Posté par (page perso) . Évalué à 4.

          je pensais que pour le renouvellement des certificats Let's Encrypt, il était nécessaire de conserver le http (pour les challenges), apparemment ce n'est pas le cas. Est-ce moi qui me suis trompé ?

          La dernière fois que j’ai vérifié le protocole ACME n’était pas très clair sur ce point. D’un côté il dit explicitement que le défi http-01 doit passer sur HTTP, pas sur HTTPS, mais de l’autre il dit aussi que les redirections HTTP doivent être suivies, sans exclure explicitement les redirections HTTP→HTTPS (qui ne sont que des redirections HTTP parmi d’autres). Du coup, ces redirections HTTP→HTTPS sont-elles admises ? D’après moi on peut conclure aussi bien « oui » que « non » …

          Et dans le cas où la redirection HTTP→HTTPS est considérée comme admise, le reste du standard ne dit rien quand à la validation du certificat utilisé sur la redirection…

          En pratique, du côté de chez Let’s Encrypt il me semble que leur implémentation a) accepte les redirections HTTP→HTTPS et b) ne vérifie pas dans ce cas le certificat du serveur. De sorte qu’on peut normalement se permettre de rediriger l’intégralité du trafic arrivant sur le port 80 vers le port 443 sans craindre, a priori, de problèmes avec le défi http-01.

          (Cela dit, chez moi, pour être sûr de ne pas avoir de soucis y compris en cas de changement de comportement de l’implémentation de Let’s Encrypt je préfère continuer à tout rediriger sur le port 443 sauf les requêtes pour .well-known/acme-challenge/.)

          • [^] # Re: http >> https

            Posté par (page perso) . Évalué à 4.

            En pratique, du côté de chez Let’s Encrypt il me semble que leur implémentation a) accepte les redirections HTTP→HTTPS et b) ne vérifie pas dans ce cas le certificat du serveur. De sorte qu’on peut normalement se permettre de rediriger l’intégralité du trafic arrivant sur le port 80 vers le port 443 sans craindre, a priori, de problèmes avec le défi http-01.

            Je confirme que c'est le comportement que j'ai observé avec Let's Encrypt.

            « 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: http >> https

            Posté par . Évalué à 3.

            D’après moi on peut conclure aussi bien « oui » que « non » …

            Après avoir fait quelques recherches de mon côté, j'en suis arrivé grosso modo aux mêmes conclusions. La seule chose qui soit complètement impossible en l'état, c'est du HTTPS-Only (c'est-à-dire sans même le port 80 ouvert). Alors que si le HTTP est ouvert et redirige vers le HTTPS, ça a l'air de passer.

            (Cela dit, chez moi, pour être sûr de ne pas avoir de soucis y compris en cas de changement de comportement de l’implémentation de Let’s Encrypt je préfère continuer à tout rediriger sur le port 443 sauf les requêtes pour .well-known/acme-challenge/.)

            Je vais essayer en redirigeant tout et voir ce que ça donne dans quelques mois ;)

            • [^] # Re: http >> https

              Posté par (page perso) . Évalué à 2.

              La seule chose qui soit complètement impossible en l'état, c'est du HTTPS-Only (c'est-à-dire sans même le port 80 ouvert).

              C’était possible avec TLS-SNI-01 qui a été désactivé pour des problèmes de sécurité.

      • [^] # Re: http >> https

        Posté par (page perso) . Évalué à 2.

        (et il faut que je regarde pour mettre en place du HSTS).

        Ha, le classique cordonnier mal chaussé… (la note "on est à jour et blindés" est A+)

        Et dire que le plus dur est fait, il reste juste une entrée de config dans le serveur web et une entrée de config dans le serveur DNS.

        • [^] # Re: http >> https

          Posté par . Évalué à 6. Dernière modification le 25/06/18 à 10:19.

          Ha, le classique cordonnier mal chaussé… (la note "on est à jour et blindés" est A+)

          Remarque, je viens de faire deux tests successifs sur les sites de mes fournisseurs d'électricité et internet, tous les deux sont notés B… dont un avec des vulnérabilités exploitables. Merci à l'équipe de linuxfr pour l'avoir fait et pour continuer de faire mieux! (*trois petits pouces en l'air*)

          • [^] # Re: http >> https

            Posté par (page perso) . Évalué à 1. Dernière modification le 25/06/18 à 11:06.

            Le HSTS c'est pas si bien que ça dans la vraie vie….
            Les mises à jour du certificat ne sont pas toujours garanties, comme cela a pu être expérimenté ici. C'est juste un fait, mettre à jour un certificat même avec des automatismes ce n'est pas garanti à 100%.
            Dans ces cas, le HSTS apporte plus d’inconvénient car interdit de facto un repli fonctionnel en http.

            Ce n'est pas encore assez sec pour vouloir jouer avec le feu (que ce soit dans la vraie vie et linuxfr). De ce que j'ai lu il y a bien d'autres priorités à traiter avant.

            • [^] # Re: http >> https

              Posté par (page perso) . Évalué à 5. Dernière modification le 25/06/18 à 11:29.

              Le HSTS c'est pas si bien que ça dans la vraie vie….

              Ha… On ne parle pas de HPKP la! (qui va être "retiré" car justement on a vu, au contraire de HSTS, que ce n'est pas si bien, car ça merde plus souvent qu'aide, donc "pas si bien que ça dans la vraie vie" là oui).

              Les mises à jour du certificat ne sont pas toujours garanties, comme cela a pu être expérimenté ici.

              Et ça se corrige, dans tous les cas il y a un gros problème car pas mal de monde est en HTTPS, et ici il y a des geeks, si HTTPS merde soit ils ajoutent le certificat en exception comme des gorets car ils se souviennent que c'est le "bon" vieux certificat, soit ils trollent sur Twitter. Mais ça m'étonnerai (en fait j'espère pour eux) qu'ils ne passeront pas en HTTP (sinon c'est super facile de leur refiler un LinuxFr vérolé…)
              En fait le plus dangereux est déjà fait : la redirection automatique.

              Dans ces cas, le HSTS apporte plus d’inconvénient car interdit de facto un repli fonctionnel en http.

              C'est exactement le but que d’empêcher une repli sur HTTP, HTTP n'étant pas sûr.

              Ce n'est pas encore assez sec pour vouloir jouer avec le feu

              HTTPS existe depuis des lustres sur LinuxFr.

              De ce que j'ai lu il y a bien d'autres priorités à traiter avant.

              C'est quelques lignes de conf, ça va prendre trop trop de temps à faire, ou pas.

              A noter que HSTS est un prérequis pour le préenregistrement HTTPS, pour éviter de voir sa page modifiée (genre en enlevant la redirection HTTPS) lors de la première connexion.

              Bref, c'est un choix, un "priorité", mais pour la "complexité" pas la peine de sortir ce genre de raison (le plus risqué est déjà fait), tout comme il n'est pas très pertinent de balancer "c'est pire ailleurs", ça fait excuse foireuse pour ne pas appliquer les "meilleures pratiques" (ça fait douter des compétences d'admin) alors que "ce n'est pas notre priorité et c'est nous qui décidons" ou "on n'a pas pris le temps, c'est bénévole" sont des raisons 100% légitimes pour un serveur géré par des bénévoles.

              • [^] # Re: http >> https

                Posté par (page perso) . Évalué à 10.

                si HTTPS merde soit ils ajoutent le certificat en exception comme des gorets

                Le HSTS n'autorise pas ça, normalement. Il rend impossible de visiter un site s'il n'a pas un certificat valide.

                • [^] # Re: http >> https

                  Posté par (page perso) . Évalué à 5.

                  Je confirme, on avait testé HSTS à l'époque où LinuxFr.org avait un certificat cacert et ça donnait une page blanche sur la plupart des navigateurs.

      • [^] # Re: http >> https

        Posté par (page perso) . Évalué à 0. Dernière modification le 25/06/18 à 17:40.

        Hello,
        Il manque aussi le CAA.
        C'est pas très compliqué à mettre en place…
        A+

    • [^] # Re: http >> https

      Posté par (page perso) . Évalué à 4.

      Depuis ces changements, quand j'ouvre un article depuis le flux RSS (https://linuxfr.org/news.atom), j'arrive sur la page de l'article en mode déconnecté. Si je clique sur « se connecter », il me renvoie sur la page d'accueil en me disant que je suis déjà connecté (et je suis alors bien connecté, mais plus sur la page que je souhaitais).

      Quelqu'un saurait pourquoi ça me fait ça ? J'ai déjà vidé le cache de firefox.

  • # redirection ?

    Posté par . Évalué à 2.

    Bonjour,

    Pour information, lorsque j'essaye de me connecter il y a une redirection vers https://img.linuxfr.org

    La suppression manuelle de img. permet de résoudre le problème… Sinon je ne serai pas là 😅

    • [^] # Re: redirection ?

      Posté par (page perso) . Évalué à 4.

      Je n'arrive pas à reproduire la redirection vers img.linuxfr.org. Est-ce que cela se produit sous un navigateur particulier ? Est-ce pour une page spécifique ou pour toutes les pages ?

      • [^] # Re: redirection ?

        Posté par (page perso) . Évalué à 3.

        J'ai eu pareil. Je crois que c'est le titre de page qui contenait img.linuxfr.org.
        Benoît l'a réparé, mais il allait purger le navigateur pour que ça marche.

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

  • # Ansible

    Posté par . Évalué à 2.

    Avez-vous un repo pour la configuration Ansible?

    • [^] # Re: Ansible

      Posté par (page perso) . Évalué à 3.

      Oui, mais il est privé pour le moment.

    • [^] # Re: Ansible

      Posté par (page perso) . Évalué à 3.

      Il y a un repo pour la configuration Ansible, mais il n'est pas encore public. Maintenant que l'ancien répertoire de scripts d'admin a été remplacé totalement par des scripts Ansible (et utilisé, on va pouvoir publier l'autre proprement. Il reste globalement le README de l'ancien à mettre à jour, et vérifier qu'aucun secret ne sera publié par erreur.

      • [^] # Re: Ansible

        Posté par (page perso) . Évalué à 4.

        et vérifier qu'aucun secret ne sera publié par erreur.

        Il y a git leaks qui aide pour ça.

        « 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: Ansible

      Posté par (page perso) . Évalué à 2.

      Et pourquoi Ansible et pas autre chose ?

  • # Incident toujours en cours

    Posté par (page perso) . Évalué à 3.

    L'API Oauth2 est toujours cassée: https://linuxfr.org/suivi/api-oauth2-cassee

    Incubez l'excellence sur https://linuxfr.org/board/

  • # Il manque un truc là

    Posté par (page perso) . Évalué à 10.

    Un grand nombre de commentaires techniques ici (ce qui a sa valeur), mais j'ai l'impression que quelque chose manque…

    … ah oui !

    Merci pour tout le boulot fait depuis de nombreuse année pour que linuxfr.org soit !

    https://librazik.tuxfamily.org - http://linuxmao.org - https://liberapay.com/trebmuh

  • # Ansible

    Posté par . Évalué à 3.

    nous avons remplacé le dépôt admin-LinuxFr.org par du Ansible (c’est un travail commencé il y a un bout de temps, mais c’est effectif sur le serveur de production depuis peu) ;

    Bravo !

    Gérer les certificats TLS est presque simple, très largement documenté et mis à part un oubli de temps en temps ça n'est, je trouve pas bien compliqué.

    Par contre passer à une maintenance via Ansible, c'est un gros travaille. Pour avoir tenté l'expérience c'est très chronophage d'avoir un playbook qui s'en sort à peu près. C'est long à tester en plus.

    Donc sincèrement bravo pour la maintenance du site et particulièrement pour arriver à faire ce genre de changement que je trouve personnellement laborieux à faire !

Suivre le flux des commentaires

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