HSTS arrive dans Firefox 4

Posté par . Modéré par baud123.
Tags :
23
17
sept.
2010
Mozilla
Mozilla a annoncé le 27 août 2010 que Firefox 4 inclurait le HSTS (HTTP Strict Transport Security). Cette amélioration permet d'éviter des problèmes de sécurité liés au basculement de HTTP au HTTPS en permettant au site web d'exiger une connexion sécurisée. Sur le web, un moyen de sécuriser le transport de données délicates est le HTTPS. Il permet de chiffrer les données qui sont échangées avec le serveur du site. Il permet à des visiteurs de vérifier l'identité du site auquel ils accèdent avec un certificat d'authentification. Généralement, on retrouve ce procédé pour les ventes/achats en ligne, et les internautes peuvent payer avec leur carte bancaire sans risques. Enfin... pas tout à fait sans risques.

Une des solutions qu'ont les crackers pour contourner cette sécurité est de s'insérer entre le client et le serveur. L'internaute demande d'abord une page web sans préciser au premier abord s'il désire une page sécurisé. Ensuite, éventuellement, le site transfère cette connexion (http) vers une connexion sécurisée (https). Le cracker peut dans ce cas s'insérer entre ces deux étapes, on appelle ça Attaque de l'homme du milieu. Un autre moyen possible est d'utiliser les failles des navigateurs web. Ceux-ci, afin d'être compatibles avec les sites qui n'utilisent pas le https correctement, se compromettent en laissant passer des erreurs. Par exemple, le cracker crée un certificat auto-signé, le navigateur web propose à l'utilisateur d'accepter ce certificat en le mettant en garde, et en cas d'acceptation envoie l'internaute sur une page qui peut ne pas être bien sécurisé. Sinon, sans en venir à "forcer" l'utilisateur à passer en http, certains sites (comme gmail), pour être compatible avec les versions http et https, mémorisent les identifiants de session dans des cookies non sécurisés. Le cracker peut alors récupérer les information sur une simple requête http au site.

