Journal ovh.fr , exemple de ce qu'il ne faut pas faire avec un certificat

Posté par  . Licence CC By‑SA.
Étiquettes :
8
29
août
2020

Je suis actuellement au Québec, donc quand je vais sur ovh.com je suis redirigé sur la version canadienne du site (avec tarifs en dollars &co). Naïvement je me suis dit qu'en tapant ovh.fr j'arriverais sur la version destinée à la France. Surprise !

Warning: Potential Security Risk Ahead

Firefox detected an issue and did not continue to ovh.fr. The website is either misconfigured or your computer clock is set to the wrong time.

En fait http://ovh.fr redirige vers https://www.ovhtelecom.fr/ mais le certificat de https://ovh.fr a expiré depuis le 08/08/2020… OK je dois faire partie de la minorité qui tape encore ses URL plutôt que de passer par Google mais un certificat expiré depuis 21 jours je trouve que ça la fout mal pour "le géant français du Cloud Computing"

  • # Bug dans les explications

    Posté par  . Évalué à 9.

    Soit tu as une extensions du genre HTTPS everywhere, soit tes explications manquent d'un caractère. Parce http://ovh.fr redirige (via un 302) vers https://www.ovhtelecom.fr, mais du coup, le certificat d'ovh.fr n'est pas impliqué dans l'histoire. Il faut taper https://ovh.fr pour avoir le problème.

    « 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: Bug dans les explications

      Posté par  . Évalué à 8. Dernière modification le 29 août 2020 à 19:19.

      J'ai raté un truc là. Tu répètes (j'ai l'impression) ce que j'ai écrit. Sans le 's' ça redirige correctement mais en tapant https ça bloque à cause du certificat expiré.

      [EDIT] OK je crois avoir compris, ma phrase Naïvement je me suis dit qu'en tapant ovh.fr n'est effectivement pas précise. J'ai réécrit l'adresse https://ovh.com en changeant com en fr donc oui j'avais bien conservé le s

      Dans tous les cas il me semble qu'il vaudrait mieux renouveler le certificat et appliquer aussi la redirection pour https://ovh.fr pour éviter les surprises

      • [^] # Re: Bug dans les explications

        Posté par  . Évalué à 9. Dernière modification le 29 août 2020 à 21:22.

        Dans tous les cas il me semble qu'il vaudrait mieux renouveler le certificat et appliquer aussi la redirection pour https://ovh.fr pour éviter les surprises

        Oui, bien sûr, ce n'était pas le but de mon commentaire de dire qu'il ne fallait pas renouveller. C'est juste que j'ai tenté de reproduire et que je n'ai pas eu le problème.

        « 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

  • # effectivement

    Posté par  . Évalué à 5.

    c'est un peu expiré :/

    mais bon, un gars dans ma boite oublie tout les 3, 4 ans de suivre quelques certificats qui expire gentiment. Et a chaque fois il ajoute une alarme dans outlook un post it qqpart pour ne plus jamais oublier :) et un nouveau fichier excel qqpart

    pour les miens j'ajoute une date de garantie dans notre logiciel, du coup cela ressort 3 mois avant l'expiration, vu que nous gerons les fin de garanties materiel à 3 mois. pour le moment ca marche plutot bien :)

    • [^] # Re: effectivement

      Posté par  . Évalué à 9.

      Je préfère avoir un Nagios pour tester que tout est ok au niveau HTTPS, surtout avec les certificats letsencrypt.org gérés par acme.sh

    • [^] # Re: effectivement

      Posté par  . Évalué à 7.

      mais bon, un gars dans ma boite oublie tout les 3, 4 ans

      C’est pour ça (en plus des avantages pour la sécurité) qu’il faut arrêter de gérer des certificats avec une validé aussi longue, et c’est pour ça qu’il y a beaucoup de propositions visant à imposer aux CA d’émettre des certificats avec des durées de validé de plus en plus courtes.

      • [^] # Re: effectivement

        Posté par  (site web personnel) . Évalué à 4.

        J'aime beaucoup le "c'est pour ça".
        Donc, si la durée de validité est 4 fois plus courte, il n'y aura pas 4 fois plus de loupés?
        Par quelle magie?

        • [^] # Re: effectivement

          Posté par  . Évalué à 10.

          Si tu te plante pour ce que tu dois faire tous les 4 ans, tu va tenter de t'améliorer.
          Si tu te plante pour ce que tu dois faire toutes les semaines, tu va t'améliorer.

          Plus quelques chose pose problème, plus il faut le faire fréquemment, c'est comme ça qu'on se donne les moyens de le corriger.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: effectivement

            Posté par  . Évalué à 3.

            Oui, d’ailleurs nos systèmes d’exploitation devraient forcer une perte de données tous les deux jours pour s’assurer qu’on sait restaurer les sauvegardes et on devrait refaire nos configs de Vim et d’Emacs tous les trois jours pour garantir qu’on sait bien les refaire.

            Effectivement, on aurait très vite tous des recettes Ansible pour refaire nos réglages de manière automatique, et on survivrait à de tels choix en améliorant notre technique. Mais je ne suis pas d’accord avec « Plus quelques chose pose problème, plus il faut le faire fréquemment ». La démarche non-shadok consiste plutôt à limiter les problèmes. Automatiser la mise à jour des certificats est une excellente chose pour éviter les mauvaises surprises et règle bien des problèmes, mais ce n’est pas une raison pour rendre la vie plus dure à ceux qui ne font pas les choses aussi bien.

            • [^] # Re: effectivement

              Posté par  . Évalué à 4.

              La démarche c'est quand tu identifie un problème de ce genre, si tu souhaite l'adresser tu réduit les temps de cycles. C'est une démarche volontaire. Letsencrypt permet de le faire, mais ce n'est pas une obligation, il est toujours possible de payer ton certificat tous les 2 ans et de faire à la main sa mise à jour. Mais il est très difficile de corriger un problème qui survient tous les n mois.

              Il faut à minima déclencher des actions fake ce qui revient au même. Personne n'a dit qu'il fallait être idiot. Il faut le faire en intelligence. L'idée c'est juste que ce qui est généralement mal fait et/ou fait peur peut généralement être fortement améliorer si on arrête de remettre la question à dans 4 ans.

              Après on peut considérer acceptable d'avoir un temps d'indispo avec une si faible fréquence (et je dis sa sans sarcasme).

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: effectivement

              Posté par  . Évalué à 5. Dernière modification le 31 août 2020 à 14:27.

              Oui, d’ailleurs nos systèmes d’exploitation devraient forcer une perte de données tous les deux jours pour s’assurer qu’on sait restaurer les sauvegardes

              Certains d’entre nous le font : Chaos engineering.

        • [^] # Re: effectivement

          Posté par  . Évalué à 2.

          Si je comprends bien ce que veut dire Arcaik, le fait d'avoir une date anniversaire est plus facile à retenir ou à inscrire sur un calendrier d'alertes. Une action plus fréquente devient aussi un automatisme de pensée.
          C'est comme pour LetsEncrypt, au début les gens vont louper puis le renouvellement va s'ancrer dans une routine.

        • [^] # Re: effectivement

          Posté par  . Évalué à 5.

          Si ton certificat n'est valide que 15 jours, tu vas très vite automatiser la generation des certificats, parce que t'as autre chose a faire tous les 15 jours.
          Et du coup, t'as vachement moins de chances d'avoir un problème.

          C'est aussi beaucoup plus dur de valider que le renouvellement automatique d'un certificat valide 4 ans fonctionne bien, vu qu'il faut attendre 3.8 ans pour s'assurer que la tache démarre.
          Sans compter qu'après 4 ans, ya des grandes chances que pour la stack de gestion de l'infra ait suffisamment changée pour douter que la tache en question va toujours fonctionner. Ou que le mec qui a mit un reminder dans son calendrier bosse plus la, ou que l'alerte nagios/sensu/whatever ait été supprimée/perdue dans une migration.

          Le "c'est pour ça" est un peu bizarre, mais ce qu'il veut dire c'est que changer les certificats tous les mois en fait une tache régulière qui a beaucoup moins de chance d'être oubliée/foirée vu que les équipes le font souvent.
          C'est du meme tonneau que "si les deployments sont douloureux ou risqués, c'est que tu déploies pas assez souvent".

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: effectivement

            Posté par  . Évalué à 3.

            Le "c'est pour ça" est un peu bizarre

            Je sais pas, le commentaire auquel je répond disait en substance : « mon collègue oublie toujours de renouveler les certificats au bout de 4 ans », bah, c’est en autre pour cette raison qu’il y a des gens qui poussent pour que les certificats ne puisse pas être émis avec une durée de validité aussi longue.

  • # comportement navigateur

    Posté par  . Évalué à 0.

    Les navigateurs ont un comportement récent :

    Je veux aller sur http://ovh.fr et bien si le navigateur connaît le site en https alors le celui-ci va aller d'abord sur https://ovh.fr

    Aussi pour certain domaine il faut absolument passer par https, c'est le cas de .dev que j'utilisais en local pour mes devs avant que Google n'ait la gestion du LTD et en impose le https

    https://get.dev

    Du coup, pour m'en sortir, quand j'ai un doute, je check avec curl…

    • [^] # Re: comportement navigateur

      Posté par  . Évalué à 7.

      Suis pas spécialiste mais ça ressemble à HSTS

      • [^] # Re: comportement navigateur

        Posté par  . Évalué à 2.

        pour .dev oui

        "Your security is our priority. The .dev top-level domain is included on the HSTS preload list, making HTTPS required on all connections to .dev websites and pages without needing individual HSTS registration or configuration. Security is built in."

    • [^] # Re: comportement navigateur

      Posté par  . Évalué à 4.

      c'est le cas de .dev que j'utilisais en local pour mes devs

      Utiliser .local posera probablement moins de problème, il n'est pas sensé être routé sur internet.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: comportement navigateur

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Utiliser .local posera probablement moins de problème, il n'est pas sensé être routé sur internet.

        Ça n'a pas l'air d'être si simple que ça, en fait…

        • [^] # Re: comportement navigateur

          Posté par  . Évalué à 3.

          Ça n'a pas l'air d'être si simple que ça, en fait…

          Justement les distributions sont configurées pour ne pas effectuer de requête DNS pour ce TLD.

          Je veux bien que ce ne soit pas une bonne pratique, c'est réservé au mCAST pour bonjour, mais à l'heure actuelle, il y a le besoin et aucune bonne solution. Donc à moins de vouloir te payer un nom de domaine pour ça, ici pour ton cas d'usage tu n'a aucun des problèmes décrit par Bortzmeyer :

          • pas de fuite sur le réseau (note que {bidule}.exemple.com a ce problème là)
          • usage local à une machine donc pas aussi structurant qu'un déploiement d'entreprise

          Si un jour l'IETF a mieux à proposer, tu pourra y passer assez facilement.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: comportement navigateur

            Posté par  . Évalué à 4. Dernière modification le 31 août 2020 à 11:10.

            Donc à moins de vouloir te payer un nom de domaine pour ça

            Et de bien tout configurer pour que ça ne fuite pas.

            « 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: comportement navigateur

        Posté par  (Mastodon) . Évalué à 2. Dernière modification le 31 août 2020 à 11:11.

        Quelle est la difficulté d'avoir son propre domaine à soit ? Aucune. Je ne comprends pas qu'il y ait encore des devs à s'emmerder avec des .dev et .local quand tu peux avoir ton domaine pour le prix de 4 bières ou un paquet de clope par an.

        • [^] # Re: comportement navigateur

          Posté par  . Évalué à 3.

          Payer et renouveler un domaine uniquement pour s'assurer que personne d'autres ne l'utilisera c'est beaucoup de gestion face à l'usage en question.

          Devoir aller enregistrer un nom dans DNS pour un usage purement local est assez fou.

          Ça demande une configuration de garantir l'absence de fuite (tu n'a pas particulièrement envi de voir des requêtes sur ces domaines transiter sur le réseau).

          Après il est toujours possible d'utiliser localhost

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: comportement navigateur

          Posté par  . Évalué à 1.

          Les serveur DNS de free, ou autres, ne retournent pas des enregistrements qui pointe vers des ip du réseau local…

          Aussi MON .dev existait AVANT que Google ne me le vole ;)

  • # j'ai signalé le pb https://ovh.fr expiré

    Posté par  . Évalué à 1.

    Je l'ai fait sur twitter, on m'as parlé d'une prise en charge, si j'ai un retour j'indiquerais ce journal comme découvreur… ;)

    Ce jour c'est toujours pas réglé c'est quand même dingo

Suivre le flux des commentaires

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