HTTPS Everywhere en version 2.0.1

Posté par (page perso) . Édité par Florent Zara, Nÿco et detail_pratique. Modéré par Lucas Bonnet. Licence CC by-sa
43
6
mar.
2012
Internet

HTTPS Everywhere est une extension Firefox éditée par l'Electronic Frontier Foundation qui permet de remplacer automatiquement l'URL d'un site web par son équivalent HTTPS. Ce n'est pas forcément simple parce que pour beaucoup de sites, il ne suffit pas d'ajouter un s à http. Par exemple, jusqu'à récemment, la version HTTPS de Google n'était accessible que sur https://encrypted.google.com.

Logo HTTPS Everywhere

L'extension maintient donc une base de données pour effectuer les correspondances. Cette version 2.0.1 apporte une base plus grande (404 nouvelles règles depuis la version 1.2.2) mais aussi un Decentralized SSL Observatory (observatoire SSL décentralisé) qui permet d'envoyer de manière anonyme les certificats à une base de données de l'EFF pour qu'ils soient étudiés par cette dernière afin de détecter les éventuelles failles. L'observatoire permet aussi de signaler les éventuels problèmes en temps réel. Pour l'instant seuls les certificats qui ont été générés à partir d'une clef privée faible — à cause d'une machine ayant un générateur de nombre aléatoire buggé — sont signalés. Enfin, cette version 2 fonctionne désormais aussi sur le navigateur de Google : Chrome.

