Journal À quand l'HTTPS par défaut sur LinuxFR ?

Posté par . Licence CC by-sa
29
14
fév.
2017

Bonjour'nal

Jusqu'à présent pour mouler sur LinuxFR de manière sécurisée avec mon copain TLS on est obligé d'utiliser les services de l'EFF, on est maintenant en 2k17 et ça nous déçois un peu…
Administrateurs, si vous nous lisez ne voulez-vous pas déposer une petite redirection 301 de http://linuxfr.org vers https://linuxfr.org ?

Si non, voulez-vous bien éclairer ma lanterne fort cabossée ? Qu'est-ce qui serait limitant pour forcer HTTPS aujourd'hui ?

La bise.

  • # Mon opinion

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

    Sur les sites web que je gère (donc pas DLFP). http -> connexion anonyme. https -> connexion identifié DÈS le reverse proxy sur un annuaire LDAP. Pas une ligne de Python exécuté avant que l'identification soit faites.

    Je ne sais pas comment faire aussi clean et aussi simple en mettant tout en https…

    • [^] # Re: Mon opinion

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

      Les choix liés à la sécurité ne devraient pas être une affaire d'opinion mais de connaissances solides, ça évitera qu'on voit des banques/assurances/startups/administrations/que-sais-je se faire trouer tous les jours.

      Pas une ligne de Python exécuté avant que l'identification soit faites.

      Aucun rapport avec le fait d'utiliser HTTPS ou pas.

      http -> connexion anonyme

      Et ta page de login ? Par définition, ton utilisateur est anonyme au moyen où il/elle envoie gentiment son login/password en vadrouille sur les réseaux vers ton serveur. Merci pour eux, maintenant tout le Starbucks connaît leurs identifiants (et leur FAI, et ton FAI, et bien d'autres…, et la NSA bien-sûr ;)).

      https -> connexion identifié

      Dans le cas d'un Man in the Middle (quelqu'un intercepte tout ce qui passe entre le navigateur de ton utilisateur et ton serveur), le méchant fait croire au navigateur que le serveur parle HTTP, il communique avec ton serveur en HTTPS si ça te fait plaisir, mais en chemin il voit tout ce qui passe, et ni toi ni le navigateur ne se doutent de quoi que ce soit… Un bon moyen d'empêcher ça, c'est de dire au navigateur qu'il ne doit accepter rien d'autre que du HTTPS de ta part. (cf une réponse plus bas)

      Je ne sais pas comment faire aussi clean et aussi simple en mettant tout en https…

      Au contraire, tout est on ne peut plus simple et clean ! Tu communiques uniquement en HTTPS. Point final. Comment ça pourrait être moins simple ? Un petit coup de HSTS et de Public Key Pinning, et tu es au top (ou tout cas bien mieux que l'immense majorité des sites webs).

      • [^] # Re: Mon opinion

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

        (Hors-sujet : on peut plus éditer ses commentaires ? Je ne trouve plus le bouton…)
        En relisant le commentaire auquel je répondais, j'ai l'impression d'avoir peut-être mal compris ce que l'auteur voulait dire par "connexion anonyme" et "connexion identifié". S'il repasse par là, j'aimerai bien une clarification.

        • [^] # Re: Mon opinion

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

          Visiteur anonyme, sans session avec authentification, donc sans envoi de login/pass, https ou non, d'autant que la personne ou le bot n'a peut-être même pas de compte sur le site. Versus un utilisateur qui se logue sur le site.

          • [^] # Re: Mon opinion

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

            Exact. Anonyme => pas d'identification.

            Via reverse proxy, si tu as un site SPIP, tu rediriges le /ecrire vers le site en HTTPS, si tu as un site Wordpress, tu rediriges le /wp-admin en https…

            Bref, en http, pas de login/pass, pas de chiffrement. C'est de la consultation et bon pour les robots. Dès qu'il y a un couple login/pass, cela bascule en https avec authentification dès le reverse proxy (donc avant l’exécution de code python ou php). Je ne suis pas un spécialiste de la sécurité mais je me dis que minimiser le nombre de ligne de code et simplifier les choses ne peuvent pas faire de mal. Mais attention, ce sont des modules intégrés de base dans Apache qui font le boulot et si je ne peux avoir confiance en eux, je peux presque arrêter mes sites web…

            Et j'ai pas de traceur de stat sur mes sites. On me le demande parfois mais je renvoie ces personnes vers l'écriture de nouvelles pages !

            • [^] # Re: Mon opinion

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

              Via reverse proxy, si tu as un site SPIP, tu rediriges le /ecrire vers le site en HTTPS, si tu as un site Wordpress, tu rediriges le /wp-admin en https…

              En fait, tu tiens à protéger ton espace privé, mais une interception de flux pour remplacer le contenu du site public par un autre ne te dérangerait pas ? Note que cette attaque peut aussi retirer ta redirection du /ecrire vers le site en HTTPS, et du coup remplacer l'espace privé par n'importe quoi d'autre.

              • [^] # Re: Mon opinion

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

                Normalement, en http, il ne devrait pas y avoir de droit d'écriture sur la base de donnée… (mais je suis loin d'être sur que tout soit bien écrit effectivement)

                Sinon, la redirection est faite sur le reverse proxy qui est une autre machine ou il n'y a ni PHP ni Python ni rien de tous ces trucs… Donc remplacer la redirection me semble non pas infaisable mais non triviale…

              • [^] # Re: Mon opinion

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

                En fait, tu tiens à protéger ton espace privé, mais une interception de flux pour remplacer le contenu du site public par un autre ne te dérangerait pas ?

                C'est effectivement peu appréciable mais au vu de l'importance de MES sites, peu probable non plus.

                Sinon, on parle ici de la véracité d'un site donc de sa signature. Il suffit d'avoir une page signé numériquement pour la valider comme on signe un courriel. Pas besoin de chiffrement et d'https donc. Une page signée suffit à certifier que la page provient bien de mon site web (ce qui ne veut pas dire mais cela est vrai dans 100% des cas que mon site n'a pas été piraté).

                Signer le HTTP, oui. Tout chiffrer et basculer en HTTPS, ce n'est pas forcément utile à mon sens.

                • [^] # Re: Mon opinion

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

                  Signer le HTTP, oui. Tout chiffrer et basculer en HTTPS, ce n'est pas forcément utile à mon sens.

                  Pourquoi ?

                  La connaissance libre : https://zestedesavoir.com

                  • [^] # Re: Mon opinion

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

                    Parce que justement j'utilise le HTTPS pour authentifier ! Sinon je met tout en https, il faut que je trouve un autre moyen pour authentifier. Mes sites web sont consultable pour la plupart authentifié ou non, or j'aime bien que l'authentification ait lieu sur le reverse proxy, en amont du site web, sur une machine n'ayant pas de langage de script !

                    • [^] # Re: Mon opinion

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

                      Tu utilise les certificats clients pour authentifier tes utilisateurs ? Sinon, je ne vois pas ce que tu veux dire par "j'utilise le HTTPS pour authentifier".
                      Si c'est bien ce que tu veux dire, tu peux écrire tes règles de reverse proxy pour agir différemment si un certificat client est présent ou non, il me semble.

                      • [^] # Re: Mon opinion

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

                        C'est très probablement des certificats clients.

                        En tout cas avec Apache, tu peux en effet rendre le certificat client optionnel… sauf que dans ce cas, le navigateur va probablement ne jamais demander au client de fournir le certificat (de mémoire, c'était le comportement quand j'avais essayé).

                        • [^] # Re: Mon opinion

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

                          Côté apache ça ressemble à :

                          # Allow access if one does not have a valid certificate
                          SSLVerifyClient optional
                          

                          (avec optional au lieu de require)

                          Et si, Firefox (45 mais c'était déjà le cas il y a plusieurs années) propose l'utilisation d'un certificat dans ce cas…

                          Mraw, KiBi.

                • [^] # Re: Mon opinion

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

                  Tout chiffrer et basculer en HTTPS, ce n'est pas forcément utile à mon sens.

                  Un des intérêts de la généralisation du chiffrement, c’est de rendre le trafic chiffré suffisamment « commun » ou « banal » pour que la simple utilisation du chiffrement ne permette pas d’identifier le trafic « intéressant ».

                  • [^] # Re: Mon opinion

                    Posté par (page perso) . Évalué à -5 (+1/-8).

                    Les personnes mettent du HTTPS et des liens vers 36 sites, soit google analytics, soit des bibliothèques javascripts…

                    Un paquet de site non authentifié sont encore (et heureusement) non pas des applications mais principalement du texte ouvert au moteur de recherche. J'évite tout script externe, tout appel DNS externe, toutes images externes…

                    Bref, pour moi, ce n'est pas forcément une priorité de chiffrer pour chiffrer du contenu que je met à la disposition du public et vérifiant (je l'espère) toutes les lois de la république. Tout est dans les caches des moteurs de recherche…

            • [^] # Re: Mon opinion

              Posté par (page perso) . Évalué à 5 (+3/-0). Dernière modification le 17/02/17 à 15:24.

              et bon pour les robots

              De mémoire, Google a commencé à mettre un score supérieur à du https que du http

  • # utiliser hsts

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

    La redirection 301 utilisée seule peut subir une attaque de "man in the middle", il est préférable pour ceci d'utiliser aussi le protocole HSTS fait spécialement pour résoudre le problème :

    • soit en pré-chargeant une liste de site à contacter en https quand aucune visite n'a encore été faite vers un site (https://hstspreload.org/)
    • soit en disant au serveur d'envoyer l'ordre d'utiliser strictement https quand vous avez déjà visité le site.

    Deux liens disponibles sur le sujet :

    • [^] # Re: utiliser hsts

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

      Tout à fait, c'est un navrant oubli de ma part, à ajouter comme doléance aux administrateurs bien entendu.

      Merci pour le rappel.

  • # aller regler ca dans tes parametres

    Posté par . Évalué à -2 (+1/-5). Dernière modification le 14/02/17 à 18:40.

    si c'est pour de la lecture seule => http, sans login
    si c'est pour repondre, tu es loggué => https

    ah non, il faut etre loggué en https pour que ca le conserve…

  • # Suivi

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

  • # merci !

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

    Grâce à ton journal je m'aperçois que j'utilise HTTP et non HTTPS, malgré https-everywhere…

    Hop zou c'est changé, merci ! Comme quoi le HTTPS par défaut serait utile aux têtes en l'air.

    • [^] # Re: merci !

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

      Enfin faut être plus que tête en l'air pour ne jamais être passé au https (si tu le fait une fois ton navigateur t'empêchera de venir autrement ensuite).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: merci !

      Posté par . Évalué à -10 (+1/-12).

      Https n'a aucun intérêt si le proxy interne de ta boite negocie le chiffrement avec ton arpenteur.

      Je comprends pas cette mode davoir envie de chiffrer du contenu qui ne le mérite pas.

      • [^] # Re: merci !

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

        Prenons le problème à l'envers : Pourquoi ne pas chiffrer alors que ça ne coûte quasiment rien ?

        Et comment tu fais la distinction entre du contenu méritant et le reste ?

        • [^] # Re: merci !

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

          Ce qui est privé doit rester privé.

          Par exemple une conversation entre deux personnes. Ce qui n'est pas le cas dans un forum par exemple. Encore qu'il peut y avoir des forums privés, on appelera ça des salons plutôt.

          Poster des contenus sur un site comme dlfp relève du public. Alors je ne vois pas l'intérêt de chiffrer.

          • [^] # Re: merci !

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

            Donc au lieu d'utiliser un protocole unique tu proposes d'en utiliser deux. Intéressant.

          • [^] # Re: merci !

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

            Poster des contenus sur un site comme dlfp relève du public. Alors je ne vois pas l'intérêt de chiffrer.

            Ce qui est sur LinuxFR est public, mais les méta données sur les posts ne le sont pas.
            Et la question n'est pas « Pourquoi chiffrer par défaut » mais plutôt « Pourquoi ne pas le faire par défaut ? ». Chiffrer par défaut ne pose aucun problème…

      • [^] # Re: merci !

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

        Je ne comprend pas cette mode de ne pas se renseigner quand on ne comprend pas, ici un peu de recherche sur le net t'indiquera rapidement les multiples raisons.
        Non, je n'ai pas envie de t'en faire un résumé, trop gros surtout pour un lecteur de LinuxFr.

        • [^] # Re: merci !

          Posté par . Évalué à -5 (+1/-7).

          Explique moi l'intérêt de chiffrer tes commentaires sur le web….sachant que dlfp est accessible à tout le monde et que le contenu sera quand même scanné, indexé etc…

          Respect de la vie privée ? Dès lors qu'un contenu que tu postes n'a pas un minimum de confidentialité, il devient publique. C'est ainsi qu'on peut s'en servir contre toi. Le chiffrement ne change rien à l'affaire.

          Et si en plus tu te sers de l'accès web de ton boulot pour poster des insanités sous couvert d'anonymat, le https ne te sera d'aucun recours.

          • [^] # Re: merci !

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

            Ne pas se faire profiler sur un réseau publique ?

          • [^] # Re: merci !

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

            Explique moi l'intérêt de chiffrer tes commentaires sur le web….sachant que dlfp est accessible à tout le monde et que le contenu sera quand même scanné, indexé etc…

            Pour la confidentialité :
            1) ton authentification (cookie et/ou mot de passe) ne passe pas en clair sur un réseau que tu ne maîtrises pas ;
            2) il est beaucoup plus compliqué de relier le contenu de ce que tu postes ou consultes sur un site via un crawling de celui-ci, par rapport à une analyse de ce qui passe effectivement sur le tuyau, ce qui est important quand SFR annonce qu'il va "tester" les publicités ciblées sur son offre TV.

          • [^] # Re: merci !

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

            Il n'y a pas que le chiffrement des communications qui est important, ya aussi et surtout l'authentification du site que tu visites. Sans HTTPS tu ne sais pas si t'es en train de lire le vrai linuxfr.org ou si quelqu'un au milieu n'est pas en train d'injecter du vilain JS ou des pubs dans ce que te renvoie le site.

          • [^] # Re: merci !

            Posté par . Évalué à 5 (+4/-1).

            Même si le contenu est public, le fait que tu le consulte peut être considéré comme privé.

            Par exemple Wikipedia n'a que des pages publiques, mais tu n'a pas forcement envie que ton FAI puisse savoir si tu te renseignes sur la version d'IE livrée avec Windows 8, sur Napoléon 3 ou sur les hémorroïdes.

            • [^] # Re: merci !

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

              Et je suis sur que tu as ton Smartphone dans ta poche arrière toute la journée ;-)

              • [^] # Re: merci !

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

                Ok donc tu ne veux pas forcément que ton FAI sache que tu te renseignes sur les hémorroïdes d'où l'usage du HTTPS.

                • [^] # Re: merci !

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

                  Attention, autant la NSA fait ce qu'elle veut, autant ton FAI est soumis à la loi française (ou belge, ou…) et ne peut pas faire ce qu'il veut !

      • [^] # Re: merci !

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

        On chiffre le contenu qui ne le mérite pas pour que le contenu qui le mérite et qui sera chiffré ne se fasse pas remarquer.

        D'autre part qui décide/juge du mérite d'un contenu à être chiffré : chaque site ? Non, c'est l'utilisateur qui doit le faire. Or un site ne peut pas savoir à l'avance ce que va décider l'utilisateur, il doit donc chiffrer par défaut.

        Une somme de contenus qui ne méritent pas d'être chiffrés peuvent constituer un profile d'un utilisateur qui lui doit être chiffré.

        Ton commentaire, si il est répandu chez une majorité d'internaute, est effarant IMHO.

      • [^] # Re: merci !

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

        Moi, je ne comprends pas cette mode d'être aussi affirmatif quand on écrit des bêtises, tout en se sachant pourtant incompétent.

  • # Désengorger HTTPS-Everywhere

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

    Sans compter que le nombre de règles de réécriture dans HTTPS-Everywhere devient vraiment grand. Ça alourdit l'extension.

    Les règles sont supprimées lorsqu'un site rejoint la liste preloaded de firefox et chromium. Du coup, je pense que ce serait une bonne chose que tous les sites qui le peuvent passent en HSTS preloaded.

  • # redirect permanent

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

    Dans la conf d'apache et celle de nginx, il y a des directives pour faire de la redirection permanente pourquoi ne pas utiliser cela

  • # Par pitié non

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

    Il y a des entreprises chez qui le https est interdit par défaut. Seule une petite liste blanche autorise quelques sites.

    Alors de grâce laissez le choix à l'utilisateur merci

    • [^] # Re: Par pitié non

      Posté par (page perso) . Évalué à 6 (+9/-5). Dernière modification le 16/02/17 à 09:40.

      T'es mal barré : le mouvement est clairement de rediriger HTTP vers HTTPS.
      De quel choix tu parles? C'est un protocole, c'est tout.
      Et justement, que tout les sites passent à HTTPS mettra alors la pression sur ta "super-entreprise" à l'admin dangereux pour qu'elle arrête sa liste blanche et autorise tout site en HTTPS (au pire si elle veut quand même scanner en mettant son certificat en intermédiaire, du moment où elle vérifie quand même que le site en face est le bon, bref sans casser la sécurité une fois sortie de l'entreprise).

      note que je comprend que tu dois te taper une boite pourrie pour avoir des sous à la fin du mois, mais pas la peine de faire le syndrome de Stockholm, tu a l'air de trouver ça pas dérangeant que de bloquer HTTPS alors que c'est quand même un gros problème de sécurité.

      • [^] # Re: Par pitié non

        Posté par . Évalué à -10 (+2/-16).

        Cette boite est un grand bancaire français. Et d'autres font pareil.

        Je suis contre le fait qu'on m'impose le https aux motifs falacieux.

        • [^] # Re: Par pitié non

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

          Si ma boite interdit les sites contenant un s, dois-je demander à tout les sites de ne pas m'imposer des noms en s ?
          Si ta boite a un fait un choix technique, c'est son problème.

    • [^] # Re: Par pitié non

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

      Si ta boite ne veut pas que tu surf, c'est son choix.
      Peut être estime-t-elle que ce n'est pas utile à ton travail.
      Dans ce cas ton surf est personnel. Surfe avec un équipement personnel comme ton mobile par exemple.

Envoyer un commentaire

Suivre le flux des commentaires

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