HTTP Strict Transport Security

Posté par (page perso) . Modéré par Lucas Bonnet. Licence CC by-sa
47
26
avr.
2011
Internet

HTTP Strict Transport Security, ou HSTS, est un brouillon de norme Internet qui propose une méthode pour augmenter la sécurité des sites web en apportant une solution à une faille courante située entre la chaise et le clavier.

Il s'agit pour les sites web sécurisés d'indiquer au navigateur qu'il doit systématiquement forcer l'accès en HTTPS.

Scénario

La meilleure façon de décrire HSTS est de présenter le scénario qu'il permet d'améliorer.

Un site web sécurisé

Responsable d'un service de courrier électronique, vous avez mis un webmail à disposition de vos utilisateur. Puisqu'ils sont amenés à y taper leur mot de passe, vous avez sécurisé l'accès à ce site avec HTTPS.

Un problème d'interface chaise-clavier

L'ennui, c'est que vos utilisateurs sont fainéants : dans la barre d'adresse de leur navigateur web, ils ne tapent pas « https://webmail.example.com/ » mais simplement « webmail.example.com ». Le comble, c'est qu'ils s'attendent à ce que cela fonctionne ainsi !

Une mauvaise solution

Pour servir vos utilisateurs, vous avez donc mis en place un site web non sécurisé répondant à l'adresse « http://webmail.example.com/ », qui redirige immédiatement sur le site sécurisé « https://webmail.example.com/ ».

C'est cette solution qui introduit une faille. Vos utilisateurs ont maintenant l'habitude de se connecter sur « webmail.example.com » sans réfléchir : ils tombent alors sur le site non sécurisé, qui redirige normalement sur le site sécurisé. Si tout va bien, l'accès à votre webmail est donc sécurisé.

Mais un pirate peut maintenant s'introduire entre un utilisateur et votre webmail : en supprimant la redirection vers le site sécurisé, il peut forcer l'utilisateur à rester sur un site non sécurisé, et lire toutes les données qu'il envoie. Habitué à ne pas saisir l'indicateur de protocole « https », il y a de bonnes chances que votre utilisateur ne s'en rende pas compte.

La solution HSTS

Avec HSTS, lorsqu'un utilisateur se connecte pour la première fois à votre site web sécurisé « https://webmail.example.com/ », votre serveur web lui indique que ce site est sécurisé et doit le rester. Le navigateur réagit en enregistrant cette information : par la suite, il n'accèdera plus jamais au site web non sécurisé, même si on lui demande, mais utilisera le site web sécurisé à la place.

En somme, puisqu'on ne peut pas se fier à l'utilisateur pour accéder volontairement au site web sécurisé, on demande au navigateur de le faire.

Mise en œuvre

Principe

En pratique, HSTS est un en-tête HTTP spécialisé :

Strict-Transport-Security: max-age=31536000

La variable max-age indique le temps, en secondes, pendant lequel cette « politique HSTS » doit être conservée par le navigateur. Après cette durée, ici un an, le navigateur considérera à nouveau ce site web comme normal — sauf qu'en réalité, à moins que le webmestre n'ait décidé de l'enlever, le navigateur aura entre-temps reçu de nouveau cet en-tête.

Serveur web

Du côté du serveur, il s'agit donc d'ajouter un en-tête particulier dans la réponse HTTP. Par exemple, avec Apache Web Server, cela se fait en ajoutant les lignes suivantes dans la définition de votre site sécurisé :

Header set Strict-Transport-Security "max-age=31536000"

La directive équivalent pour Nginx n'est guère plus compliquée :

add_header Strict-Transport-Security "max-age=31536000";

Navigateur

