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=31536000La 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
- Le brouillon de norme (115 clics)
- DLFP : HSTS arrive dans Firefox 4 (194 clics)
# NoScript
Posté par DLFP est mort . É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 Fabimaru (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 Mouns (site web personnel) . É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 Mouns (site web personnel) . É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 :
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 🚲 Tanguy Ortolo (site web personnel) . É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 Mouns (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
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…
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 Mouns (site web personnel) . É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 barmic . É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 rpnpif . É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 Bruno Michel (site web personnel) . É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 barmic . É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.
Ç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.
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.
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 rpnpif . Évalué à 0.
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 barmic . É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 geb . Évalué à 3.
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 rpnpif . É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 Bruno Michel (site web personnel) . É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 Framasky (site web personnel) . É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 ?
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Et la fermeture du port 80 ?
Posté par claudex . É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 Larry Cow . É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 feth . É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 claudex . Évalué à 3.
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 🚲 Tanguy Ortolo (site web personnel) . É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 Christophe Turbout . É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 bilboa . É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 tyoup . É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 tyoup . É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 oinkoink_daotter . Évalué à 0.
C'est fou que ce soit à la technique de s'adapter à l'utilisateur et non l'inverse ...
[^] # Re: Un problème d'interface chaise-clavier ?
Posté par Philippe F (site web personnel) . Évalué à 6.
C'est vrai ça, pourquoi on tape pas nos requêtes http à la main plutôt que de passer par un navigateur qui les génère ? Il serait quand même temps que les utilisateurs s'adaptent un peu à la technique !
[^] # Re: Un problème d'interface chaise-clavier ?
Posté par oinkoink_daotter . Évalué à 1.
telnet sur le porc 80 FTW !
[^] # Re: Un problème d'interface chaise-clavier ?
Posté par tyoup . Évalué à 1.
netcat ? ---->[]
[^] # Re: Un problème d'interface chaise-clavier ?
Posté par Bob . Évalué à 3.
Intéressant comme concept !
$ telnet charcuterie 80GET /jambon.html[^] # Re: Un problème d'interface chaise-clavier ?
Posté par Juke (site web personnel) . Évalué à 5.
c'est grouik comme solution
# Mauvaise réponse à un vrai problème ?
Posté par Kerro . É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 claudex . Évalué à 6.
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.
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 Mouns (site web personnel) . É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 oinkoink_daotter . É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 claudex . Évalué à 3.
C'est le problème.
Ç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 oinkoink_daotter . Évalué à 1.
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 claudex . Évalué à 2.
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.
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 oinkoink_daotter . É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 claudex . Évalué à 2.
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 LupusMic (site web personnel, Mastodon) . É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 bilboa . É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 oinkoink_daotter . Évalué à 0.
Pis je vois pas comment ça peut marcher avec les proxy http tres chers à nos entreprises.
[^] # Re: Un truc que je ne comprends pas ...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Ça dépendra de ce que fait le proxy.
[^] # Re: Un truc que je ne comprends pas ...
Posté par oinkoink_daotter . Évalué à 0.
Justement, non. Dans le cas du post que je cite (dns), ça ne marche pas. C'est le proxy qui va faire la résolution dns, voir qu'il faut aller chercher du https à la place du http demandé par le client et non le brouteur de l'utilisateur final.
[^] # Re: Un truc que je ne comprends pas ...
Posté par bilboa . Évalué à 0.
ben ca reste compat, si tu choppe pas le bon message dns parce-que t'y a pas accès ben pas de sécurité
enfin bref, au final tout ca ca reste du patchwork
[^] # Re: Un truc que je ne comprends pas ...
Posté par lululaglue (site web personnel) . Évalué à 0.
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.
[^] # Re: Un truc que je ne comprends pas ...
Posté par Larry Cow . Évalué à 3.
Ou passer à SNI, qui permet du VirtualHosting basé sur les noms même en SSL.
[^] # Re: Un truc que je ne comprends pas ...
Posté par lululaglue (site web personnel) . Évalué à 1.
SNI c'est bien sur le principe, mais je me vois pas dire à mes clients qu'ils vont perdre tous leurs visiteurs utilisant encore IE+winXP parce que j'ai voulu économiser des adresses IP.
# HSTS c'est facile a implémenter
Posté par bilboa . É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:
/**
* @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 geb . Évalué à 4.
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 Victor STINNER (site web personnel) . É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 Misc (site web personnel) . É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 Aurélien Jarno (site web personnel) . É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.
[^] # Re: Et Google ?
Posté par Michaël (site web personnel) . Évalué à 1.
Moi je tape linuxfr.org dans le champ recherche de Google.
# Un peu fou ?
Posté par tyoup . É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 Bruno Michel (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.