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.

Aller plus loin

  • # 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

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

    • [^] # 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.

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

          • [^] # 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.

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

          • [^] # 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

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

        Post√© par . √Čvalu√© √† 1.

        Le seul moyen serait de sécuriser HTTP. HSTS ne protège pas les nouveaux venus il me semble...

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

        Post√© par . √Čvalu√© √† -1.

        Le seul moyen serait de sécuriser HTTP. HSTS ne protège pas les nouveaux venus il me semble...

  • # 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.