Du côté du client, il faut que le navigateur web prenne en charge HSTS. Aujourd'hui, les navigateurs suivants le prennent en charge :

  • Google Chrome/Chromium 4.0.211.0 ;
  • Firefox 4.0.
  • # NoScript

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

    Ça fait un moment que NoScript (pour Firefox, versions 3 et 4) supporte le HSTS, et on peut aussi ajouter des sites manuellement.

    DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Internet Explorer

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

    Apparemment, IE9 ne le supporte pas. Donc les développeurs/admins web devront toujours utiliser la technique de la redirection pour palier (un peu) ce manque...

    • [^] # Re: Internet Explorer

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

      HSTS ne dispense pas de la redirection !

      Avec HSTS, on redirige une fois, et les suivantes le navigateur le fait systématiquement de lui-même, sans même aller consulter le site non sécurisé.

    • [^] # Re: Internet Explorer

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

      HSTS n'est actif que si la connexion est déjà en HTTPS.
      dit autrement, envoyer les en-tetes HSTS sur un lien HTTP n'aura aucun impact puisque le navigateur ne les regardera même pas.

      il faut donc toujours avoir une regle dans le vhost HTTP du genre :
      RewriteRule ^/(.*)$ https://example.com/$1 [L,R=301]

  • # le seul soucis de HSTS ...

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

    j'ai vite adhéré à HSTS dans un projet récent que j'ai eu à mener.

    mais en cours de développement, nous avons rencontré un problème ennuyeux :

    soumettre un formulaire de retour en POST vers un site en HTTP.
    

    et oui, c'est con mais diverses normes, specs, protocoles etc, demandent ( à coup de SHOULD ) à transmettre plein d'info via des methodes POST au travers de l'UI de l'utilisateur.

    quand l'appli doit renvoyer vers un site sans https , elle produit un formulaire depuis l'appli HTTPS qui va être POSTé vers un site en HTTP, ce qui donne l'affichage dans le navigateur d'une superbe popup flippante du genre " valider ce formulaire provoquera une transmission non sécurisée, ton cancer, ta faillite et le départ de ton etre aimé " .

    Je vous propose d'ignorer l'hypocrisie du navigateur à valider sans sourciller et en silence les formulaire GET HTTPS -> HTTP puisque GET est limité au niveau de la longueur de l'URL.

    toujours est il que :
    - HSTS palie localement à un réel probleme sans considérer la "big picture" qui est qu'aujourd'hui on a les OpenID, les OAuth 3-legged & consort qui font causer les différents sites entre eux, et que les navigateurs conservent encore les legs de Netscape & co qui sortaient des alertes au moindre formulaire,
    - si tu veux retirer un site de la liste HSTS interne au navigateur, tu ne peux pas le faire aisément ( genre quand il a fallu faire machine arrière avec HSTS )

    en résumé :
    - HSTS est très bien pour les sites qui fonctionnent en autarcie ou qui n'accepte de collaborer qu'avec des sites proposant HTTPS.
    - par contre, si ton site HSTS propose de te connecter aux providers perso OpenID et non aux usines Google & co, tu risques d'etre confronté à la popup de la mort qui effraiera certainement le pere, la mere et la fratrie du gentil geek qui a monté son provider OpenID sur en http://geek-michu.free.fr/ et qui leur a vanté les mérites de gerer soit meme son identité numérique plutot que de la vendre aux facebook & co

    Monde de merde

    • [^] # Re: le seul soucis de HSTS ...

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

      Bah, je ne vois pas ce que ça change avec HTTPS sans HSTS : l'utilisateur est averti qu'il va envoyer des données à des boulets infoutus de sécuriser leur site, c'est tout…

      • [^] # Re: le seul soucis de HSTS ...

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

        rien si ce n'est que sans HSTS tu peux palier à ce cas de figure en utilisant au choix une page HTTP ou HTTPS pour produire le formulaire de renvoie.

        mon probleme est qu'avec HSTS, l'appli ne peut plus produire EXCEPTIONNELLEMENT des pages HTTP pour gérer un cas comme celui ci.

        • [^] # Re: le seul soucis de HSTS ...

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

          rien si ce n'est que sans HSTS tu peux palier à ce cas de figure en utilisant au choix une page HTTP ou HTTPS pour produire le formulaire de renvoie.

          Super. Pour éviter au client un message d'avertissement tout à fait légitime, non seulement on envoie les données sans les sécuriser — ça, on n'a pas le choix, c'est imposé par les boulets d'en face — mais en plus on retire la sécurisation de son propre site…

          mon probleme est qu'avec HSTS, l'appli ne peut plus produire EXCEPTIONNELLEMENT des pages HTTP pour gérer un cas comme celui ci.

          Ah, mais ce n'est pas un problème, ça, c'est le principe même d'HSTS : c'est fait pour indiquer que ton site doit toujours être sécurisé, sans exceptions. Si tu veux que parfois, il ne le soit pas, eh bien HSTS n'est pas du tout fait pour toi, c'est tout.

          « Parfois sécurisé, parfois non », c'est la situation sans HSTS, c'est ça qu'il te faut.

          • [^] # Re: le seul soucis de HSTS ...

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

            j'avais souligné ceci :
            _ Je vous propose d'ignorer l'hypocrisie du navigateur à valider sans sourciller et en silence les formulaire GET HTTPS -> HTTP puisque GET est limité au niveau de la longueur de l'URL._

            donc, je clarifie mon propos :
            - soit ces boulets ( je reprends ton terme ) de devs de navigateurs, collent la meme alerte quand on fait un GET avec parametres HTTPS -> HTTP .
            - soit ces boulets ( je reprends ton terme ) de devs de navigateurs, trouvent une solution pour ce cas de figure avant de distribuer HSTS n'importe ou.

            parce qu'une maniere de contourner le probleme est ... un GET avec parametres :p

            Tout comme un formulaire POST n'est pas uniquement pour transmettre une CB ou son caryotype, on peut transmettre des informations critiques avec une méthode GET.

            concernant ce qu'il me faut, je te rassure, j'avais trouvé la réponse sans toi, si tu relis mon propos, j'ai écrit :
            HSTS est très bien pour les sites qui fonctionnent en autarcie ou qui n'accepte de collaborer qu'avec des sites proposant HTTPS

            donc, je ne dis pas que HSTS est mal, je dis juste qu'il répond à un besoin précis mais qu'à partir du moment où l'on se retrouve à utiliser des protocoles faisant intervenir le browser, et si l'on ne restreint pas volontairement le périmètre uniquement aux sites proposant uniquement HTTPS, alors, il y a un probleme avec une hypocrisie dans le navigateur qui peut nuire au déploiement massif de HSTS.

            Si j'étais méchante, je te rappellerai qu'il est meme possible de passer des informations en GET et sans parametre.

            ben quoi ? c'est le GET ou le POST qui permette de déterminer si l'information est critique ou non ?
            ce n'est pas un peu synonyme de " si tu fais du P2P , c'est que tu télécharge illégalement " ?

            je vais me répéter :
            HSTS palie localement à un réel probleme sans considérer la "big picture" qui est qu'aujourd'hui on a les OpenID, les OAuth 3-legged & consort qui font causer les différents sites entre eux, et que les navigateurs conservent encore les legs de Netscape & co qui sortaient des alertes au moindre formulaire

  • # Entrée dans le suivi

    Posté par . Évalué à 4.

    Je viens d'ajouter une entrée dans le suivi de linuxfr (j'ai pas trouvé de précédente entrée) donc si vous voulais voter :
    https://linuxfr.org/suivi/support-de-hsts

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

    • [^] # Re: Entrée dans le suivi

      Posté par . Évalué à 3.

      Euh, il faudrait d'abord que https://linuxfr.org/ délivre des certificats valides, ou au moins connus de Firefox and co. Non ?

      • [^] # Re: Entrée dans le suivi

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

        Le certificat de LinuxFr.org est valide mais il a été signé par une autorité, CaCert, qui n'est effectivement pas reconnue par Firefox & co. Du coup, HSTS n'est effectivement pas une option pour LinuxFr.org. Cf http://linuxfr.org/suivi/support-de-hsts#comment-1227989

        • [^] # Re: Entrée dans le suivi

          Posté par . Évalué à 6.

          Merci pour ta réponse dans le suivi. J'y répond ici parce que je pense que c'est plus sa place.

          D'une part, nous ne voulons pas forcer tous nos utilisateurs à passer en HTTPS [...]

          Ça n'oblige rien le HSTS (d'après ce que j'ai compris). Ca oblige ceux qui on déjà accédé à linuxfr en https à continuer à le faire. Je ne pense pas que ce soit contraignant.

          Nous utilisons un certificat CaCert, qui n'est pas reconnu par défaut par la plupart des navigateurs. Avec HSTS, quand un navigateur voit un certificat qui ne lui semble pas valide, il affiche une page blanche au lieu de la page d'avertissement qui permet d'ajouter le certificat !

          Je comprends bien le problème, mais je trouve ça débile. Je ne vois pas pourquoi Firefox a un comportement différent, si à la première connexion je valide le certificat, il n'y a plus à me poser la question ou à rechigner de l'accepter. Je ne comprends vraiment pas où ils veulent en venir comme ça.

          À la place, nous utilisons une technique à base de cookies. Quand quelqu'un se connecte depuis la version HTTPS du site, ses cookies sont en mode secure. Cela veut dire qu'ils ne sont envoyés que quand on se connecte en HTTPS, pas en HTTP. Un autre cookie https, pas _secure celui-là, est également ajouté. Quand ce cookie est présent et que l'utilisateur demande une page en HTTP, il est automatiquement redirigé vers la page équivalent en HTTPS.

          Ok je vois à peut prêt l'astuce. Merci pour l'explication.

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

          • [^] # Re: Entrée dans le suivi

            Posté par . Évalué à 0.

            Je comprends bien le problème, mais je trouve ça débile. Je ne vois pas pourquoi Firefox a un comportement différent, si à la première connexion je valide le certificat, il n'y a plus à me poser la question ou à rechigner de l'accepter. Je ne comprends vraiment pas où ils veulent en venir comme ça.

            Je ne comprends pas ta remarque. En mode navigation non privé, Firefox mémorise bien l'acceptation du certificat inconnu et ne le redemande plus. Il n'est pas différent des autres (en HTTPS) :?

            • [^] # Re: Entrée dans le suivi

              Posté par . Évalué à 5.

              D'après ce que dis Bruno Michel, avec HSTS tu ne peux pas valider un certificat qui ne viens pas d'une autorité reconnu.

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

          • [^] # Re: Entrée dans le suivi

            Posté par . Évalué à 3.

            Je comprends bien le problème, mais je trouve ça débile. Je ne vois pas pourquoi Firefox a un comportement différent, si à la première connexion je valide le certificat, il n'y a plus à me poser la question ou à rechigner de l'accepter. Je ne comprends vraiment pas où ils veulent en venir comme ça.

            Je pense qu'il voulait juste dire que par défaut firefox ne reconnait pas cacert comme authorité de certification. À la demande des gens de ce cacert de mémoire ( https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 ).

  • # Et la fermeture du port 80 ?

    Posté par . Évalué à 1.

    J'ai une question qui est peut-être bête.
    Et si on ferme le port 80 pour ne laisser que le 443 d'HTTPS ouvert, quel problème cela pose ? Quel est l'avantage de l'HSTS sur cette méthode ?

    • [^] # Re: Et la fermeture du port 80 ?

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

      Dans ce cas, les utilisateurs viennent se plaindre que le site ne marche pas. Après, si tu as le temps pour leur expliquer le pourquoi du comment, tant mieux, ça fera des utilisateurs avertis en plus.

      • [^] # Re: Et la fermeture du port 80 ?

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

        Simple avec apache :
        <VirtualHost *:80>
        ServerName webmail.com
        Redirect 301 https://webmail.com
        </VirtualHost>
        <VirtualHost *:443>
        ServerName webmail.com
        </VirtualHost>

        Le non-sécurisé n'est pas accessible et renvoie direct vers le sécurisé. C'est pas plus simple qu'une norme ?

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

        • [^] # Re: Et la fermeture du port 80 ?

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

          Et le jour où tu fais fasse à une attaque MiM, cette règle n'existe plus et les gens se connectent en HTTP sur un truc complètement vérolé sans le savoir.

          « 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: Et la fermeture du port 80 ?

          Posté par . Évalué à 4.

          C'est précisément ce à quoi HSTS répond, si j'ai tout suivi. Avec ta technique, le navigateur se connecte en non-sécurisé, et se voit répondre - par ce biais non-sécurisé - que la vraie ressource est à l'adresse suivante et sécurisée.

          Le problème, c'est que - ton flux initial étant non-sécurisé - quelqu'un peut faire du MITM dessus. Et, au lieu de balancer le 301 vers la version sécurisée, faire un 301 vers un serveur tiers en HTTP (ou avec un certificat valide) qui se chargera de se faire passer pour le serveur HTTPS originel.

          HSTS permet d'éviter cette étape (sauf pour la première connexion), et de faire en sorte que le navigateur aille de lui-même taper sur la ressource HTTPS sans prendre le risque de demander les coordonnées de ce dernier à chaque fois sur un canal non-fiable.

          • [^] # Re: Et la fermeture du port 80 ?

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

            Si les utilisateurs ne regardent pas l'url qu'ils visitent, facile en cas de MiM de rediriger vers un site sécurisé dont on possède le certificat.

            On peut faire des choses pour rendre la vérification plus facile, mais au bout d'un moment on ne peut pas se substituer à un minimum de vigilance de la part des utilisateurs finauds ou non.

            • [^] # Re: Et la fermeture du port 80 ?

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

              Si les utilisateurs ne regardent pas l'url qu'ils visitent, facile en cas de MiM de rediriger vers un site sécurisé dont on possède le certificat.

              Non, parce que le navigateur n'acceptera pas de se connecter en HTTP sur le site (après la première fois).

              « 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: Et la fermeture du port 80 ?

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

          Un pirate se branche sur la ligne d'un de tes clients, se connecte sur ton site sécurisé, et renvoie le tout en clair au client, sans la redirection vers le site sécurisé.

          Cette redirection n'est pas une mesure de sécurité efficace puisqu'elle n'est présente que si la liaison n'est pas attaquée.

      • [^] # Re: Et la fermeture du port 80 ?

        Posté par . Évalué à 1.

        Entre expliquer aux utilisateurs les raisons d'utiliser https et la mise en
        place de bric et de broc, le choix est vite fait !

        Là sous prétexte d'éviter à l'utilisateur de lui apprendre la bonne utilisation
        du web, on met en place une technique qui devient une faille de sécurité et
        on propose en réponse un protocole qui presque règler le problème ...

        Eduquons les gens, plutôt que d'inventer des pseudos solutions.

        c'est à force de mettre en place ce genre de solutions qu'on l'habitue à faire
        n'importe quoi ... et après on vient s'en plaindre ...

        c'est le pompier pyromane la !

    • [^] # Re: Et la fermeture du port 80 ?

      Posté par . Évalué à -1.

      Reponse simple et claire: Non, ca change rien.
      Le seul moyen est en fait HSTS

  • # Un problème d'interface chaise-clavier ?

    Posté par . Évalué à 0.

    L'ennui, c'est que vos utilisateurs sont fainéants : dans la barre d'adresse de leur navigateur web, ils ne tapent pas « https://webmail.example.com/ » mais simplement « webmail.example.com ». Le comble, c'est qu'ils s'attendent à ce que cela fonctionne ainsi !

    C'est fou que ce soit à la technique de s'adapter à l'utilisateur et non l'inverse ...

  • # Mauvaise réponse à un vrai problème ?

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

    On dira ce qu'on veut à propos de l'utilisateur (il est nul, il ne vérifie pas 100% de ce qu'il a devant les yeux), mais ne jamais se tromper est impossible. Donc "aider" l'utilisateur à ne pas se tromper est une bonne chose.

    Cependant je trouve que le procédé décrit ici est problématique: il faut que le navigateur le prenne en charge. Il faut se connecter une première fois au site. Et il faut que le navigateur enregistre quelque chose.
    Ca fait trois conditions. La première est inévitable, ok. Les deux autres sont des contraintes, des sources de problèmes, et des failles potentielles.
    Exemples: j'utilise un autre ordinateur. Je suis dans un cyber café. J'ai un live-cd. Etc.

    Pourquoi ne pas utiliser un champ dns ?
    Il faut également un navigateur adapté, ça ne change pas.
    Pas besoin d'effectuer une première connexion.
    Pas besoin de stocker l'information.
    Est-ce plus vulnérable que la page non sécurisée lors de la première connexion ?

    • [^] # Re: Mauvaise réponse à un vrai problème ?

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

      Pourquoi ne pas utiliser un champ dns ?

      Je ne suis pas sûr mais je pense que beaucoup plus de gens maîtrise les headers envoyés aux clients que leurs champ DNS. C'est donc un moyen de répandre plus facilement la technique.

      Pas besoin de stocker l'information.

      Si, sinon tu ne résoud pas du tout l'attaque de l'homme du milieu.

      « 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: Mauvaise réponse à un vrai problème ?

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

      en gros tu aimerais que le attributs SRV soit exploité pour les requetes HTTP et HTTPS ?

      oui, cela serait peut etre le possible debut d'une forme de solution ...

      ... sauf que, ce n'est pas demain la veille que cela sera fait.

  • # Un truc que je ne comprends pas ...

    Posté par . Évalué à 1.

    HSTS ne permet pas de lutter contre un proxy transparent qui supprimerait la redirection vers le site sécurisé dans le cas où l'on a jamais accédé au site sécurisé avant (le navigateur n'ayant jamais vu le tag) ?

    Idée en l'air : ne serait-il pas plus simple d'essayer par défaut une connexion https avant de faire la connexion http ?

    • [^] # Re: Un truc que je ne comprends pas ...

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

      HSTS ne permet pas de lutter contre un proxy transparent qui supprimerait la redirection vers le site sécurisé dans le cas où l'on a jamais accédé au site sécurisé avant (le navigateur n'ayant jamais vu le tag) ?

      C'est le problème.

      Idée en l'air : ne serait-il pas plus simple d'essayer par défaut une connexion https avant de faire la connexion http ?

      Ça veut dire allonger le temps de connexion de 30 secondes pour tous les sites qui ne gèrent pas HTTPS, l'utilisateur va vite changer de navigateur.

      « 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: Un truc que je ne comprends pas ...

        Posté par . Évalué à 1.

        Ça veut dire allonger le temps de connexion de 30 secondes pour tous les sites qui ne gèrent pas HTTPS, l'utilisateur va vite changer de navigateur.

        Ah non ! S'il y a "connection refused", tu ne mettras pas 30s à le savoir. Cela dit ça ne gene "personne" quand firefox/chrome/whatever essaye d'abord en IPv6 puis en v4.

        • [^] # Re: Un truc que je ne comprends pas ...

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

          Ah non ! S'il y a "connection refused", tu ne mettras pas 30s à le savoir.

          C'était une exagération, mais même si c'est pour 10% des sites, les navigateurs perdraient beaucoup à le faire. Sans compter qu'on arrive pas forcément au même site. De plus, cela va effrayer l'utilisateur s'il tombe sur un certificat qui n'est pas signé par une autorité reconnue par le navigateur.

          Cela dit ça ne gene "personne" quand firefox/chrome/whatever essaye d'abord en IPv6 puis en v4.

          Sans doute parce que l'IPv6 est plutôt inexistant actuellement côté utilisateur final.

          « 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: Un truc que je ne comprends pas ...

            Posté par . Évalué à 0.

            Ben toutes les distrib linux récentes plus vistouille, 7 et macos leo (?) and up . Soit à peu pres tous les PC vendus ces cinq dernieres années. Apres, les "routeurs", faut voir...

            Sinon, à par linux qui est signé par cacert, tu connais beaucoup de sites grand public dont le certificat n'est pas signé par un machin reconnu par les navigateurs ?

            • [^] # Re: Un truc que je ne comprends pas ...

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

              Sinon, à par linux qui est signé par cacert, tu connais beaucoup de sites grand public dont le certificat n'est pas signé par un machin reconnu par les navigateurs ?

              Je ne sais pas, je ne teste pas les version HTTPS quand elle ne sont pas proposé (ce n'est pas pour ça que tu ne tombe par sur une page par défaut avec un certificat pas signé).

              « 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: Un truc que je ne comprends pas ...

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

          Toi tu n'as pas vu les nombreux articles qui disent que IPv6 c'est du caca qui ralenti l'Internet, et qu'il faut le désactiver parce que ça ne sert à rien.

    • [^] # Re: Un truc que je ne comprends pas ...

      Posté par . Évalué à -1.

      Tout à fait. HSTS est une "solution" intermédiaire vu qu'on ne peut pas ré-écrire HTTP.
      C'est mieux que sans, de très très loin mais c'est pas parfait non plus. En general on utilisarais le DNS pour specifier que le site est HTTPS-only en fourrant ca dans un champs à la con style TXT ou un tout neuf (comme SSH ;-) avec sa fingerprint pour faire un "meilleur patch", mais c'est compliqué a implementer pour les admins (pas pour les dévs) donc ca serait très peut utilisé.
      D'ou HSTS en compromis.

    • [^] # Re: Un truc que je ne comprends pas ...

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

      Idée en l'air : ne serait-il pas plus simple d'essayer par défaut une connexion https avant de faire la connexion http ?

      Pour les petits sites, en général il y en a plusieurs d'hebergés par serveur, d'ou l'utilité des vhosts.
      Tester automatiquement en https ça obligerait chaque site à être hebergé sur des ip différentes, ou utiliser des certificats multi-domaine, ce qui est problèmatique si chaque site appartient à un propriétaire différent.

  • # HSTS c'est facile a implémenter

    Posté par . Évalué à 1.

    Malgrès ses petits défaults il y a un gros bonus à HSTS, ca s'implémente en 2 minutes.
    Par exemple pour Wordpress:

    < ?php
    

    /**
    * @package HSTS
    * @version 1.0
    /
    /

    Plugin Name: HSTS - HTTP Strict Transport Security enforcement plugin
    Author: kang@insecure.ws
    Version: 1.0
    Author URI: https://www.insecure.ws
    */

    function hsts_header()
    {
    isset($_SERVER['HTTPS']) && header('Strict-Transport-Security: max-age=15768000; includeSubDomains');
    }

    add_action( 'send_headers', 'hsts_header' );

    ?>

    Source: https://www.insecure.ws/2011/04/13/http-strict-transport-security-hsts-for-wp

  • # C'est bien joli tout ça, mais...

    Posté par . Évalué à 4.

    7.3. Errors in Secure Transport Establishment

    When connecting to a Known HSTS Host, the UA MUST terminate the connection with no user recourse if there are any errors (e.g. certificate errors), whether "warning" or "fatal" or any other error level, with the underlying secure transport.

    Autant ça peut faire sens pour un site ayant un besoin extreme de sécurité (banque etc), autant pour les sites ou c'est juste "bonus" (wikipedia, linuxfr..) , c'est peut être un peu trop strict.

    • [^] # Re: C'est bien joli tout ça, mais...

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

      Le but est de protéger des attaques de l'homme du milieu (MITM). Cet homme (ou femme hein :-)) peut se faire passer pour LinuxFR en montant un proxy HTTPS pour capturer le traffic en clair. Il a juste besoin d'un certificat autosigné. Si ta banque ou LinuxFR a un certificat bien propre, tu vas avoir un vilain message d'erreur HTTPS s'il y a un proxy HTTPS sur le route (qui change le certificat HTTPS).

    • [^] # Re: C'est bien joli tout ça, mais...

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

      Juste bonus, ça dépend de ton voisinage. Si c'est juste bonus que quelqu'un poste sur ton compte linuxfr des horreurs parce qu'il a chopé ton cookie, soit :)

  • # Et Google ?

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

    L'ennui, c'est que vos utilisateurs sont fainéants : dans la barre d'adresse de leur navigateur web, ils ne tapent pas « https://webmail.example.com/ » mais simplement « webmail.example.com ». Le comble, c'est qu'ils s'attendent à ce que cela fonctionne ainsi !

    Enfin ça c'est les utilisateurs un peu avertis. La plupart tapent « webmail example » dans la barre de recherche ou même directement dans Google.

  • # Un peu fou ?

    Posté par . Évalué à 2.

    Imaginons que je sois un méchant hacker un peu fou et que je décide d'attaquer un site web qui n'ait pas de certificat valide. J'ajoute dans une réponse http que j'ai préalablement interceptée un header HSTS avec un max-age énorme pour bien embêter les gens. Le site sera-t-il toujours utilisable ?

    • [^] # Re: Un peu fou ?

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

      Non, le site n'est plus utilisable. Ça revient (en gros) au même que si tu renvoyais une page blanche avec une mise en cache très longue (en fait, c'est plus violent que ça, même avec un refresh, tu gardes la page blanche).

Suivre le flux des commentaires

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