Journal Passer au HTTPS pour améliorer son PageRank

Posté par . Licence CC by-sa
12
8
août
2014

Google vient d'annoncer qu'il commence à prendre en compte la présence du protocole d'accès HTTPS pour évaluer le score d'un site web (PageRank) :
HTTPS as a ranking signal

J'ai commencé la construction d'un site web pour la première fois et j'ai choisi de rediriger tout le traffic vers l'HTTPS par défaut.
Il n'y a donc aucun accès possible par HTTP.

J'avoue ne pas avoir trop réfléchi à la question et jusqu'ici je n'ai vu que les 3 inconvénients suivant :
A) Il faut un installer un certificat SSL, de préférence un certificat wildcard pour la souplesse
B) Le CPU et la RAM sont plus sollicités
C) Problèmes de compatibilités ou d'accès avec certains navigateurs/logiciels

A et B correspondent à un handicap financier (il faut installer/maintenir le certificat, il faut avoir une machine plus puissante, etc.). C'est quand même assez relatif car les certificats sont devenus assez abordables (parfois même gratuits dans certain cas) et les machines de base semblent assez puissantes aujourd'hui.
Pour C, il semblerait que ce ne soit plus vraiment un problème aujourd'hui.

Si on laisse de côté le problème de fond des certificats SSL (Pourquoi ne prenez pas un certificat SSL/TLS gratuit ou payant de chez Machin qui est par défaut dans un navigateur, quelles raisons peuvent bien retenir de passer son site web au tout HTTPS ? Surtout que l'on a maintenant un réel avantage en améliorant le score du site web.

Par exemple j'ai cru voir qu'à une époque AdSense n'était pas compatible, mais cela a été corrigé.

Avez-vous donc quelques pistes intéressantes pour justifier de conserver un accès HTTP ?

  • # Noui…

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

    Je suis un peu tiraillé par la question du HTTPS. Si en soit c'est une bonne idée, j'ai l'impression que depuis Snowden on tombe dans une sorte de paranoïa (peut-être justifiée ?) où chaque page web DOIT être accessible en HTTPS. C'est souvent utile certes, mais dans le cas d'un petit site perso j'ai du mal à y voir un grand intérêt (mise à part la zone d'administration). La dernière fois que j'ai écrit un article là-dessus, on m'a fait remarquer (avec raison) que HTTPS a deux fonctions :

    • Chiffrer les échanges (dans le cas d'un petit blog je trouve l'intérêt très limité)
    • Identifier un site pour s'assurer qu'il est bien celui qu'il dit être. Problème ? Souvent les gens se contentent d'un certificat auto-signé. Du coup pourquoi devrais-je faire confiance à ce certificat ? On pourrait très bien essayer de me faire accepter n'importe quoi… Le pire étant quand on me force à l'accepter car pas d'accès HTTP (généralement je quitte simplement la page)

    Donc voilà : je m'interroge sur l'intérêt du HTTPS dans certains cas, encore plus quand on nous demande (ou force !) d'accepter un certificat auto-signé…

    • [^] # Re: Noui…

      Posté par . Évalué à 10.

      Pour ma part, je pense que HTTPS apporte un mieux, pour pas grand chose, le surcoût CPU/RAM étant très limité

      – Avoir du HTTPS partout rend plus difficile l'espionnage de masse, c'est une très bonne chose.
      – Avoir du HTTPS partout limite l'utilisation des techniques genre DPI au niveau du FAI, c'est une très bonne chose.
      – Dès qu'un site permet une authentification, on devrait obligatoirement avoir du HTTPS, pour le login/mot de passe. Or aujourd'hui la plupart des site perso sont basé sur des trucs genre Wordpress, Mediawiki, etc, qui utilise une authentification. Donc si on met en place HTTPS pour la partie admin, ça ne coûte pas grand chose à faire pour le reste…

      Globalement il me semble que la généralisation d'HTTPS favorise un environnement sécurisé, pour un surcoût faible.

      Par contre je suis absolument contre le certificat auto-signé. D'un point de vue utilisateur, c'est vraiment catastrophique: les gens prennent l'habitude d'accepter n'importe quoi, ce qui abaisse la sécurité globale.

      • [^] # Re: Noui…

        Posté par . Évalué à 2.

        +1

        de plus l'utilisation d'un certificat auto signé pour un site visant une audience publique c'est vraiment se rajouter un handicape inutilement en effrayant le visiteur avec un gros avertissement de sécurité.
        L'effet inverse du résultat escompté

      • [^] # Re: Noui…

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

        Par contre je suis absolument contre le certificat auto-signé. D'un point de vue utilisateur, c'est vraiment catastrophique: les gens prennent l'habitude d'accepter n'importe quoi, ce qui abaisse la sécurité globale.

        Entièrement d'accord avec toi ! Si au moins la mise en place était bien faite, je ne dis pas, mais quand on me demande d'accepter un certificat auto-signé pour lire un article de blog, pour le moment je regarde si je peux y accéder en HTTP mais un de ces jours je ne ferais même plus cet effort.

        Perso, j'ai mis en place un certificat (au début auto-signé) que j'utilise uniquement pour la partie administration : c'est le mien, je sais la tête qu'il doit avoir. Le reste du site / blog est en accès par HTTP par défaut. Mais maintenant que j'ai un certificat certifié par StartSSL je continue de même parce que j'en ai marre de cette paranoïa. C'est un peu comme si je devais me déguiser avec un chapeau, des lunettes de soleil, une fausse moustache et un long manteau noir pour aller voir mon voisin… je trouve ça aberrant (mais j'ai bien conscience que c'est parfois nécessaire vu les excès en matière d'espionnage, DPI, etc.).

        De plus, si la mise en place d'un certificat est facile pour un domaine, ça commence à devenir galère pour du multi-domaine avec des sous-domaines dans tous les sens…

        • [^] # Re: Noui…

          Posté par . Évalué à 2.

          je continue de même parce que j'en ai marre de cette paranoïa

          Personnellement je ne me suis même pas posé ce genre de questions philosophiques.
          En gros tu peux trouver pleins de bonnes raisons pour utiliser HTTPS (voir plus haut le message d'Adrien par exemple) et quand je demande les inconvénients c'est presque le vide complet.
          Donc vu la facilité avec laquelle j'ai mis cela en place et le coût relatif, le choix a été vite fait.

          De plus, si la mise en place d'un certificat est facile pour un domaine, ça commence à devenir galère pour du multi-domaine avec des sous-domaines dans tous les sens

          Est-ce qu'un certificat wildcard ne règle pas ce problème ? oui c'est un peu plus cher…

          • [^] # Re: Noui…

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

            Le seul inconvénient du HTTPS, c'est qu'il n'est pas possible de mettre les pages dans un cache de manière globale. C'est-à-dire que si tu un réseau un peu conséquent et que tu veux cacher le JS de Google ou les vidéos Youtube pour tous tes clients, ce n'est pas possible (sans faire du MitM).

            « 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: Noui…

              Posté par . Évalué à -1.

              Si t'as un réseau conséquent, tu contactes le fournisseur de service et il met un cache dans ton réseau.

              • [^] # Re: Noui…

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

                Si tu as un réseau conséquent au point que le fournisseur de service vienne mettre un cache chez toi, c'est que tu es un gros FAI et que tu ne devrais pas faire de cache. Je pensais plutôt des entreprises où il y a beaucoup de personnes derrière une seule ligne.

                « 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: Noui…

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

              Pas seulement le cache global, le cache local est également affecté : à moins que ça ait changé, les navigateurs tels que Firefox ne stockent pas sur le disque les fichiers téléchargés en HTTPS.

              À chaque redémarrage du navigateur, il faut donc re-télécharger tous les CSS, JS et autres éléments du design des sites.

              alf.life

              • [^] # Re: Noui…

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

                Et bien je n'avais pas re-vérifier depuis longtemps visiblement, Firefox a effectivement changé de comportement en 2010, car il était le seul à ne pas mettre en cache.

                alf.life

        • [^] # Re: Noui…

          Posté par . Évalué à 5.

          C'est un peu comme si je devais me déguiser avec un chapeau, des lunettes de soleil, une fausse moustache et un long manteau noir pour aller voir mon voisin… je trouve ça aberrant (mais j'ai bien conscience que c'est parfois nécessaire vu les excès en matière d'espionnage, DPI, etc.).

          Tu n'est pourtant pas à poil dans la rue, mais habillé, et en été ou sur la plage, ça n'est pas pour se protéger du froid ;-)

          Préserver son intimité et sa vie privée n'est pas aberrant…

      • [^] # Re: Noui…

        Posté par . Évalué à 6.

        Par contre je suis absolument contre le certificat auto-signé. D'un point de vue utilisateur, c'est vraiment catastrophique: les gens prennent l'habitude d'accepter n'importe quoi, ce qui abaisse la sécurité globale.

        Il y a une règle empirique que j'essaye de valider sur le net : Toute assertion débutant par « les gens » est une ânerie.

        Je suis un utilisateur, et un "gens", et j'apprécie les certificats auto-signés. Comme beaucoup d'autres utilisateurs, et gens, je sais ce que je fais, et je ne m'habitue pas. Merci.

        Please do not feed the trolls

        • [^] # Re: Noui…

          Posté par . Évalué à 6.

          Comme beaucoup d'autres utilisateurs, et gens, je sais ce que je fais, et je ne m'habitue pas. Merci.

          Je vais donc appliquer ta règle. Tu as des sources ? des études ? des chiffres fiables ? ou le « beaucoup d'utilisateur », c'est juste aussi bidon que moi ?

          Perso je parle d'expérience : au boulot les certificats auto-signés engendrent des réactions mitigées : j'appelle le support pour savoir quoi faire avant de faire une connerie (en général des gens peu à l'aise avec l'outil informatique) au je clique suivant suivant pour avoir la page, sans vraiment comprendre les conséquence. Ceux qui lisent effectivement le message et le comprennent sont une infime minorité (navigateur: firefox).

          Effectivement, je n'ai pas d'étude sous la main, uniquement l'approche empirique auprès de plusieurs centaines de gens. Si quelqu'un à des données plus fiable, objective, ça serait intéressant.

      • [^] # Re: Noui…

        Posté par . Évalué à 6.

        Je suis d'accord avec tous tes points (sauf pour le certificat auto-signé), mais malgré tout, je trouve ça profondément débile que la présence ou l'absence de HTTPS entre en ligne de compte dans le PageRank. La présence ou l'absence de HTTPS ne donne absolument aucune indication sur la pertinence d'un résultat. Or, un moteur de recherche est quand même censé être là pour nous donner une liste de résultats pertinents.
        A la limite, pourquoi pas un filtre que l'utilisateur pourrait activer "je souhaite prioriser les sites utilisables en HTTPS"…

        • [^] # Re: Noui…

          Posté par (page perso) . Évalué à -3. Dernière modification le 08/08/14 à 16:54.

          je trouve ça profondément débile que la présence ou l'absence de HTTPS entre en ligne de compte dans le PageRank.

          Pas moi : la présence de HTTPS montre le respect qu'a l'admin des préférences de l'utilisateur. C'est justement une très bonne idée que de regarder comment l'admin prend en compte les utilisateurs.
          J'espère que Google fera aussi de même prochainement pour IPv6 (pour la même raison).

          • [^] # Re: Noui…

            Posté par . Évalué à 5.

            Je vois pas le rapport entre le respect de l'admin et la pertinence de la réponse… Perso, quand je fais une recherche, j'en ai rien à secouer de l'état d'esprit de l'admin et de son soi-disant respect vis à vis de l'utilisateur. Je veux juste un lien vers un site qui donne une réponse pertinente à ma question. Et la présence / absence de HTTPS n'a aucun lien avec cette pertinence.

        • [^] # Re: Noui…

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

          J'ai cru comprendre que le critère "https" ne devient pas d'un coup LE critère principal :

          […] so we're starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content […]

          Source

          Voir le billet de Benjamin Sonntag sur le sujet.

          • [^] # Re: Noui…

            Posté par . Évalué à 6.

            Oui, heureusement, ça n'est pas le critère principal. Mais au fur et à mesure, Google ajoute des critères qui (pour moi) ne sont pas liés à la pertinence : temps de chargement de la page (si un site met 2 minutes à charger, OK, je vais abandonner, mais en soi ça n'est pas un critère de pertinence, et au pire, ça pourrait être un message d'information à côté du résultat), "fraîcheur" de l'information, et maintenant HTTPS… Et peut-être d'autres que je ne connais pas, je ne suis pas spécialiste SEO.

            L'entreprise fait ce qu'elle veut, c'est son algo et peut-être que ça plaît à la majorité des clients, mais je trouve que la pertinence de mes recherches sur leur moteur est de moins en moins bonne. C'est peut-être également lié à l'évolution des sites web, je n'en sais rien.

            • [^] # Re: Noui…

              Posté par . Évalué à 1.

              temps de chargement de la page (si un site met 2 minutes à charger, OK, je vais abandonner, mais en soi ça n'est pas un critère de pertinence, et au pire, ça pourrait être un message d'information à côté du résultat)

              La pertinence c'est le fait de te fournir l'information le plus efficacement possible. Si à la question "va-t'il faire beau demain ?", je te répons "oui" est-ce que ce plus ou moins pertinent que si je te fourni l'ensemble des données mesurées ces 5 derniers jours, les statistiques de ces 4 dernières années, les algo d'analyses qui vont avec et que je finis en t'expliquant que ben oui il va faire beau ?

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

              • [^] # Re: Noui…

                Posté par . Évalué à 2.

                Je ne vois pas le rapport avec ce que j'ai écrit ?

                • [^] # Re: Noui…

                  Posté par . Évalué à 2. Dernière modification le 11/08/14 à 14:55.

                  L'important c'est que le temps entre le moment où tu commence ta recherche et le moment où tu as l'information soit le plus court possible (pas de passer 5 jours de formation pour pouvoir déduire la réponse).

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

        • [^] # Re: Noui…

          Posté par . Évalué à 2.

          La présence ou l'absence de HTTPS ne donne absolument aucune indication sur la pertinence d'un résultat.

          En fait ce n'est pas si simple. L'objectif de google search ce n'est pas simplement d'être pertinent, mais de fournir la meilleure expérience possible et pour cela de retourner des pages entre autre qui sont accessibles, qui existent encore, qui ne prennent pas 20 minutes à charger, qui ne sont pas vérolées par de vielles XSS, etc

          Tu préfèrera avoir une page simple rapide à chargée, en https, accessibles aux handicapés qui donne à peu près la bonne réponse, que la thèse qui donne le résultat précis en 160 pages au format djvu.

          Donc oui la frontière entre ce qui est pertinent est ce qui ne l'est pas n'est pas aussi simple que ça. Mais oui Google se sert aussi de son moteur de recherche pour faire évoluer les habitudes (c'est par exemple le cas de l'accessibilité, à la fois ça incite aux bonnes pratiques à la fois c'est bon pour les utilisateurs de google).

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

          • [^] # Re: Noui…

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

            L'objectif de google search ce n'est pas simplement d'être pertinent, mais de fournir la meilleure expérience possible et pour cela de retourner des pages entre autre qui sont accessibles, qui existent encore, qui ne prennent pas 20 minutes à charger, qui ne sont pas vérolées par de vielles XSS, etc

            Pourtant il mets souvent en avant des sites bloated de js tiers de chez google!

            http://devnewton.bci.im

    • [^] # Re: Noui…

      Posté par . Évalué à 10.

      Donc voilà : je m'interroge sur l'intérêt du HTTPS dans certains cas, encore plus quand on nous demande (ou force !) d'accepter un certificat auto-signé…

      Même avec un certificat auto-signé, la sécurité du https est strictement supérieure à celle du http. Le https avec un certificat auto-signé c'est le chiffrement sans l'authentification (si le certificat est accepté aveuglément), c'est mieux que sans chiffrement ET sans authentification.

      En revanche, je reconnais que j'aimerais avoir une grosse icône dans mon navigateur qui me rappelle que le certificat est auto-signé, et je regrette que la case "se souvenir du certificat pour les prochaines sessions" soit cochée par défaut.

      Please do not feed the trolls

      • [^] # Re: Noui…

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

        Même avec un certificat auto-signé, la sécurité du https est strictement supérieure à celle du http.

        Pluzun. C'est d'ailleurs un gros problème des navigateurs actuels, pour lequel j'avais ouvert un rapport de bogue sur Firefox : lorsqu'un utilisateur se connecte sur un serveur dont le certificat ne peut pas être validé, il y a un avertissement effrayant, alors que lorsqu'il envoie en clair un mot de passe, ce qui est bien pire, il n'y a aucun avertissement.

      • [^] # Re: Noui…

        Posté par . Évalué à 3.

        En revanche, je reconnais que j'aimerais avoir une grosse icône dans mon navigateur qui me rappelle que le certificat est auto-signé, et je regrette que la case "se souvenir du certificat pour les prochaines sessions" soit cochée par défaut.

        Autant, je suis d'accord sur la seconde partie de la phrase (sur le rappel dans le navigateur), autant je ne suis pas d'accord sur la seconde partie ("se souvenir…"). En effet, se souvenir d'un certificat pour un site donné permet d'être averti en cas de changement du certificat, ce qui peut-être un signe de Man-In-The-Middle… Par contre, on peut sans doute améliorer les messages affichés dans ce cas précis.

      • [^] # Re: Noui…

        Posté par . Évalué à 2.

        Même avec un certificat auto-signé, la sécurité du https est strictement supérieure à celle du http.

        Si je me trompe pas j'irais même plus loin: avec un certificat auto-signé, la sécurité du https est strictement supérieure à celle du https, pour l'utilisation https en chiffrement du trafic (pas pour l'authentification)
        Pourquoi? Parce qu'on a pas besoin d'un tiers pour générer son certificat ce qui peut être problématique car une partie de la sécurité repose sur ce tiers qui peut être compromis.

        Cette conférence est très intéressante sur ce qui concerne le SSL et la sécurité: DEFCON 17: More Tricks For Defeating SSL

        • [^] # Re: Noui…

          Posté par . Évalué à 4.

          Pourquoi? Parce qu'on a pas besoin d'un tiers pour générer son certificat ce qui peut être problématique car une partie de la sécurité repose sur ce tiers qui peut être compromis.

          L'autorité de certification n'a pas à voir la partie privée du certificat, donc il n'y a pas moins de sécurité pour le chiffrement.

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

      • [^] # Re: Noui…

        Posté par . Évalué à 7.

        Le https avec un certificat auto-signé c'est le chiffrement sans l'authentification (si le certificat est accepté aveuglément). c'est mieux que sans chiffrement ET sans authentification.

        CERTAINEMENT PAS !!!

        Sans authentification, tu ne peux garantir la confidentialité. Si t'as de la chance c'est bon, sinon le certificat est forgé par un gars entre toi et le serveur. Et tu es incapable de savoir ce que t'es écouté.

        Tu contournes le problème de l'authent par un sybillin "(si le certificat est accepté aveuglément)". Le problème c'est que même en vérifiant les champs du certificat, si tu ne sais pas à quoi t'attendre (en gros avec du certificate pinning ou en connaissant avant les empreintes, ce qui est très rapidement ingérable), tu peux te faire forger TOUS les champs (c'est même faisable à la volée en plus).

        • [^] # Re: Noui…

          Posté par . Évalué à 4. Dernière modification le 08/08/14 à 17:14.

          Il y a de plus un truc pire que l'absence de sécurité qui est le faux sentiment de sécurité. Quand tout passe en clair, on le sait (ou on devrait le savoir), donc on s'adapte. Si le truc dit que c'est chiffré, c'est bon on peut se lâcher. Euh wait, c'est autosigné, donc c'est pas fiable ? En fait, on va rien dire de sensible. Du coup pourquoi chiffrer ?

          edit : Shit, ca m'a bouffé un bout du message.
          Enfin, aujourd'hui, les gens dont on cherche à se protéger (FAI, grandes noreilles) s'interressent plus à l'existence d'une communication qu'à son contenu. Du coup chiffrement ou pas, ca n'a pas vraiment d'importance.
          Pour finir j'ajouterai que pour ces gens la, le certificat autosigné, c'est que du bonheur

          • [^] # Re: Noui…

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

            Parce que c'est mieux que de ne pas chiffrer du tout. Le chiffrement sans authentification est vulnérable aux attaques par réécriture, mais pas aux écoutes passives.

            • [^] # Re: Noui…

              Posté par . Évalué à 1.

              Et donc, on donne son numéro de CB sur un site autosigné ou pas ?

              • [^] # Re: Noui…

                Posté par (page perso) . Évalué à 5. Dernière modification le 08/08/14 à 17:24.

                Non, et ça tombe bien, on n'a pas besoin. Les paiements se font sur le site d'un intermédiaire de paiement qui est tout à fait sécurisé.

                En revanche, pour, disons, le wiki d'un projet quelconque, il est préférable de transmettre son mot de passe en HTTPS sans authentification du serveur, que de le transmettre en clair, bien que le navigateur rendre cette seconde pratique moins effrayante que la première.

                • [^] # Re: Noui…

                  Posté par . Évalué à 0.

                  En revanche, pour, disons, le wiki d'un projet quelconque, il est préférable de transmettre son mot de passe en HTTPS sans authentification du serveur, que de le transmettre en clair

                  Pourquoi?
                  Les deux sont strictement équivalent d'un point de vue sécurité, tu n'as aucune garantie que quelqu'un dans la chaine n'est pas en train d'écouter le traffic. Un mitma synchrone sur du https auto signe est tres simple a mettre en oeuvre, surtout a l'heure du wifi gratuit un peu partout.
                  Du https auto signe, ca sert juste a bouffer des cycles cpu et du réseau a faire des handshakes de partout.

                  bien que le navigateur rendre cette seconde pratique moins effrayante que la première.

                  Si le deuxième ne fait pas gueuler le browser, c'est parce qu'il n'est pas capable de detecter que t'envoie un mot de passe. Et encore, si tu fais du http basic auth, safari va te prévenir avant d'envoyer le mot de passe sur du http.

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

        • [^] # Re: Noui…

          Posté par . Évalué à 7.

          Le https avec un certificat auto-signé c'est le chiffrement sans l'authentification (si le certificat est accepté aveuglément). c'est mieux que sans chiffrement ET sans authentification.

          CERTAINEMENT PAS !!!

          CERTAINEMENT !

          Par exemple, pour voler mot passe sur une connexion HTTP il faut juste pouvoir écouter ce qui passe. La même sur une connexion HTTPS avec un certificat auto-signé, il faire un vrai man in the middle, se faire passer pour client auprès du serveur (ça, c'est facile) et se faire passer pour le serveur auprès du client, ça suppose de pouvoir être actif sur le réseau, ce qui exclus beaucoup d'attaques. Donc la sécurité qu'offre le HTTPS est strictement supérieure à celle qu'offre le HTTP. Dit autrement, et sauf erreur de ma part, il n'existe aucune attaque qui est possible sur le HTTPS mais pas sur le HTTP. Bref, le HTTPS est plus sûr.

          Please do not feed the trolls

          • [^] # Re: Noui…

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

            même sur une connexion HTTPS avec un certificat auto-signé, il faire un vrai man in the middle, se faire passer pour client auprès du serveur

            Ca, OK…

            Par exemple, pour voler mot passe sur une connexion HTTP il faut juste pouvoir écouter ce qui passe.

            Mauvais codeur, virer ce codeur.
            On a inventé certaines choses pour ne pas voler le pass en HTTP…

            • [^] # Re: Noui…

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

              Ces techniques nécessitent un stockage du mot de passe en clair sur le serveur, et sont donc à éviter.

              • [^] # Re: Noui…

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

                Ah
                "The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss[3]) to store HA1 rather than the cleartext password"
                J'avais vu d'autres implémentations (Yahoo mail par exemple de mémoire).

                Mais de manière générale, oui, c'est un pis aller (on ne peut pas mettre de bcrypt etc…). Faut juste arrêter de croire que "le pass passe en clair" en HTTP : ce n'est pas parfait, mais on peut gérer.

                • [^] # Re: Noui…

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

                  The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss[3]) to store HA1 rather than the cleartext password

                  De sorte que HA1 devient le véritable mot de passe, stocké en clair sur le serveur. Supaire.

                  • [^] # Re: Noui…

                    Posté par . Évalué à 2.

                    Il y a des moyens de contrer ça, en rajoutant un sel qui change régulièrement. Enfin bref, c'est faisable, par contre c'est clair que ce n'est pas la stratégie adoptée par la plupart des sites ou "applications" Web.

      • [^] # Re: Noui…

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

        et je regrette que la case "se souvenir du certificat pour les prochaines sessions" soit cochée par défaut.

        +1

        Et je n'ai jamais compris (bon, j'ai pas trop cherché non plus) le pourquoi de ce choix étonnant, d'autant qu'il me semble que ce choix par défaut ne peut pas être changé dans les préférences.

        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: Noui…

      Posté par . Évalué à 3.

      Quid du cache des proxy en HTTPS ? ils sont un peu niqués du coup, non ?

      • [^] # Re: Noui…

        Posté par . Évalué à 0.

        Aucun problème de mon côté avec Varnish et l'HTTPS.

        • [^] # Re: Noui…

          Posté par . Évalué à 1.

          Zut voir la réponse plus bas : j'ai confondu proxy et reverse-proxy

    • [^] # Re: Noui…

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

      J'ai souvent entendu ce "mais de toute façon mon site c'est juste du contenu public, statique". La tu pars du principe que passer en HTTPS a un cout non négligeable. Je pense au contraire que le cout est négligeable (je ne prends pas en compte la cabale mondiale des CA qui est un non-sens total) et qu'il faudrait plutôt expliquer pourquoi rester en HTTP.

      Comme dit plus bas, dans le pire des cas, HTTPS non authentifié est moins pire que HTTP tout nu, et pourtant le deuxième ne lève aucun avertissement. Parce qu'en fait, ton problème, c'est pas tant HTTP vs HTTPS: c'est surtout que tu veux pas avoir a cliquer de bouton en plus juste pour lire ce satané contenu. Il faudrait donc inverser la réaction du navigateur entre HTTP tout nu et HTTPS non authentifié: le premier pose de gros problème, le deuxième est potentiellement dangereux mais on laisse l'utilisateur juger si le site est le bon ou pas.

      Sinon dans les avantages, j'en vois un autre intéressant quand même: tu es sur que le contenu n'a pas été modifié. Encore une fois, depuis l'endroit ou se situe la clé privée associée au certificat.

    • [^] # Re: Noui…

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

      Tiens, ça va te plaire: https://www.youtube.com/watch?v=kLt_uqSCEUA

      Ça explique comment un homme du milieu peut injecter du js dans tes pages pour ensuite espionner le trafic même quand tu ne passes plus par cet homme du milieu. Si la page était chiffrée, il n'y aurait pas ce problème.

  • # Objets externes

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

    Et si la moitié du code dudit site web provient d'objets externes (images, video youtube, script JS, etc…) qui sont hebergés sans https. Ca compte comlebt dans le ranking?

    • [^] # Re: Objets externes

      Posté par . Évalué à -1.

      Déjà tout dépend du type de contenu. Si sur une page en https tu as des images en http elles seront chargées. De mémoire, le CSS aussi. Par contre si c'est un script appelé en http in ne sera pas chargé.

  • # Idem, pour mon premier site web, tout est en HTTPS

    Posté par . Évalué à 2.

    Et bien tout comme toi, j'ai lancé mon petit site web perso, et j'ai choisi de tout passer en HTTPS.
    Reste l'envoi des emails avec SSL que je ne sais pas faire.
    Le site web que j'ai est très simple :
    - VPS OVH à 3€/mois
    - Serveur courriels
    - Owncloud
    - Wordpress
    - deux ou trois trucs sur les côtés "pour le fun".

    Le plus compliqué reste à trouver des certificats SSL abordables. En gros, un certificat pour un nom de domaine coute 5 à 10€ et un wildcard entre 50 et 100€ (après, on peut trouver encore plus cher où seule la garantie si ça foire est plus importante financièrement parlant).

    Le seul argument qui tient vraiment la route (je ne dis pas que je suis d'accord avec, je suis même anti-pub et n'hésite pas à payer pour certains sites, mais c'est ce que j'ai lu sur le web) concernant la difficulté d'avoir du HTTPS partout concerne la pub sur les sites web : en effet, peu de vendeur de pub propose du HTTPS.

    • [^] # Re: Idem, pour mon premier site web, tout est en HTTPS

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

      Tu peux passer par StartSSL qui propose des certificats reconnus gratuits pour un domaine + un sous-domaine. Il y a CACert aussi qui fonctionne un peu différemment (communautaire toussa toussa) mais qui n'est pas aussi bien reconnu par les navigateurs.

    • [^] # Re: Idem, pour mon premier site web, tout est en HTTPS

      Posté par . Évalué à 0. Dernière modification le 08/08/14 à 13:29.

      Reste l'envoi des emails avec SSL que je ne sais pas faire.

      Tu n'arrives pas à configurer pour utiliser TLS ?
      Je n'ai pas souvenir d'avoir eu beaucoup de difficultés.

      Le plus compliqué reste à trouver des certificats SSL abordables. En gros, un certificat pour un nom de domaine coute 5 à 10€ et un wildcard entre 50 et 100€.

      Tu peux trouver des certificats wildcard gratuits sous certaines conditions. Par exemple au hasard (je n'ai pas essayé, j'ai juste pris le premier lien sous Google) :
      Free SSL Certificates for Open Source Projects

      Le seul argument qui tient vraiment la route (je ne dis pas que je suis d'accord avec, je suis même anti-pub et n'hésite pas à payer pour certains sites, mais c'est ce que j'ai lu sur le web) concernant la difficulté d'avoir du HTTPS partout concerne la pub sur les sites web : en effet, peu de vendeur de pub propose du HTTPS.

      Ah voilà une raison valable ! Comme marqué dans mon journal, AdSense est passé au HTTPS. Je suppose que les autres ne vont pas tarder.

  • # Consommation ressource

    Posté par . Évalué à 4.

    B) Le CPU et la RAM sont plus sollicités

    C'est négligeable, cf : https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

    De la crypto lourde c'est rien par rapport à des pages « légère » en php.

    Please do not feed the trolls

  • # Redirection HTTPS

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

    J'ai commencé la construction d'un site web pour la première fois et j'ai choisi de rediriger tout le traffic vers l'HTTPS par défaut.

    Ce qui est une grave erreur. En effet, le visiteur peut ainsi s'habituer à taper l'adresse sans HTTPS et se reposer sur la redirection sans y prêter attention. En cas d'attaque, la première chose que fera un pirate en interception et réécriture sera de faire sauter la redirection en question et de laisser l'internaute rester en HTTP.

    Il y a plusieurs alternatives à cette approche dangereuse :

    1. ne pas fournir du tout d'accès HTTP : l'internaute qui essaie sans HTTPS tombe sur un refus de connexion et doit de facto s'habituer à bien demander du HTTPS ;
    2. fournir un simple page d'erreur en HTTP, expliquant qu'il faut bien taper HTTPS ;
    3. utiliser HSTS, l'internaute essayant en HTTP se retrouvant dirigé en HTTPS et son navigateur retenant cela pour ne plus jamais y accéder en HTTP.
    • [^] # Re: Redirection HTTPS

      Posté par . Évalué à 2.

      1. ne pas fournir du tout d'accès HTTP : l'internaute qui essaie sans HTTPS tombe sur un refus de connexion et doit de facto s'habituer à bien demander du HTTPS ;
      2. fournir un simple page d'erreur en HTTP, expliquant qu'il faut bien taper HTTPS ;

      Je suis un peu mitigé sur l'idée.
      Est-ce que tu aurais quelques statistiques sur l'effet de ce genre de politique ?
      Il ne me semble jamais avoir vu de site web avec ce genre de système en place, tu as des examples ?

      1. utiliser HSTS, l'internaute essayant en HTTP se retrouvant dirigé en HTTPS et son navigateur retenant cela pour ne plus jamais y accéder en HTTP.

      J'avoue y avoir pensé mais avant de mettre une longue durée pour max-age, j'attendais un peu d'avoir les réponses à mes interrogations dans mon journal.
      Si quelqu'un arrive avec des raisons valables de garder un accès HTTP, je vais peut-être remettre en question pas mal de choses.

    • [^] # Re: Redirection HTTPS

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

      Si le pirate est en mesure d'intercepter le flux réseau, alors il fait ce qu'il veut.
      Il redirige vers n'importe quel site.

      HSTS n'y change rien non plus (pour les nouveaux visiteurs, ça protège tout de même les anciens). Le pirate ne va pas transmettre l'en-tête HSTS donc basta.
      Et il fait échouer les requêtes vers HTTPS pour être bien certain que la victime ne puisse pas tomber dessus par hasard. D'ailleurs ça se passe comment pour ceux qui ont déjà visité le site ? Ils peuvent facilement dire au navigateur de passer outre ? Ce serait dommage.

    • [^] # Re: Redirection HTTPS

      Posté par . Évalué à 5.

      ne pas fournir du tout d'accès HTTP : l'internaute qui essaie sans HTTPS tombe sur un refus de connexion et doit de facto s'habituer à bien demander du HTTPS ;
      fournir un simple page d'erreur en HTTP, expliquant qu'il faut bien taper HTTPS ;

      Oui, enfin a ce compte la, si tu t'adresses au grand public, autant plier les gaules et partir élever des chèvres dans le larzac, je te garantit qu'une grande majorité des gens n'arriveront pas a accéder a ton site.

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

      • [^] # Re: Redirection HTTPS

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

        une grande majorité des gens n'arriveront pas a accéder a ton site

        s/n'arriveront pas/& ni ne voudront/

        parce même moi, ça me ferrait chier et je ne continuerais que si j'ai certaines garanties que ça en vaille la peine.

        « 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

  • # Et si on passait à un truc genre DKIM ?

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

    Dans le système de signature DKIM, le serveur qui reçoit le mail va aller chercher un élément (je sais pas lequel) dans un enregistrement DNS kivabien pour valider la signature du mail. Du coup, pas d'autorité de certification, pas de frais, pas de "certificat signé par une autorité de certification non reconnue"

    Pourquoi on passerait pas à un truc comme ça ? Éventuellement, on pourrait imaginer un système de réplication de l'enregistrement DNS sur un autre domaine DNS, histoire que quelqu'un qui prend le contrôle du DNS ne puisse pas juste remplacer la clé. Ou alors se reposer sur un truc style protocole bitcoin (ou bitcloud ! http://bitcloudproject.org/) pour stocker la clé de validation ?

    It's a fez. I wear a fez now. Fezes are cool !

    • [^] # Re: Et si on passait à un truc genre DKIM ?

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

      On ne t'a pas attendu pour ça !

      https://en.wikipedia.org/wiki/DANE
      http://www.bortzmeyer.org/6698.html
      https://tools.ietf.org/html/rfc6698

      Reste à convaincre les éditeurs de logiciels clients de s'y mettre. Bon courage.

    • [^] # Re: Et si on passait à un truc genre DKIM ?

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

      Pourquoi on passerait pas à un truc comme ça ?

      Ça existe, c’est le DNS-based Authentication of Named Entities. Mais ce n’est ni répandu dans les domaines ni supporté nativement par les navigateurs (je n’en connais aucun qui supporte ça nativement — il y a une extension Firefox, et je suis en train de bidouiller un plugin pour Uzbl).

      En plus, ça dépend de DNSSEC, qui lui aussi n’est ni largement répandu ni bien supporté par les clients.

      Je crois quand même pas mal à ce système, même si au final je penche plutôt pour une cohabitation entre plusieurs méthodes d’authentification, et laisser le client utiliser celle(s) qu’il veut. Par exemple, sur ma machine j’ai quatre méthodes pour vérifier un certificat :

      • le système PKIX (l’infrastructure actuelle basée sur des « autorités de certifications » jugées dignes de confiance par les navigateurs) ;
      • Monkeysphere (validation par la toile de confiance OpenPGP) ;
      • DANE ;
      • le « suivi de certificat » (modèle « trust on first use », à la manière de SSH : on garde une trace du certificat associé à chaque hôte, et on vérifie à chaque nouvelle connexion que le certificat présenté est bien le même que celui précédemment associé à cet hôte).

      J’accepte automatiquement un certificat s’il est validé par au moins une des méthodes sans être strictement invalidé par aucune autre.

    • [^] # Re: Et si on passait à un truc genre DKIM ?

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

      Comme dit en dessous, c'est DANE. Le problème de DANE est qu'il part du principe que les enregistrements DNS arrivent intacts depuis le NS du domaine jusqu’à chez toi, ce qui est pour le moment hautement illusoire. Il faut utiliser DNSSEC (ou autres) pour acheminer les enregistrements, mains DNSSEC c'est une autre paire de manches a installer et maintenir.

      Ou alors se reposer sur un truc style protocole bitcoin (ou bitcloud ! http://bitcloudproject.org/) pour stocker la clé de validation ?

      Et bien justement, dnschain permet ça. Le principe est simple: il y a deja des specifications pour enregistrer ses noms de domaines et son identite dans Namecoin. Malheureseument Namecoin c'est son monde a part avec son client specialement fait pour. C'est la que dnschain fait le pont, puisqu'il permet d'acceder aux informations depuis des moyens connus:

      $ dig @dns.dnschain.net okturtles.bit
      
      $ curl http://dns.dnschain.net/d/okturtles
      
  • # Serveur Proxy

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

    Un autre inconvénient de l'HTTPS est qu'on ne peut plus utiliser de proxy cache (à moins que j'ai raté un truc).

    • [^] # Re: Serveur Proxy

      Posté par . Évalué à -1.

      Même réponse que plus haut : j'utilise Varnish et cela marche très bien avec HTTPS.
      J'ai juste mis Nginx devant pour interpréter l'HTTPS et il se débrouille après avec Varnish.
      Il y a 2-3 trucs à configurer pour mettre les bons en-têtes mais j'étais loin d'être le premier à faire cela et on trouve pleins d'explication sur internet.

      • [^] # Re: Serveur Proxy

        Posté par . Évalué à 3.

        Le problème est plutôt du côté client. Un service proxy en coupure n'a aucun moyen de mettre en cache les connexions HTTPS. Or ceci est assez utile lorsque l'on veut économiser de la bande passante.

    • [^] # Re: Serveur Proxy

      Posté par . Évalué à 3.

      J'ai croisé, en entreprise, des proxies qui forgeaient des certificats à la volée pour les sites en https. L'autorité de certification était ajoutée au master du poste utilisateur dans le navigateur par défaut (IE ou FF dans mes cas).
      Cela n'était détectable que dans un navigateur vanillia, genre portable FF. Très dangereux car dans un cas, le proxy acceptait les certificats auto-signés sans avertir l'utilisateur. Le navigateur ne pouvait pas le détecter puisque le certificat qui lui était présenté était valide.
      Je pense que c'est avant tout pour inspecter le flux (fuite d'information tout ça), mais dans cette configuration, rien n'empêche de faire de la mise en cache.

      • [^] # Re: Serveur Proxy

        Posté par . Évalué à 2.

        Est-ce que c'est légal en France ça ?

        Please do not feed the trolls

        • [^] # Re: Serveur Proxy

          Posté par . Évalué à 3.

          Je me suis aussi posé la question car sans y prêter attention, il est possible de se connecter à sa banque, en clair pour l'administrateur du proxy.
          Soit disant que les admins ont pas accès (croix de bois, croix de fer, …) et que c'est dis dans la charte, que je n'ai jamais eu entre les mains en tant que presta.
          Bref, ça doit être très limite, mais je pouvais pas trop faire de vague et comme je ne me suis pas faire prendre au piège, j'ai laissé courir.

      • [^] # Re: Serveur Proxy

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

        Cela n'était détectable que dans un navigateur vanillia, genre portable FF.

        À mon avis, c'était aussi détectable en vérifiant l'autorité de certification, dans ce genre de cas, les entreprises s'amusent rarement à usurper le nom d'une autre.

        « 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: Serveur Proxy

          Posté par . Évalué à 2.

          Non, effectivement. Et en plus, ca ne met pas une partie de la barre en vert pour les gros sites qui se sont payés de l'EV machin.

  • # Un classement suivant l’autorité de certification

    Posté par . Évalué à 5.

    Je suis dubitatif sur ce nouveau critère de Google. On pourrait imaginer par le suite que Google améliore le page rank des sites qui ont un certificat de telle ou telle autorité et pas d'une autre, ou de ceux qui paient cher leur certificat (au plutôt l'assurance associée) et pas les autres.

    Ce qui me gène c'est qu'il y pourrait y avoir une discrimination sur l'argent que tu mets dans un certificat. Du coup, si tu as un super site avec un certificat autosigné, tu pourrais te retrouver au fin fond du classement (en 2ème page ;-) ).

    Donc mouais.

  • # Sympa...

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

    Avez-vous donc quelques pistes intéressantes pour justifier de conserver un accès HTTP ?

    Laisser le choix au gens plutôt que leur imposer ta vision du monde?
    Sinon, sympa pour les gens qui ont accès qu'au port 80 à cause de proxy nazi.
    Question inverse : avez-vous donc quelques pistes intéressantes pour justifier de ne pas conserver un accès HTTP ? Pour la sécurité, c'est mort, te requète HTTP étant acceptée on peut l'intercepter et rediriger autrement.

    Pourquoi cette manie d'imposer aux autres sa vision en refusant de laisser un choix?
    Il y a 36 solutions pour faire du HTTPS sans imposer (par exemple, la façon dont fait LinuxFr avec un cookie "j'ai déjà été en HTTPS, je souhaite donc de nouveau l'être même si je tape comme un couillon http:// , un petit warning et une offre de passer en HTTPS si HTTP etc…), et quand il y aura moins d'1% d'utilisateurs en HTTP tu pourras te dire que ça ne sert plus…
    en attendant, HTTP ne te fait pas de mal.

    • [^] # Re: Sympa...

      Posté par . Évalué à 3.

      Laisser le choix au gens plutôt que leur imposer ta vision du monde?
      Sinon, sympa pour les gens qui ont accès qu'au port 80 à cause de proxy nazi.

      L'argument se tiendrait si cela avait un impact significatif sur « les gens ».
      En pratique j'ai subis le proxy Websense et de mémoire il laissait tranquille le HTTPS.
      Il y en a beaucoup des proxy qui filtrent sans discrimination l'HTTPS ?

      C'est une question de compromis : combien de personnes je perds à cause de ces proxy nazi et combien de temps je passe à maintenir 2 accès.

      J'ai eu le même genre de question lorsque j'ai dû choisir mon hébergement : certains hébergeurs sont bloqués par certains proxy (kimsufi par exemple) mais par contre ils ne sont pas chers.

      Si personne n'a de statistiques pertinentes sur le sujet, je suppose que je peux réaliser moi-même l'expérience et voir dans mes logs combien d'accès HTTP ne sont pas suivis par un accès HTTPS.

      Question inverse : avez-vous donc quelques pistes intéressantes pour justifier de ne pas conserver un accès HTTP ?

      Ben oui : cela m'évite des efforts pour installer/maintenir.
      Pour le moment, je considère que j'y gagne plus (i.e. moins de temps à installer/maintenir) et que j'y perds pas grand chose (les gens qui subissent les proxy nazi).

      Le but de ce journal c'est justement de voir si quelqu'un a des données factuelles pour remettre en question mon raisonnement.
      Si tu as des sources qui donnent des chiffres à propos de ces proxy nazi, cela m'intéresse beaucoup.
      Sinon je verrai par moi-même.

      Pour la sécurité, c'est mort, te requète HTTP étant acceptée on peut l'intercepter et rediriger autrement.

      Je ne comprends pas : rediriger vers où ?
      Tu veux dire que http://example.com peut être redirigé vers https://example.com.piratage ?
      Si oui je ne vois pas en quoi c'est différent de rediriger https://example.com vers https://example.com.piratage

      Pourquoi cette manie d'imposer aux autres sa vision en refusant de laisser un choix?

      Parce que tout est affaire de compromis ?
      Je suis justement à la recherche de bons arguments pour réaliser le meilleur compromis.
      Ton argument avec celui plus haut que l'HTTPS n'est pas compatible avec certaines publicités sont les seuls qui répondent vraiment à la question du journal. Par contre c'est relativement vague (pas de données chiffrées) et donc ne fait pas trop pencher la balance.
      Je vais rechercher par curiosité si on ne trouve pas des chiffres sur tes proxy nazi.

      • [^] # Re: Sympa...

        Posté par . Évalué à 1.

        Et un lien rigolo et relatif au sujet :
        Cochons dansants

      • [^] # Re: Sympa...

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

        combien de temps je passe à maintenir 2 accès.

        Par curiosité (bon, OK : pour rigoler), chiffre ce temps.
        D'ailleurs, dans ton journal, tu dis que tu continues à maintenir HTTP quand même (redirection, mais quand même présent).

        combien de personnes je perds à cause (…)

        Perso, je m'en fout un peu de ça à partir du moment où ça me coûte pas grand chose à maintenir : question de respect du visiteur sans lui imposer mes choix "pour son bien".

        • [^] # Re: Sympa...

          Posté par . Évalué à -1. Dernière modification le 08/08/14 à 17:08.

          combien de temps je passe à maintenir 2 accès.

          Par curiosité (bon, OK : pour rigoler), chiffre ce temps.

          J'ai mis grosso-modo 20-30h au doigt mouillé pour configurer l'HTTPS en partant de zéro (c'est mon premier site web, soyez indulgent).
          Ajouter l'accès HTTP en parallèle me prendrait je pense la moitié du temps.

          Mais c'est surtout la perte de la simplicité de mon site dont j'ai peur. Et il sera plus dur à administrer.

          D'ailleurs, dans ton journal, tu dis que tu continues à maintenir HTTP quand même (redirection, mais quand même présent).

          La maintenance de l'accès HTTP c'est un peu plus qu'une simple redirection dans mon cas.
          Par exemple j'ai un proxy cache comme Varnish et il faudrait que je modifie la ré-écriture des en-têtes proprement (actuellement fait dans Varnish) et que je voie comment le backend doit gérer les cookies (j'ai activé l'option "cookie via HTTPS seulement" car c'était plus simple).

          Je ne dis pas que ce ne serait pas plus facile pour toi ou pour des administrateurs expérimentés. Mais bon comme c'est mon premier site web je suis allé au plus simple.

          combien de personnes je perds à cause (…)

          Perso, je m'en fout un peu de ça à partir du moment où ça me coûte pas grand chose à maintenir : question de respect du visiteur sans lui imposer mes choix "pour son bien".

          Tu vois bien que tu fais ce compromis toi aussi « à partir du moment où ça me coûte pas grand chose à maintenir ».
          Dans mon cas, je dois être moins expérimenté donc cela me coûte beaucoup.

          • [^] # Re: Sympa...

            Posté par (page perso) . Évalué à -3. Dernière modification le 08/08/14 à 17:23.

            (c'est mon premier site web, soyez indulgent).
            (…)
            Par exemple j'ai un proxy cache comme Varnish

            Euh…

            Ajouter l'accès HTTP en parallèle me prendrait je pense la moitié du temps.

            Euh… (bis)

    • [^] # Re: Sympa...

      Posté par . Évalué à 9.

      Sinon, sympa pour les gens qui ont accès qu'au port 80 à cause de proxy nazi.

      S'ils n'ont pas accès à Internet, c'est la faute au proxy, pas aux fournisseurs de services qui tournent ailleurs que sur le port 80.

  • # IPv6

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

    J'espère qu'il compte aussi l'accès via IPv6 pour leur ranking…

    (Je dis ça car mon site est accessible via IPv6, mais pas via HTTPS :-) )

  • # et dans tous ces commentaires

    Posté par . Évalué à -7.

    à aucun moment personne ne s'offusque de ce monde de merde où il faut protéger jusqu'à son site web perso pour être visible.

    bran****tte intellectuelle du vendredi soir ? Expliquez moi …

Suivre le flux des commentaires

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