Chrome 68 est disponible, et avec lui un changement de comportement attendu depuis longtemps : les sites n’utilisant pas le HTTPS sont marqués comme « non sécurisés ». Le navigateur de Google est l’un des premiers à effectuer cette bascule, prévue par tous les concurrents.
Depuis longtemps, l’internaute peut identifier un site « sécurisé » par le petit cadenas vert situé à gauche de l’adresse du site. Il symbolise la présence d’une connexion HTTPS, signifiant que les données échangées avec le serveur sont chiffrées.
Ce cadenas (ou bouclier selon les navigateurs) a eu des vertus éducatives et devait inciter l’utilisateur à faire confiance. Une condition bien importante pour faire notamment décoller le commerce en ligne. Mais les choses ont bien changé, notamment sous l’impulsion d’initiatives comme Let’s Encrypt (qui a récemment passé la barre des 100 millions de certificats SSL/TLS, avec les dangers que cela comporte).
Maintenant que le HTTPS est utilisé par une grande majorité de sites, les navigateurs placardent depuis plusieurs mois maintenant une alerte pour signaler ceux qui ne le proposent pas quand des données sont sur le point d’être échangées. Deux exemples simples : l’envoi d’identifiants et les achats en ligne.
Il est désormais temps de franchir une nouvelle étape.
Les sites sans HTTPS deviennent « non sécurisés »
Chrome 68 introduit un changement aux vertus éducatives. Les sites avec HTTPS gardent leur cadenas et leur « Sécurisé », mais ceux ne l’ayant pas sont affublés d’un « Non sécurisé » gris. Les internautes vont donc apprendre progressivement ces deux facettes du web, avant d'affronter des changements plus radicaux.
Bon nombre d’internautes ne remarqueront sans doute même pas cette nouveauté. C’est d’ailleurs l’idée : accompagner l’adresse d’une information discrète, mais essentielle. Les utilisateurs n’auront cependant que quelques semaines pour s’y faire avant que Chrome n’aille plus loin.
Chrome 69 et 70 fermeront la marche
En septembre et octobre, les futures moutures du navigateur termineront ce travail éducatif. Dans un premier temps, Chrome 69 va supprimer l’étiquette « Sécurisé » pour un site possédant HTTPS. Le cadenas restera en place mais perdra sa couleur verte pour un simple gris. De quoi insister encore sur l’idée qu’une connexion chiffrée est la norme.
Environ six semaines plus tard, Chrome 70 viendra accentuer la pression sur les sites sans certificat. Déjà signalés comme non sécurisés, le navigateur colorera son avertissement en rouge dès que l’internaute inscrira des données dans un formulaire.
Après ces trois versions successives, Google espère que l’internaute aura compris le message : seuls les sites n’utilisant pas HTTPS seront pointés du doigt. Un changement conséquent et une inversion de philosophie qui devraient concourir à améliorer encore la sécurité générale du web. Car en dépit des efforts réalisés, la marge d’amélioration reste importante.
Selon Google, le trafic via Chrome montre ainsi une utilisation déjà massive de HTTPS, mais avec parfois de gros écarts. Au 21 juillet par exemple, 84 % des sites visités aux États-Unis étaient chargés via HTTPS. En France, le chiffre est presque aussi élevé : 82 %. L’Indonésie, la Turquie et le Japon sont cependant loin derrière, avec respectivement 68, 67 et 66 %.
Un mouvement général
Chrome est le premier à marquer tous les sites sans HTTPS comme non sécurisés. Safari, depuis sa mouture 11.1, affiche bien un message en rouge, mais uniquement pour les pages contenant des formulaires. Chrome 68 généralise son avertissement, bien qu’il faille attendre la version 70 pour l'arrivée du rouge sur les pages à formulaires.
Mais Google a beau être le premier à se jeter dans le grand bassin, les autres suivent ou prévoient de le faire. Côté Firefox, un cadenas barré d’un trait rouge apparait quand une page sans HTTPS propose un champ d’identification. À terme, le navigateur l’affichera pour toutes les pages avec du simple HTTP, mais Mozilla n’a pour l’instant pas de calendrier. Dans le menu about:config, on peut néanmoins forcer cet affichage, via le réglage security.insecure_connection_icon.enabled
. Il suffit alors de le basculer en « true
».
Les navigateurs reposant sur la base Chromium vont hériter du changement introduit par Google et devraient donc proposer le même comportement au cours des prochains mois. Quant à Edge, il suit pour l’instant le comportement courant : un cadenas pour les pages HTTPS, rien pour les pages classiques et une étiquette « Non sécurisé » si ces dernières présentent un formulaire. Microsoft n’a pas encore évoqué la suite du programme.
Notez que même si HTTPS n’est pas une protection absolue, il reste crucial pour s’assurer – autant que possible – que les données échangées n’ont pas été modifiées par un tiers. Le changement introduit par Chrome est donc important, et ce d’autant plus qu’il est le navigateur le plus utilisé au monde (environ 59 % selon StatCounter).
Enfin, ceux souhaitant aller un peu plus loin pourront se pencher sur l’extension HTTPS Everywhere de l’EFF, qui s’assure de toujours basculer sur une connexion HTTPS si le serveur contacté l’autorise. Elle est disponible pour Chrome, Firefox et Opera. Le navigateur Brave l'intègre directement.
Commentaires (39)
#1
Excellente chose pour internet mais problématique pour les appli web en local car même avec un certificat, on a un message d’alerte, le certificat n’étant pas “valide”
#2
#3
Pour ceux qui, comme moi, auraient un problème de couleurs avec cette mise à jour:
chrome://flags/#force-color-profile et changez de Default en sRGB
#4
Petit article utile :)
https://letsencrypt.org/docs/certificates-for-localhost/
#5
Bientôt un : Site non IPv6 ?
#6
“il reste crucial pour s’assurer – autant que possible – que les données échangées n’ont pas été modifiées par un tiers” Euhh, le HTTPS assure la confidentialité des données mais à quel moment il assure l’intégrité ? J’ai pas souvenirs de signatures ou de contrôles de hash pour les réponse HTTPS…
#7
#8
Ah bah, en soit c’est bien.
Mais ça va quand même être le foutoir lorsqu’ils vont supprimer le cadenas avec les gens qui vont faire (globalement à juste titre) : ah mais c’est pas sécurisé, y a pas de cadenas, surtout si la concurrence le laisse.
#9
#10
#11
j’avais 33 raccourcis sur la bookmark bar depuis des années , je n’en vois plus que 30 car il y a un espace de facilement 5mm entre chaque bookmark !
fait ch…
" />
#12
#13
Ils ne prévoient pas de suppression du cadenas pour l’instant
#14
Je ne suis vraiment pas à l’aise avec le mantra des navigateurs https = sécurisé.
Bordel, la « sécurité » d’un site s’arrete pas à ça… or, ils en font tellement des caisses la dessus que ca en devient l’alpha et l’omega de la sécurité.
Quand on voit comment certains sites sont faits et maintenus, ça fait franchement peur. « Mais c’est pas grave car on est sécurisé avec le cadenas vert »… pff, on est juste en train de tranquillement paver la route pour des vagues de phishing et de vol de pass encore plus intenses qu’on en a jamais connu car la seule chose qui retenait les “phishers” de se faire passer pour des sites “sécurisés” était le cout des certificats. Tout le mantra “https = sécurisé” repose là dessus.
Or, maintenant que ce cout est nul, cette belle incantation vaudou n’a plus aucune valeur (elle n’en avait deja pas beaucoup…)
#15
#16
#17
Au temps pour moi, j’ai lu de travers, et la drogue n’arrange rien
#18
#19
Oui on le connait bien celui-là :)
#20
#21
Et pourtant les TLS Records sont bien assurés en intégrité. C’est d’ailleurs bien clair dans les suites de chiffrement utilisées, via usage d’un HMAC : TLS_RSA_WITH_AES_128_CBC_SHA256
Pour les suites de chiffrement récentes, l’usage d’un mécanise AEAD assure la confidentialité, l’intégrité et l’authenticité : https://en.wikipedia.org/wiki/Authenticated_encryption
#22
#23
#24
#25
#26
Ce qui était faux et le sera toujours : il faut sortir de ce mensonge. Et justement, ce que fait Chrome est clairement un pas dans la bonne direction.
Le cadenas seul n’a jamais été une garantie que le site est de confiance. Il est tout a fait logique de rendre moins visible et même de le faire disparaitre a terme. Par contre un site, même si son propriétaire est honnête, peut être détourné par un intermédiaire si la connexion n’est pas chiffrée. c’est donc normal d’afficher un avertissement sur ces connexions.
#27
Ça va, le symbole “i” dans un petit rond, ça fait juste informatif pour le http.
edit : ah mais c’est le cas, j’avais zappé le paragraphe.
#28
Je viens d’avoir un échange de mail avec un fournisseur pro qui m’a envoyé un devis, à valider sur le compte en ligne que j’ai créé, et dans le mail il me donne l’identifiant/pass que j’ai choisi pour le compte. Quand je lui dit que c’est gravissimme (donc mot de passe stocké en clair chez eux), il me répond que c’est pas un soucis, que c’est juste stocké dans leur CRM sécurisé derrière un av et un pare-feu… Heureusement que j’ai un pass bien à part pour ce site, et qu’on paye par virement (pas de paiement en ligne)… Même pas de hash sur le mot de passe… Mes premiers sites en 98 on utilisait md5 (bon dépassé maintenant…)
#29
Merci pour vos retours. C’est juste que ça m’étonnais qu’on parle d’intégrité pour HTTPS car dans la plupart des cours que j’ai eu sur la question on mettait en avant la confidentialité.
#30
#31
#32
#33
#34
http://motdepasseenclair.fr/ ?
J’avais envie un mail il y a plusieurs mois pour rajouter un site mais j’ai pas eu de retour..
#35
C’est pas forcément aussi binaire. envoyé en clair dans un email != stocké en clair.
J’ai eu bossé sur un site avec des connecteurs vers un crm et un outil pour commerciaux, à l’inscription d’un internaute, on générait un pwd de 8 caractères (lol) et avant de le hasher (en md5 aussi… mais bien après 98 " /> )et de le persister, on envoyait un mail à l’internaute avec le pwd généré.
Ca vaut pas un token avec obligation définir un pwd à la 1ère connexion, mais c’est pas un pwd en clair et sans sel en base non plus ;)
#36
Oui enfin dans ce cas précis, c’est bien le mot de passe choisi par l’utilisateur qui lui a été renvoyé, et pas un mot de passe généré au niveau du serveur, si je comprends bien.
Donc le mot de passe se balade bien en clair quelque part côté fournisseur.
#37
Au renvoi, tout a fait, c’est inadmissible, et à fuir au plus vite.
J’avais compris à la création, auquel cas c’est pas terrible, mais ne présuppose pas qu’il est en clair en BDD pour autant
#38
#39
Pour info le probleme de bookmark bar dont je me plaignais va être réparé
https://bugs.chromium.org/p/chromium/issues/detail?id=848631