Depuis 2008, deux chercheurs en informatique, Collin Jackson et Adam Barth (Université de Standford), proposent une alternative pour sécuriser les sites web : ForceHTTPS (voir leur article ForceHTTPS: Protecting High-Security Web Sites from Network Attacks). Avec un cookie ForceHTTP intégré à un site web, le propriétaire du site demande aux navigateurs web de traiter des erreurs HTTPS comme des attaques, et non comme des erreurs de configuration. Ce petit détail change un certain nombre de choses. Une connexion HTTP normale est automatiquement redirigée vers du HTTPS (et donc, à aucun moment, il n'y a eu connexion au site de manière non sécurisée). Toute erreur TLS met fin à la session. Toute tentative d'insérer du contenu non sécurisé au site se termine en erreur réseau.

Cette idée a germé dans l'esprit des développeurs et de là est né HTTP Strict Transport Security (HSTS). Cette amélioration est déjà accessible via une extension pour Firefox (HTTPS Everywhere), mais aussi, et surtout, mozilla a annoncé il y a quelques semaines que HSTS sera présent dans le futur Firefox 4. Voilà qui méritait d'être noté.
  • # Certificat auto-signé

    Posté par . Évalué à 10.

    Est-ce que ça permettra à plus ou moins long terme de permettre de réutiliser sans que cela génère des alertes des certificats auto-signé pour les applications non-critiques ? Parce qu'aujourd'hui, c'est devenu difficile de permettre à des utilisateurs de communiquer avec un serveur de façon sécurisé sans se payer un certificat, tellement les navigateurs en font des tonnes sur une possible attaque parce que le certificat d'un site web est auto-signé.

    Même en tant qu'utilisateur c'est lourd, beaucoup de site sur le logiciel libre utilisent des certificats auto-signés, et voir ces erreurs en permanence finit par la banaliser et finit par faire en sorte que lorsqu'on est face à un véritable problème de sécurité, on y fera probablement pas attention...
    • [^] # Re: Certificat auto-signé

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

      Je crois que c'est ce qui est prévu, et que c'est en fonction du site que tu visites :
      - soit tu surfes sur un site qui utilise HSTS, alors il n'enverra jamais de requête sur HTTP mais que sur HTTPS, et là il sera très strict
      - soit tu surfes sur un site qui ne l'utilise pas (pour les applications non-critiques comme tu dis) et le comportement deviendra un comportement normal

      Chrome, qui utilise apparemment aussi cette fonctionnalité, a aussi une liste statique de serveurs qui utilisent le HSTS, pour éviter de se faire attaquer la première fois qu'on visite le site (l'information est transmise normalement avec un header sur le site HTTP, donc facilement manipulable par une attaque man in the middle, ou encore un virus).

      Cf : http://sites.google.com/a/chromium.org/dev/sts
      • [^] # Re: Certificat auto-signé

        Posté par . Évalué à 2.

        l'information est transmise normalement avec un header sur le site HTTP

        Tu es certain? Parce que ton lien indique le contraire, et ce que j'ai lu sur le sujet jusqu'ici aussi.

        An HSTS enabled server can include the following header in an HTTPS reply:

        Strict-Transport-Security: max-age=16070400; includeSubDomains
        • [^] # Re: Certificat auto-signé

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

          Effectivement, ce qui est prévu dans le brouillon de la spec¹, c'est que quand une requête HTTP est reçue par un moyen de transport non-sécurisé (cas de la classique URL http://..., le serveur devrait répondre par un 301 (redirect) qui donne l'adresse https en retour.

          (Ce n'est pas une obligation, car il y a des problématiques de sécurité liées à ce genre de méthode, cf. la note dans la spec.)

          Par contre, le serveur ne doit pas donner l'en-tête Strict-Transport-Security dans une réponse HTTP non-sécurisée.

          ¹ http://tools.ietf.org/html/draft-hodges-strict-transport-sec(...)
    • [^] # Re: Certificat auto-signé

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

      En tant qu'admin, tu n'as qu'a soit générer tes certificats avec ton CA, et le foutre comme CA de confiance sur les postes, soit déployer une liste de certificats autorisés.

      Avec firefox ça se script bien, avec IE j'imagine que ça se gère dans l'AD, avec les autres ça doit être faisable aussi.

      En tant qu'utilisateur, .. bah .. heu .. tu peux patcher le code pour utiliser tout et n'importe quoi ? :p
    • [^] # Re: Certificat auto-signé

      Posté par . Évalué à 2.

      Et pourquoi ne pas utiliser un certificat signé par StartSSL ?
    • [^] # Re: Certificat auto-signé

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

      Certes ils en font des tonnes, mais justement parce que les utilisateurs ont trop l'habitude d'avoir des boites de dialogue et de valider sans vraiment comprendre.

      Moi j'aime bien les pages de Mozilla où ajouter une exception n'est pas une simple validation et où clairement le bouton si on ne réfléchit pas est "je m'en vais".

      Pour ce qui est de la banalisation, même avec les pages de Mozilla, on y est déjà.

      Je me rappelle à une conférence de développeurs web, probablement des développeurs du haut du panier, des gens qui comprennent, qui savent, et qui font attention.
      On avait du wifi prêté pour des ateliers, géré par une école (peut être par l'administration, peut être par des étudiants, on n'en sait rien). Là dessus ils avaient un proxy filtrant aussi le HTTPS (donc cassant les certificats, tous apparaissaient comme des certificats auto-signés).
      Et bien ... tous se sont connectés à gmail et à twitter, en validant les erreurs "certificat ssl incorrect". Tous sans exception, j'ai fait un sondage.
      Le réflexe est tellement ancré tous se croient plus sachant que le système et que jamais les erreurs du système ne sont acceptées comme bloquantes. Le "Je veux" de l'utilisateur ne s'arrête plus aux "non" du système, quelle que soit la forme qu'on leur donne ou la connaissance de l'utilisateur.

      La seule solution que je vois serait de permettre aux navigateurs :
      - de faire la différence entre un certificat sans CA de confiance visité pour la première fois (probablement un auto-signé) et un certificat sans CA de confiance pour un site qui était certifié auparavant (probablement un problème de MITM)
      - de faire la différence entre un certificat à problème sur une connexion cable habituelle et sur une connexion wifi publique (avec une gravité supplémentaire pour ce dernier cas qui rend plus vraissembable l'attaque)
      - d'utiliser un tiers de confiance pour savoir si la signature du certificat auto-signée est la même que celle que les autres ont et ont eu par le passé ou pas (auquel cas si je suis le seul, c'est certainement un MITM)
      • [^] # Re: Certificat auto-signé

        Posté par . Évalué à 2.

        Ajouter quelques couleurs de plus dans la barre d'adresse pour que ça saute aux yeux pourrait être bien.

        On pourrait distinguer
        1 - banal http
        2 - https avec certificat auto-signé inconnu (accepté temporairement après popup)
        3 - https avec certificat auto-signé déjà ajouté à la whitelist
        4 - https dûment signé

        Le passage d'un niveau à un niveau inférieur pour un même domaine devrait faire surgir une alerte.
        • [^] # mouif

          Posté par . Évalué à 10.

          il y aura https, et https en Orange ?
      • [^] # Re: Certificat auto-signé

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

        Moi j'aime bien les pages de Mozilla où ajouter une exception n'est pas une simple validation et où clairement le bouton si on ne réfléchit pas est "je m'en vais".

        Ben moi j'aime pas, car tout ce qu'on cherche à faire c'est d'accéder à ce site alors que ce put**** de navigateur nous donne un labyrinthe qui ne change rien au final.
        Chrome n'est pas beaucoup mieux (mais mieux quand même de mon point de vue car il indique la différence entre http signé et auto-signé), il pose une question à chaque fois qu'on redémarre le navigateur, sans prévenir si le certificat a changé ou pas.
        Alors qu'on a une solution simple depuis un moment avec SSH par exemple :
        - Première connexion, on accepte ou pas le certificat en disant bien que si ce certificat est nouveau, et que donc il faut avoir confiance dans notre liaison. Pas avec des warnings super-méga mechant qui passent pour ridicule (trop gros, ça passe pas). Dans la barre d'URL, mettre une couleur spéciale pour dire que la validation ne s'est pas faite de manière 100% sécure (ça, c'est pour Firefox)
        - Connexions suivantes sans questions (ça c'est pour Chrome) si le certificat n'a pas changé (et que la personne a demandé de garder en mémoire le certificat par exemple)

        Avec Firefox, tout ce que ça fait c'est d'inciter les gens à cliquer partout où ils peuvent car ils ne comprennent pas le problème avec le texte alarmiste et qu'on file un labyrinthe pour y accéder au site à visiter, et plus tard, ils continuent de cliquer partout sans lire plus car la première fois c'était pour bizarre. Pas sûr que la sécurité s’améliore avec ce système.

        Et dans ton exemple, le reproche que je ferai est que le navigateur n'avertit pas que le certificat a changé pour un site déjà visité auparavant.
        • [^] # Re: Certificat auto-signé

          Posté par . Évalué à 2.

          +1
          Et j’ajouterai que 95% des sites qui ont un certificat auto-signé sont loin d’être des sites ultra-sensibles. Une popup avec deux boutons continuer/annuler, ok, mais toute procédure plus longue que ça est inutilement chiante.
        • [^] # Re: Certificat auto-signé

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

          Je suis d'accord avec tout.

          Tout d'abord non, la plupart des gens ne souhaitent pas simplement accéder à ce ** de site. Ils veulent le faire *et* ne pas compromettre la sécurité (sinon autant aller en http simple).

          Ensuite non, nous ne sommes pas dans une configuration similaire à SSH. SSH se fait souvent dans des conditions idéales :
          - peu de destinations, toutes connues,
          - généralement ces destinations sont fortement maitrisées (souvent on est l'administrateur de la machine)
          - généralement accédé depuis son poste et d'un réseau connu, maitrisé
          - on ne rencontre jamais de nouveau serveur "par hasard" ou par découverte, la liste change rarement
          - si le serveur ssh change de certificat on le sait, on sait facilement que c'est anormal dans le cas contraire
          - on s'adresse à des utilisateurs tous très avertis

          Là côté web c'est tout le contraire :
          - il y a facile une centaine de destinations même pour l'utilisateur de base
          - aucune n'est maitrisée (mais alors *pas* du tout)
          - pas si rarement accédées en situation de mobilité, à partir de réseaux non contrôlés
          - on découvre fréquemment de nouveaux serveurs, qu'on ne connait pas auparavant, la liste change souvent
          - on ne sait jamais si un nouveau certificat est normal ou s'il est révélateur d'une malveillance
          - on s'adresse en partie à des utilisateurs qui n'y connaissent rien (voire pire : qui se méprennent)

          Et ça change tout.
          - On me signale par mail un problème avec mon compte en banque, je vais sur le wifi du mac do avec mon téléphone portable, c'est ma première connexion au site avec ce téléphone, je fais quoi ?
          - Un copain me conseille un site par mail, j'y vais pour la première fois, le certificat semble auto-signé, je fais quoi ? est-ce normal ?
          - Le certificat de Linuxfr.org change, il est auto-signé (imaginons), comment sait-je s'il y a eu un problème ou s'il a réellement changé ?

          Le résultat c'est que le comportement par défaut doit bien être d'abandonner. Le fait d'avertir si le certificat a changé n'est pas suffisant. Si on reprend les habitudes de ssh sur le web, on revient rapidement à ce qu'il y avait avant sous Mozilla : aucun labyrinthe, juste une popup qui retient le statut ensuite. C'est simple, excellent, mais finalement la popup ne sert quasiment à rien, on cliquera toujours sur "continuer" ou presque.


          On est d'accord que un changement est un critère principal dans l'équation, mais la problématique n'est pas simple pour autant. Dans mon exemple le navigateur avait bel et bien prévenu que le certificat avait changé (puisque tous ont eu le labyrinthe Mozilla, sinon ça serait passé direct). Ca n'a pas suffit.


          En fait une des solutions serait d'avoir enfin une autorité de confiance gratuite *ET* qui fait son boulot (donc qui vérifie réellement la propriété du domaine avant d'envoyer le certificat) *ET* qui passe un audit pour être intégrée dans les navigateurs courants (l'intégration de cacert dans les distributions Linux n'a pas été une bonne chose amha)
          • [^] # Re: Certificat auto-signé

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

            Oui, ce n'est pas simple.
            Mais à mon avis (que je partage), le fait d'avoir fait un méga-warning pour les sites auto-signés, et mettre ce même warning pour les sites non auto-signés qui passent bizarrement en auto-signé (Man in the middle), n'a fait que tuer la sécurité : maintenant, les gens sont gavés d'alertes de sécurité "à la con" (celui de l'auto-signé qui a toujours été auto-signé, genre... LinuxFr, cacert n'étant pas dans les version officielles des navigateurs), ils cliquent partout pour que ça marche, même quand le comportement est bizarre (gmail qui passe en auto-signé). Même réaction que quand Microsoft a mis l'UAC partout, il a fallu Windows 7 pour qu'ils corrigent un peu le tir.

            Trop d'alertes tuent les alertes, et c'est ce qu'il se passe en ce moment. Le mal est fait, les navigateurs sauront-ils corriger le tir?
            Une chose est sûre : le comportement actuel des navigateurs ne fait que faire chier, et n'améliore pas la sécurité, au contraire, du fait du trop grand nombre d'alertes faites sans assez de réflexions. Il y a quelque chose à changer.
            • [^] # Re: Certificat auto-signé

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

              Pour les auto-signés qui l'ont toujours été, je pense qu'il y a vraiment moyen d'améliorer la chose. Il suffit d'un tiers de confiance qui peut confirmer :
              - que le certificat n'a pas changé ce dernier mois (donc pas de compromission du côté du serveur ou du réseau global)
              - que le certificat qui est vu d'une autre partie du réseau est bien le même que celui que je vois (donc pas de compromission du côté du réseau que j'utilise)

              Avec ces deux critères, un simple warning à la première connexion devrait suffire (sans labyrinthe j'entends)

              Ca ne coute pas grand chose à faire, qui se lance ?
              • [^] # Re: Certificat auto-signé

                Posté par . Évalué à 2.

                Ben si on utilise un tier de confiance, pourquoi le site ne se fait pas signer son certificat par ce tier de confiance pour qu'il ne soit plus autosigné ?

                Quel est l'intérêt d'un certificat autosigné puisqu'il ne permet pas de valider l'identité du serveur, et qu'il permet de chiffrer la connexion ... mais on ne sait pas avec qui.

                A mon sens le problème, c'est plutôt qu'on a pas d'autorité de certification gratuite. Le seul gain de "s'autosigner" c'est les quelques centaines d'euros/ an de certificat.
                Or c'est assez simple a faire une autorité de confiance, y' a pas de raison que cela coute cher.
                qui se lance ?
                • [^] # Re: Certificat auto-signé

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

                  Ben... Avec http://www.startssl.com/?app=1 , le problème n'est-il alors pas résolu si c'est "que" ça? Ou est le piège? A quand LinuxFr avec? ;-) (LinuxFr n'utilise pas un certificat signé par une autorité de confiance pour les navigateur, le certificat cacert n'étant pas dans la liste des autorités de confiance par défaut)
                  http://www.positivessl.com/ssl-certificate-products/addsuppo(...) est à 10€/an, d'autres sont à 100€/an, je suis perdu dans ces prix totalement différents... C'est quoi la différénce entre un certificat startssl gratuit et un qui coûte plus de 100€/an même en class 1? (et quelle est l'utilité de monter à class 2 pour la sécurité de la communication entre mon navigateur et le serveur, question peut-être con désolé)
                  • [^] # Re: Certificat auto-signé

                    Posté par . Évalué à 1.

                    Je ne connaissais pas startssl.com, c'est exactement de ce genre de service dont je voulais parler.
                    Pouvoir obtenir un certificat pour un serveur web, en validant uniquement qu'on est bien au bout de "webmaster@mondomaine.com", ce qui est déjà pas mal comme preuve de propriété. On pourrait aussi utiliser les adresses email du whois du domaine... rien de très compliqué.

                    Dans ce cas, est-ce que les admins de linuxfr.org pourraient nous expliquer POURQUOI ils ne prennent pas un certificat chez startssl ?? Quel serait l'inconvénient par rapport a un certificat autosigné ?? Parceque coté utilisateur ça simplifierai bien la vie !!

                    quelqu'un pour répondre ?
                    • [^] # Re: Certificat auto-signé

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

                      Le certificat de LinuxFr.org n'est pas auto-signé, il est signé par CaCert.org. Les raisons de ce choix ont déjà été expliquées plusieurs fois, par exemple sur http://linuxfr.org/comments/1044250,1.html
                      • [^] # Re: Certificat auto-signé

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

                        Le certificat de LinuxFr.org n'est pas auto-signé, il est signé par CaCert.org.

                        En pratique, ça revient exactement au même : méga-warning "attention vous allez avoir les pires trucs si vous faites le labyrinthe qu'on vous met".

                        Je comprend l'argumentation du pourquoi, mais j'ai bien peur que les bienfaits de l'action (ne pas avoir d'oligopole) ne compense pas les méfaits (inciter les gens à passer outre les warnings sans plus les lire tellement il y en a).

                        Question con : à ma connaissance, pour être dans les navigateurs il "suffit" d'être audité et montrer qu'on peut être de confiance, plusieurs entités (j'en ai une bonne dizaine encore en enlevant les doublons) sont dans les navigateurs, alors pourquoi pas CaCert au moins dans Firefox et Chrome si admettons Microsoft fait de la résistance? StartCom (StartSSL) a le gros avantage d'être dans les navigateurs par défaut, et donc ne pas afficher les méga-warning. Jusqu'au changement de politique des navigateurs sur le comment alerter sur ce genre de certificat, ça pouvait aller, maintenant avec les méga-warnings c'est plus délicat de continuer comme ça.
                • [^] # Re: Certificat auto-signé

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

                  > Ben si on utilise un tier de confiance, pourquoi le site ne se fait pas signer son certificat par ce tier de confiance pour qu'il ne soit plus autosigné ?

                  Parce que déclarer "je vois le même certificat que toi" n'a pas la même force et ne demande pas la même infrastructure/sécurité que certifier le site.

                  > Quel est l'intérêt d'un certificat autosigné puisqu'il ne permet pas de valider l'identité du serveur, et qu'il permet de chiffrer la connexion ... mais on ne sait pas avec qui.

                  La signature de l'autorité de confiance est un moyen d'identifier le site, pas le seul. On peut passer par une certification "de masse" (on sait que le site est le bon parce que la masse déclare qu'il est le bon). On peut aussi certifier par soi même (ce qui est fait pour la plupart des intranet ou applis persos).
                  Ces moyens ne sont pas forcément plus mauvais que de faire confiance à Verisign qu'on ne connait pas et dont on ne peut pas contrôler la bonne foi ou l'absence de faille.

                  > Or c'est assez simple a faire une autorité de confiance, y' a pas de raison que cela coute cher.
                  qui se lance ?

                  vas voir cacert.org

                  Mais ce n'est pas si simple. Il va te falloir une infrastructure de sécurité qui convainque tous les éditeurs de navigateur que ta clef maitresse ne sera pas compromise. Il va aussi te falloir assurer que tu ne certifies que le propriétaire du site et pas n'importe qui.

                  Ca demande une organisation, une infrastructure, et ça coute des sous.
                  CaCert n'est toujours pas dans Firefox justement pour ça, ils n'ont pas encore pu prouver par un audit qu'ils apportaient toutes les garanties nécessaires (et pas à cause de questions de monopole ou de non-commercial)
      • [^] # Re: Certificat auto-signé

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

        Comme je rencontre pas mal de certificats auto-signés, j'utilise maintenant Certificate Patrol, un addon Firefox. C'est assez bien fait, et relativement accessible à un utilisateur inexpérimenté.

        http://patrol.psyced.org/

        DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Par défaut ?

    Posté par . Évalué à 5.

    Voir http://www.geckozone.org/forum/viewtopic.php?f=13&t=7618(...)

    Pour ceux qui ont la flemme de cliquer :
    "Sinon, dans un autre domaine, ForceTLS risque bien d'être coupé par défaut. Plusieurs sites ne fonctionnent plus et un soucis d'attaque par régression a été soumis à l'IETF qui standardise TLS. Chrome 6 a d'ailleurs fait de même (c'est le même dev qui l'a développé pour les deux navigateurs), le support y a été désactivé par défaut."

    Donc, je sais pas ce qu'il en est maintenant, si quelqu'un a une idée...
  • # En tout cas, ça marche !

    Posté par . Évalué à 3.

    C'est présent dans la beta 6 de Firefox 4 et, alors qu'avant j'avais un avertissement sur le certificat de la boîte mail de ma société de service, maintenant j'ai une jolie page blanche.

    D'un autre côté, j'ai testé cette page parce qu'à cause du proxy-facho-mitm-powered du boulot, c'est la seule page sécurisée que je visite ou presque.

    En fait, après vérification, c'est pareil sur le site d'addons de Mozilla (qui ne fonctionnait déjà qu'en https avant) et ici même si je passe en https.
  • # NoScript, l'outil ultime des paranos

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

    NoScript est capable de faire un truc similaire : si un cookie a été reçu en HTTPS, il empêchera l'envoi sans HTTPS, même si le cookie n'a pas été marqué « secure ». Ça pose des problèmes de temps en temps, mais on peut exclure certains sites de ce comportement.

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: NoScript, l'outil ultime des paranos

      Posté par . Évalué à 4.

      D'ailleurs la news indique que la fonctionnalité est disponible dans l'extension HTTPS Everywhere de l'EFF, et le site web de cette extension (lien dans la news) précise que son code est basé sur NoScript.
      • [^] # Re: NoScript, l'outil ultime des paranos

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

        Ah oui on peut aussi forcer un domaine en HTTPS. J’utilise quand même HTTPS Everywhere, car pour Wikipedia ou Google par exemple, il ne suffit pas de rajouter un 's', le domaine est différent.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: NoScript, l'outil ultime des paranos

          Posté par . Évalué à 3.

          Elle est super cette extension, on peut facilement ajouter les sites webs importants pour soi (banque, vente en ligne), c'est-à-dire des sites où un vol de session aurait des conséquences graves (compromission de données bancaires).

          Par exemple :
          cd ~/.mozilla/firefox/dx99x99x.default/extensions/https-everywhere@eff.org/chrome/content/rules
          $ cat Linuxfr.xml
          <ruleset name="linuxfr">
          <rule from="^http://(www\.)?linuxfr\.org/" to="https://linuxfr.org/"/>
          </ruleset>

          La liste est lue au lancement, il faut redémarrer Firefox.
  • # HTTP->HTTPS

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

    C'est ce truc qui semble-t-il est responsable du fait que la beta 5 de firefox est inutilisable au quotidien et donc intestable en utilisation normale.

    Impossible d'accéder à gmail ou tout autre service qui redirige vers du https...

    Et pas un mot de la part de Mozilla quand à la correction de ce problème sur le raport de bug (à part "c'est corrigé, au revoir merci pour le rapport").
    • [^] # Re: HTTP->HTTPS

      Posté par . Évalué à 4.

      Voici le lien du rapport de bug, avec les commentaires des développeurs : https://bugzilla.mozilla.org/show_bug.cgi?id=592197

      En gros, c'est corrigé sur le tronc, et ça sera disponible avec la beta 7 (la 6 étant une 5 + quelques corrections de failles de sécurtié qu'ils ont été obligé de de publier plus tôt que prévu). Si tu veux faire du test de version instable et profiter des corrections quotidiennes, je te conseille Minefield, qui intègre la correction depuis au moins lundi.

      Si tu veux suivre l'actualité du développement de Firefox 4, je te conseille de suivre le sujet déjà indiqué dans les commentaires précédents sur les forums de geckozone : http://www.geckozone.org/forum/viewtopic.php?f=13&t=7618(...)
      • [^] # Re: HTTP->HTTPS

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

        Le problème n'est pas que je suive ou pas l'actualité de Firefox 4 (ce que je fais pour Mozilla en général, je suis curieux et on ne se refait pas), mais que je trouve que al gestion de la bêta est calamiteuse.

        Ils ont introduit un bugs, ouf c'est une bêta. Ce bug rend la bêta intestable (alors que c'est son dessein) sur 25% du web (en gros) et ça ne les fait pas bouger d'un poil sur leur planning. Pourquoi le fix n'est pas dans la bêta intercallaire 6 ? Pas de réponse.

        J'en ai parler au détour d'un canal IRC avec un développeur de mozilla, qui ne voit pas le problème, pour lui (eux ?) leur communication est exemplaire... Peut être est-ce là une position officielle mais quand même, c'est inapproprié de la part d'un projet qui se dit communautaire, ouvert et défenseur de la bidouillabilité et qui communique autant la dessus.

        Le fait que tu donnes un lien vers un obscur forum plutôt qu'un blog un peu officiel pour suivre le développement est significatif de ce que je ressent vis-à-vis de leur mode de fonctionnement.
        • [^] # Re: HTTP->HTTPS

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

          Parce que si on devait avoir une beta à chaque correction on en serait aujoud'hui à la beta 236 ?
        • [^] # Canaux de communication de l'information

          Posté par . Évalué à 2.

          La version intercallaire 6 ne contient que 2 corrections de bugs par rapport à la 5 : une faille de sécurité et un qui crée de nombreux crash, de mémoire.

          Peut-être qu'au niveau de la communication Mozilla cela gagnerait à être plus clairement dit, mais en tout cas, au niveau de la bidouillabilité, c'est un parfait contre-exemple : le bug a été corrigé rapidement, et les nightly build téléchargeable pour toutes les plate-formes ont donc la correction de bug depuis ce jour, donc le bidouilleur qui veut règler ce problème a très facilement la possibilité d'utiliser Minefield en attendant la beta 7.

          Quand à Geckozone, c'est le forum francophone de référence, il existe depuis plus de 7 ans, et c'est l'un des plus important des communautés locales Mozilla (même le plus important d'après mes coups d'oeils du côté espagnol, allemand, et italien). Il est cité comme exemple par David Tenser, membre de la Fondation Mozilla chargé du support utilisateur (cf ses slides lors du Mozcamp Barcelone en 2008 : http://www.mozilla-europe.org/fr/press/2008/10/22/1194-mozil(...) ).

          Des membres de Mozilla Europe participent parfois aux sujets sur geckozone (Pascal Chevrel et Paul Rouget notamment).

          Et si tu crois toujours que le site est obscur, va sur mozilla-europe.org et cliques sur assistance : http://www.mozilla-europe.org/fr/support/ Quel est le premier lien, en gras ? Les forums de geckozone ... Et le second est la liste de discussion de geckozone, pour ceux qui préfèrent ce moyen de communication.

          Est-ce que c'est le fait que le site n'ait pas un domaine en mozilla.org qui te donne l'impression que l'information qui s'y trouve n'est pas fiable ? En quoi un blog donne-t-il des informations plus fiables qu'un sujet de discussion entre passionnés ? Je t'assure que teoli, qui anime le sujet dont j'ai donné le lien ci-dessus, est très pointu et donne des informations encore plus pertinentes que ce que l'on peut lire sur les blogs, étant donné qu'il suite de très près tout l'actualité des développements (les blogs anglophones mais également bugzilla, et il teste toutes les nouveautés sur Minefield).

          Enfin, si tu cherches un blog officiel, et que te te serai donné la peine d'utiliser un moteur de recherche, tu serais tombé très vite sur http://planet.mozilla.org/ pour les annonces officielles en anglais, http://planete.mozfr.org/ en français, et en cadeau bonus, je te met le lien vers l'annonce offcielle que tu dis ne pas exister : https://developer.mozilla.org/devnews/index.php/2010/09/13/f(...)
  • # A quand ?

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

    Ce petit système sur Da Linux French Page ?

    Fuse : j'en Use et Abuse !

  • # Path spécifique ?

    Posté par . Évalué à 3.

    J'ai beau lire la spec je ne voit pas de moyen de limiter cet effet à un path spécifique: typiquement /admin.

    Je suis passé à coté ou ça n'existe pas ?
    • [^] # Re: Path spécifique ?

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

      J'ai beau lire la spec je ne voit pas de moyen de limiter cet effet à un path spécifique: typiquement /admin.

      Je suis passé à coté ou ça n'existe pas ?


      Ça existe comme directive au niveau d'un serveur Apache pour forcer l'utilisation de SSL :


      < Directory /srv/apache2/mon-site/mon-repertoire/ >
      SSLRequireSSL
      < /Directory >


      Après, est-ce suffisant pour gérer aussi HSTS ? J'aurais tendance à penser que oui, mais il faudrait tester.

      Pour d'autres serveurs web, je serais curieux de savoir s'il y a un équivalent.

Suivre le flux des commentaires

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