Tous les navigateurs devraient-ils implémenter le protocole HSTS ?

[Katleen Erna]

Tous les navigateurs devraient-ils implémenter le protocole HSTS ? Le mécanisme sécuritaire est en voie de standardisation

Le protocole HSTS (HTTP Strict Transport Security), qui permet de renforcer le sécurité en ligne, n'est pas encore utilisé en masse.

Pourtant, ce mécanisme permettrait de renforcer la sécurité des sites visités, et des comptes qui y sont associés. Notamment, dans le cas de réseaux Wi-Fi non fiables ou de connexions manquant de cryptage.

Actuellement, le protocole est en cours de standardisation par le IETF (Internet Engineering Task Force) et deux navigateurs très populaires le prennent déjà en charge :

Il s'agit de Chrome, et de FireFox (actuellement dans les plug-in NoScript et Force-TLS, avant d'être implémenté dans la prochaine version du logiciel lui-même).

Lorsqu'un site Web qui l'a implémenté sera visité, il fera en sorte que le navigateur se connecte toujours par défaut et automatiquement à la version sécurisée de la page via une URL en "https".

De plus, certains sites contenant des infos sensibles utilisent le protocole, comme PayPal. Et encore plus suivront certainement, surtout lorsque Microsoft aura implémenté le HSTS. Mais ce mouvement n'est pour l'instant pas prévu dans Internet Explorer 9.

Pensez-vous que tous les navigateurs devraient implémenter ce protocole ?

[Neko]

Et donc c'est quoi la différence avec une redirection auto sur la page https comme beaucoup de sites utilisent déjà ?

[Ev3r10st]

Y'en a pas.

Rediriger automatiquement (via le browser) tout le http vers https, pourquoi pas.
Pour les attaques MITM.

Mais encore une fois, on met la sécurité côté client.

Seulement c'est à double tranchant, les développeurs d'appli web vont être encore plus confiants, et laisser d'énormes failles dans leurs sites.

C'est les développeurs qu'il faut sensibiliser.

[Flaburgan]

Cela rendrait-il le réseau réellement plus lent si TOUS les sites étaient en HTTPS ?

[Joker-eph]

Le réseau serait toujours aussi "rapide", il ne transporte que des octets sans discrimination (pour l'instant) ;-)

Le problème c'est plutôt les ressources serveurs pour initier une session https et ensuite encrypter le trafic.

[Flaburgan]

Oui ce que j'entendais par rapide était le temps de réponse entre le moment où je clique sur un lien et où la page s'affiche, rajouter les actions encrypter et décrypter à la fin ralentisse forcément, et peut être que les données cryptées tiennent du coup sur plus d'octets... Bref, cette variation de temps est-elle visible ? (Delta t est-il négligeable :p ?)

[valkirys]

Non, si un site est bien codé avec des règles de mise en cache (du navigateur) bien faites, le surcout devrait être négligeable (pas vraiment visible lors du chargement de la page) a priori il y a de la marge au niveau d'un serveur qui devrait pouvoir crypter (il zip déjà les données et ça ne se voit pas) sans se mettre à ramer.
Après si un site envoie trop de donner, est mal codé le temps d'exécution va augmenter avec un cryptage ce qui ne va rien arranger.
Pour la taille des données, vu la taille des images de nos jours on n'en est plus à quelques centaines d'octet près, le cache (navigateur) joue un rôle important avec ou sans https dans ce cas.

[cassis2k]

Je suis de l'avis d'Ev3r10st. C'est au serveur de gérer cette fonction !