NdA : Merci à detail_pratique pour son aide lors de la rédaction de cette dépêche.

  • # Le bien fondé ?

    Posté par . Évalué à 1.

    Quelle est l'utilité concrète d'abuser du https ? Je n'en vois pas réellement, pour moi c'est utile uniquement dans les cas où on veut transférer des mots de passe ou des codes de cartes de paiement.

    Le https ne garanti pas une navigation privée puisqu'on sait toujours qui demande la page et qui la fournit (client/serveur). Il induit également une charge plus importante sur le serveur. Pire encore, sur beaucoup de sites, comme Linuxfr, les certificats ne sont pas valides et on les accepte donc sans trop savoir si c'est bien ou pas. On apprend donc les mauvaises habitudes aux utilisateurs.

    • [^] # Re: Le bien fondé ?

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

      Le https ne garanti pas une navigation privée puisqu'on sait toujours qui demande la page et qui la fournit (client/serveur).

      Mais il garanti (normalement) que le contenu de la page est inaccessible, ça permet d'éviter que les intermédiaire puissent lire tes mails quand tu les consultes via ton webmail. Les cookies sont aussi chiffrés, ça permet d'éviter une usurpation d'identité (il y avait une extension Firefox qui sniffait les WiFi en clair pour voler le cookie Facebook et te permettait de poster au nom de la personne).

      les certificats ne sont pas valides

      Le certificat de LinuxFr est valide, par contre, il se peut que tu n'est pas le certificat racine de CaCert dans ton navigateur. La FAQ décrit comment ajouter ce certificat sous Iceweasel/Firefox.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Le bien fondé ?

        Posté par . Évalué à 1.

        Merci en plus ça m'a donné l'occasion de découvrir cacert.org que je ne connaissais pas.

      • [^] # Re: Le bien fondé ?

        Posté par (page perso) . Évalué à 4. Dernière modification le 06/03/12 à 14:57.

        Mais il garanti (normalement) que le contenu de la page est inaccessible, ça permet d'éviter que les intermédiaire puissent lire tes mails quand tu les consultes via ton webmail. Les cookies sont aussi chiffrés, ça permet d'éviter une usurpation d'identité (il y avait une extension Firefox qui sniffait les WiFi en clair pour voler le cookie Facebook et te permettait de poster au nom de la personne).

        Oui enfin les principaux vecteurs ne sont pas arrêtés par le https. Le sniffage réseau n'est quand même pas le chemin le plus facile pour commettre des actes malicieux. Il est plus facile de péter une machine que de mettre en place une infra de capture.

        Attention, je ne dis pas que le ssl ne sert à rien. Mais il ne protège ni le client, ni le serveur. Il protège la transaction sur le réseau (donc il te protège des boites / états mals intentionnés ainsi que de trois petit malins qui font mumuse avec FreeWifiOpenWrt). Si je veux des comptes facebook, il me suffit de faire un site avec les résultats du bac et inscriptions obligatoire. En imposant l'adresse mail comme login. Je suis sûr de tomber dans 60% des cas sur un mot de passe générique me donnant l'accès à gmail, hotmail, facebook …

        Il te faut :
        1) un hébergeur (obtenu par exemple par scan des ports 10000 ou recherche d'url caractéristiques)
        2) une base de données de clients (un bot en perl pour récuperer des adresses mail ou un robot pour me faire des amis sur facebook, voir un bête achat).
        3) un minimum d'imagination et de discrétion

        • [^] # Re: Le bien fondé ?

          Posté par . Évalué à 9. Dernière modification le 06/03/12 à 22:18.

          Le sniffage réseau n'est quand même pas le chemin le plus facile pour commettre des actes malicieux.

          Tu as dû rater l'invention du wifi toi. Parce que entre le war driving, les clés pourries, le WEP, le WPS, le brute force sur des cartes graphiques, et j'en passe et des meilleures, le sniffage des réseaux sans fils est devenu ridiculement simple.

          • [^] # Re: Le bien fondé ?

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

            Tu as du rater l'invention du wifi toi.

            Il faut être à moins de 100 mètre de la personne (et encore, je suis gentil).
            Désolé, mais à l'échelle de la planète, cet argument est minuscule, surtout dès qu'on veut automatiser.

            Après, certes, pour le ciblage d'une personne précise valant beaucoup d'argent… Mais ça limite quand même.

            Ps : je ne dis pas qu'il ne faut pas se prémunir des failles du WiFi, il faut. Mais ce n'est pas ce qu'il y a de plus simple quand même.

          • [^] # Re: Le bien fondé ?

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

            Tu as du rater l'invention du wifi toi.

            La porté d'une telle attaque est extrêmement limité dans l'espace et dans son efficacité. Tu va faire quoi ? espionner les clients d'un hôtel ? tes voisins … Entre les PC surpuissant connectés en fibre et mal sécurisés, les offres d'hébergeurs douteux qui te font croire qu'avec l'interface magique, tu n'as pas besoin d'un adminsys ou encore les webagencies qui t'installent un joomla one shot sans contrat de maintenance et de mises à jour, il y a largement de quoi taper à une plus grande échelle. Et aussi facilement qu'en cassant du wep.

            Je ne nie pas les dangers du sniffage, des man in the middle, ni l'interet du ssl. Je dis simplement que faire croire au gens qu'ils seront en sécurité parce que leur browser fait un jolie truc vert dans la barre d'adresse n'est pas honnête. Les problèmes viennent majoritairement des clients et serveurs compromis.

            • [^] # Re: Le bien fondé ?

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

              e dis simplement que faire croire au gens qu'ils seront en sécurité parce que leur browser fait un jolie truc vert dans la barre d'adresse n'est pas honnête

              Le but avec le SSL n'est pas de dire que les gens sont en sécurité quand il y en a mais qu'il n'y a aucune sécurité quand il n'y en a pas.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Le bien fondé ?

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

                Le but avec le SSL n'est pas de dire que les gens sont en sécurité quand il y en a mais qu'il n'y a aucune sécurité quand il n'y en a pas.

                On est bien d'accord. Ceci dit les incantations ne changent pas le discours ambiant.

                De : http://www.ca-toulouse31.fr/questions-frequentes.html

                Votre session Crédit Agricole en Ligne est obligatoirement sécurisée. Ceci garantit la confidentialité des informations échangées entre vous et votre banque. Vous pouvez le constater en regardant l'icône située dans la barre en bas ou en haut de votre navigateur représentant un cadenas fermé. Tous les navigateurs détaillent dans leurs pages d'aide les informations sur leur niveau de sécurité. N'hésitez pas à les consulter.

                La sécurité de votre navigation lors de la session est assurée par l'utilisation du protocole SSL 128 bits. Reposant sur des techniques évoluées de chiffrement, celui-ci permet de garantir que le site auquel vous vous adressez est bien géré par le Crédit Agricole ainsi que la confidentialité de vos données. L'utilisation d'un certificat dans SSL (représentée par le cadenas de votre navigateur) garantit qu'aucun autre site Web ne peut usurper l'identité du site sécurisé d'origine.

                De : http://www.verisign.fr/ssl/index.html?tid=gnps

                Lorsque les clients voient le sceau VeriSign Trust™, ils savent qu'ils peuvent faire confiance au lien, au site et à la transaction.

                et on pourrait en trouver bien d'autres.

                Que va finir par retenir Miss Michu ? Si c'est vert ou bleue, c'est bon. Et peut importe que le site s'appelle en réalité www.gruick.ru.com:8081/upload/amazon/paypal.jpg.php

                Encore une fois je ne critique pas le ssl. Je critique le discours ambiant ssl = sécurisé

                • [^] # Re: Le bien fondé ?

                  Posté par . Évalué à 0.

                  Bonjour,

                  Naïvement j'ai pourtant toujours pensé que puisque SSL chiffrait les données cela permettait aussi de les sécuriser :

                  Non seulement SSL m'apparait comme un moyen de valider les identités , mais d'avoir également un chiffrement via l'utilisation d'une clef partagée avec négociation des algorithmes de chiffrement (étape de négociation), de plus SSL permet de vérifier l'intégrité des données échangées.
                  Je suis donc surpris de voir parler d'attaque type "man in the middle", entre autres choses.

                  Ai-je mal interprété :
                  > Le but avec le SSL n'est pas de dire que les gens sont en sécurité
                  si oui peux tu préciser "sécurité" stp ?

                  • [^] # Re: Le bien fondé ?

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

                    SSL securise entre ta machine et le serveur.
                    SSL ne sécurise pas ta machine (virus etc…)

                    Dire "Votre session Crédit Agricole en Ligne est obligatoirement sécurisée. " est faux, 100% faux : si ton PC est vérolé, l'attaquant voit tout (entre toi et ta machine). Tu peux juste dire que le lien entre ta machine et leur serveur est obligatoirement sécurisé. Il te reste l'interface chaise clavier à sécuriser, vérifier que ta machine est pas trouée.

                    C'est une fausse sécurité de dire que SSL suffit. Ca suffit pour un lien, pas pour l'ensemble de la chaîne (SSL ne défend pas contre la connerie humaine)

                    • [^] # Re: Le bien fondé ?

                      Posté par . Évalué à 0.

                      Compris, effectivement on n'abordait pas "sécurité" de la même manière.

                      Merci pour ta précision.

    • [^] # Re: Le bien fondé ?

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

      Je n'en vois pas réellement, pour moi c'est utile uniquement dans les cas où on veut transférer des mots de passe ou des codes de cartes de paiement.

      Mon FAI n'a aucune raison de regarder le contenu, même si pas de mots de passe. La police a l'adresse IP / le nom de domaine, ça devrait lui suffire pour ensuite demander des infos au serveur en face ou à la personne directement (à chaque bout). Et les gens ne sont pas assez sérieux pour se dire "ah tiens, cette page a un mot de passe, je dois passer ne https sinon ça craint", donc vaut mieux activé en permanence que loupé quand un mot de passe transite. Pareil tu le fais pas chez toi (tu as confiance dans ton FAI), mais quid de ta mobilité (WiFi d'un café)? Vaut mieux tout le temps.

      Il induit également une charge plus importante sur le serveur.

      AES instruction set

      Pire encore, sur beaucoup de sites, comme Linuxfr, les certificats ne sont pas valides et on les accepte donc sans trop savoir si c'est bien ou pas. On apprend donc les mauvaises habitudes aux utilisateurs.

      Ca… je n'arrête pas de répéter que LinuxFr habitue les gens à ignorer les alertes de sécurité, mais il parait que c'est une fonctionnalité avec une argumentation en béton (même si CAcert n'a toujours pas assez confiance en sa sécurité pour demander à Mozilla ou Chrome de le valider…)
      Note : on détecte que tu n'es pas utilisateur Debian, CAcert est par défaut de souvenir, hop tracé!

      • [^] # Re: Le bien fondé ?

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

        Note : on détecte que tu n'es pas utilisateur Debian, CAcert est par défaut de souvenir, hop tracé!

        De mémoire, Iceweasel inclut des certificats de Firefox et uniquement ceux-ci, donc tu te chope quand même une erreur avec Iceweasel sous Debian (même chose avec OpenJDK qui a encore des certificats différents de Firefox).

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Le bien fondé ?

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

          Je viens de tester avec le navigateur par défaut (Epiphany) de l'install par défaut (je crois, de souvenir, donc gnome) de Debian 6, et pas d'erreur.

          • [^] # Re: Le bien fondé ?

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

            C'est pour ça que j'ai parlé d'Iceweasel, Debian embarque bien CaCert mais pas Iceweasel. Il peut donc être sous Debian et avoir quand même l'erreur.

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Le bien fondé ?

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

              Tiens, Debian accepte une duplication de "lib" (la liste des certificats)? Pfff, Debian ne respecte pas ses règles! ;-)

        • [^] # Re: Le bien fondé ?

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

          Pas d'accord : chez moi (Debian Sid), CaCert est valide/connu sous Iceweasel, d'origine.
          (il est d'ailleurs dans /etc/ssl/certs/cacert.org.pem)

          alf.life

    • [^] # Re: Le bien fondé ?

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

      Et quand tu te connectes à internet sur un réseau que tu n'as pas confiance (cybercafé, hotspot wifi, université etc…)?
      As tu envie que l'admin ou un malin se faisant passer pour une passerelle puisse lire tes mails et usurper ton compte faceboob?

      • [^] # Re: Le bien fondé ?

        Posté par . Évalué à -1.

        Ca fait partie des cas que j'ai cité où https est utile.
        Par contre lire des blogs en https j'ai un peu de mal à voir l'intérêt.

        • [^] # Re: Le bien fondé ?

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

          Par contre lire des blogs en https j'ai un peu de mal à voir l'intérêt.

          ça depend du pays ou tu habite et du contenu du blog.

          • [^] # Re: Le bien fondé ?

            Posté par . Évalué à 0.

            Le certificat SSL te donne le nom de domaine du blog, c'est une information largement suffisante si le contenu du blog est public.

            • [^] # Re: Le bien fondé ?

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

              Le certificat SSL te donne le nom de domaine du blog

              Pas forcément, http://wiki.cacert.org/VhostTaskForce par exemple.

              • [^] # Re: Le bien fondé ?

                Posté par . Évalué à 2.

                Oui, et bien ? SNI (mentionné dans ton lien) est un moyen d'avoir des certificats distincts par nom de domaine sur une IP unique. Le certificat utilisé trahit bien de quel site il s'agit.

                Ensuite on peut effectivement faire un opérer un certificat pour plusieurs domaines, mais encore faut-il trouver une autorité de certification qui accepte de signer ça ? Par ailleurs il faut que les opérateurs des différents domaines aient une confiance forte les uns dans les autres pour utiliser la même clé privée, on revient donc au même : utiliser un certificat commun indique une connivence probable.

                • [^] # Re: Le bien fondé ?

                  Posté par (page perso) . Évalué à 2. Dernière modification le 08/03/12 à 00:10.

                  Entre SNI, les commonName, les certificats wildcard… y a de quoi faire.

                  Par exemple n'importe quel fournisseur de certifs commun (RapidSSL, Verisign etc.) vendent des *.mondomaine.com. Pour un hébergeur c'est nickel. Alors oui il y a connivence entre les 10 000 blogs…

                  Et à la base je répondais à :

                  le certif te donne le domaine

                  qui est juste faux (OK, en confondant domaine et TLD… genre c'était pas le cas).

            • [^] # Re: Le bien fondé ?

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

              le blog n'est pas forcement publique, ça peut etre le certificat d'une plateforme de blog. Skyblog peut etre vu comme une plateforme de dissidents ;)

              • [^] # Re: Le bien fondé ?

                Posté par . Évalué à 8.

                Skyblog peut etre vu comme une plateforme de dissidents ;)

                Des dissidents orthographiques ?

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Le bien fondé ?

      Posté par . Évalué à 2.

      Je vois deux raisons qui pour moi sont chacune suffisantes à elles seules :

      • Parce que c'est possible, Pourquoi ne pas le faire ?
      • Même si la connexion n'est pas authentifiée, ça permet de compliquer la tache de celui qui voudrait écouter la liaison.

      Pour l'argument de la charge supplémentaire : Je pense qu'elle n'est significative ni devant la puissance des machines, ni mise à coté des scripts interprétés qui génèrent les pages elle mêmes (ou même java d'ailleurs).
      D'ailleurs, je me demande, dans la charge des machines Linuxfr par exemple, quelle est la charge engendrée par le http, le https (par connexions) et celle engendrée par Ruby.
      Sinon, ya toujours moyen moins chiffrer.

      Please do not feed the trolls

      • [^] # Re: Le bien fondé ?

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

        J'ai le souvenir d'avoir lu un jour sur DLFP que Google parlait d'un overhead de 5% en HTTPS. Flemme de chercher des sources. J'en chercherai peut-être quand un anti-SSL fournira des chiffres concrets de fin du monde causé par le dit overhead…

        • [^] # Re: Le bien fondé ?

          Posté par . Évalué à 3.

          Il y a un article qui en parle ici: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html ou il parle de 2%.

          L'intérêt supplémentaire que je vois du https, et que visiblement personne n'a souligné, est l'authentification du serveur.
          Le certificat serveur permet de valider que le serveur sur lequel on se connecte à un certificat valide. Ce n'est pas parfait, mais c'est une protection supplémentaire.

    • [^] # Re: Le bien fondé ?

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

      Quelle est l'utilité concrète d'abuser du https ? Je n'en vois pas réellement, pour moi c'est utile uniquement dans les cas où on veut transférer des mots de passe ou des codes de cartes de paiement.

      En chiffrant juste les échanges de mot de passe ou d'informations confidentielles, on met un gros pointeur dessus => Tu vois, c'est ce trafic là qui t'intéresse, inutile de perdre du temps avec le reste.

      Après, on tombe dans l'habituel débat des cartes postales dans une enveloppe ou non. Mes cartes postales, même quand elles ont un contenu anodin, je les mets dans une enveloppe. Et bien, autant que possible, il en est de même pour mon trafic Internet. Je ne sais pas qui le regarde (proxy, FAI, etc.), donc moins le contenu est visible, mieux je me porte, et ce d'autant plus que certain FAI ne se gênerait pas pour observer attentivement ce que font ses abonnés : http://reflets.info/orange-le-deep-packet-inspection-est-maintenant-sur-opt-out/

      Dans mon cas particulier, j'ajouterais que j'utilise régulièrement des connexions considérées comme peu sûre (hotel, etc.). Plutôt que de penser à utiliser le https à ce moment là, et à ne pas l'utiliser quand je suis chez moi, autant l'utiliser tout le temps, ça évite les erreurs de manipulation.

      • [^] # Re: Le bien fondé ?

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

        Dans mon cas particulier, j'ajouterais que j'utilise régulièrement des connexions considérées comme peu sûre (hotel, etc.). Plutôt que de penser à utiliser le https à ce moment là, et à ne pas l'utiliser quand je suis chez moi, autant l'utiliser tout le temps, ça évite les erreurs de manipulation.

        Moi, c'est pareil, j'ai installé l'extension sur mon portable mais pas sur ma tour.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # A propos des extensions FF pour la vie privé

    Posté par . Évalué à 4.

    Adblock plus avec easylist + easyprivacy: ça bloque les pubs + peut-être les traqueurs suivant une liste
    Ghostery: blocage des traqueurs suivant une liste prédéfinie
    Noscript: blocage de tous les javascript et liste blanche à la discrétion de l'utilisateur

    Activer le Do Not Track
    Ne pas accepter les cookies tiers

    Bonus:
    Certificate Patrol: vérifie et signale les changements de certificat

    Est-ce que ces extensions ne se marchent pas dessus?
    Il y a peut-être plus optimal comme configuration.
    D'autres extensions à proposer?

    • [^] # Re: A propos des extensions FF pour la vie privé

      Posté par . Évalué à 3.

      Y'a la nouvelle extension lancée par Mozilla qui t'indique les site "notifiés" quand tu visites une page :
      https://www.mozilla.org/en-US/collusion/

    • [^] # Re: A propos des extensions FF pour la vie privé

      Posté par . Évalué à 3.

      Déjà avec adblock plus easylist+fr et noscript et ne pas accepter les cookies tiers, j'ai pas énorme de requêtes vers les trackers et aucun de leurs cookies (hormis google quoi).

      Ghostery c'est pas libre, pas forcément un problème mais du coup j'ai pas confiance (c'est pas parce que je suis parano qu'il ne sont pas après moi).
      Du coup j'ai opté pour la purge les cookies à la fermeture de firefox sauf ceux marqués comme à préserver (cookie culler ou biscuit). Je trouve ça moins contraignant et plus précis (cookie vs domaine) que la plupart des autres solutions, même si ce n'est pas parfait niveau vie privé.
      Et je purge les cookies flash avec un script (y a bien betterprivacy en extension firefox, mais je crois que c'est pas libre, et moins j'ai d'extensions mieux c'est)

      Une astuce que j'ai vu passer y a pas longtemps sur un blog quelconque: Utiliser ABE de noscript (onglet avancé) pour interdire certaines requêtes cross site (un genre de request policy du pauvre).
      Exemple qui était donné:

      # Only Facebook may embed Facebook
      Site        .facebook.com .fbcdn.net .facebook.net
      Accept from .facebook.com .fbcdn.net .facebook.net
      Deny        INCLUSION POST
      
      # Only Google may embed Google +1
      Site        plusone.google.com
      Accept from         google.com
      Deny        INCLUSION POST
      
      

      +1 pour Certificate Patrol.

      • [^] # Re: A propos des extensions FF pour la vie privé

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

        Pour ca on peut aussi rajouter une règle toute simple dans adblock qui dit à peu près ca :

        ||*.google.*/*$third-party
        ||*.facebook.*/*$third-party
        
        

        Ca évite toute utilisation de code de facebook/google sur des domaines autres que ceux de facebook ou google.

    • [^] # Re: A propos des extensions FF pour la vie privé

      Posté par . Évalué à 4.

      Personnellement j'utilise juste NoScript et RequestPolicy.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: A propos des extensions FF pour la vie privé

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

      Ne pas accepter les cookiers tiers ?!? Mais t’es fou !!! Si tu fais ça, les bouton +1 de Google ne marcheront plus !
      Je comprends d’ailleurs pas comment ça se fait.
      Moi aussi, je refuse les cookies tiers : et pourtant, même comme ça, les bouton Tweet this de Twitter ou Like de Facebook marchent bien. Y a que les +1 de Google qui ne marchent pas. Dommage, c’est les seuls que j’aimerai pouvoir utiliser.
      Tant pis, j’activerai pas les cookies tiers. Les boutons +1 se passeront de moi, et voilà.

      Je comprends aussi que Google, propriétaire du plus gros espion de l’histoire (le cookie Doubleclick et sa monstrueuse moissonneuse de données) ait intérêt à forcer l’utilisation des cookies tiers…

  • # sont fun quand même

    Posté par . Évalué à 5.

    (404 nouvelles règles depuis la version 1.2.2), c'est voulu j'imagine le nombre de règles …

  • # Quid des popups en cas de certificat auto signés ou expirés

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

    Est-ce que cette extension fait disparaître les popups d'alerte des certificats SSL auto signés ou expirés ?
    Car si c'est le cas autant dire que ça a peu d'intérêt pour se protéger contre des attaques du type Man In The Middle

  • # horrible

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

    Horrible cette énorme image flashy au milieu du texte.

    • [^] # Re: horrible

      Posté par (page perso) . Évalué à 1. Dernière modification le 08/03/12 à 14:49.

      J'ai mis une version plus réduite en taille et en poids.

Suivre le flux des commentaires

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