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 (142 clics)
- DLFP : HSTS arrive dans Firefox 4 (208 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 . Ă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 . Ă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 . Ă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 . Ă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 . Ă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 . Ă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 . Ă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.