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
# le seul soucis de HSTS ...
Posté par Mouns . En réponse à la dépêche HTTP Strict Transport Security. É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