Firefox 51 et Chrome 56 signalent les sites non sécurisés
Firefox et Chrome ont entrepris de sécuriser le web à leur manière. Ces deux navigateurs vont inverser la logique qui avait cours jusque-là et les sites sécurisés (https) ne seront plus récompensés d’un cadenas vert, ce sont les sites non sécurisés (http) qui seront pointés du doigt avec un avertissement. On n’y est pas encore, mais Firefox 51 qui doit sortir aujourd'hui et Chrome 56 qui sera finalisé d’ici la fin du mois vont activer la première mesure de ce plan.
Avec ces deux versions, les sites non sécurisés qui affichent un champ de connexion avec un mot de passe ou bien qui demandent une carte de crédit seront signalés d’un avertissement dans la barre d’URL. Firefox 51 affichera un cadenas gris et barré d’un trait rouge, Chrome de son côté a opté pour un cadenas rouge avec une mention explicite.
https. Cliquer pour agrandirGoogle a déjà indiqué que cette fonction serait déployée progressivement et nous n’avons pas réussi à l’obtenir dans la dernière version bêta. En revanche, Firefox 51 qui sortira aujourd'hui en version finale affiche bien l’indicateur sur les sites que nous avons essayés. Ajoutons que les sites sécurisés sont toujours signalés par un cadenas vert avec la version actuelle.
Outre cette sécurité accrue, Firefox 51 est capable de lire nativement l’audio en FLAC (comme Chrome 56 d’ailleurs). Côté Chrome, cette mise à jour sera aussi l’occasion de faciliter l’utilisation d’appareils Bluetooth depuis le navigateur et d’ajouter la règle CSS sticky qui permet de laisser un élément défiler uniquement jusqu’en haut de l’écran.
Très bien!
Le lien FTP pour Firefox 51 : https://ftp.mozilla.org/pub/firefox/releases/51.0/mac/fr/Firefox%2051.0.dmg
J'ai déjà depuis 6 ans une application qui me signale a chaque clic les sites foireux.
La securitisation c'est très bien, par contre, j'ai lu des articles indiquant que le https bloquait une bonne part des outils de statistiques de visites.
Est-ce confirmé ?
Et si oui, quelles solutions ?
voilà typiquement le genre de décision, imposée en force depuis une tour de crystal que je critique de la part d'auteurs de logiciels.
Les gens sont très attentifs à ce genre de message. Du coup, ça force les gérants de site à réagir rapidement à tout mouvement de gros éditeurs.
Le plan est de progressivement imposer SSL pour tout, même sur des sites sans mot de passe.
même quand ça n'a aucun intérêt ! (un simple site informatif).
ça a des conséquences de foutre SSL partout.
En coût de certificats à acheter, gérer, maintenir : c'est une prestation, c'est un prix.
En coûts cachés comme la charge en calcul pour cryptage. J'aimerais d'ailleurs une étude qui mesure l'impact sur un usage omniprésent de SSL.
Et en fantasme qui est prêté par le public à SSL
SSL ne garantit pas la sécurité que les gens désirent réellement : qu'on ne va pas faire n'importe quoi de ce qu'ils font sur le web et que ça ne leur attirera pas des ennuis (spams, harcèlements, surveillance, etc).
SSL va garantir (quand une source d'autorité ne distribue pas des certificats bidons à n'importe qui...) que le site est qui il dit qu'il est (selon une source d'autorité dont vous avez totalement confiance donc...) et que les données sont cryptées entre votre navigateur et le site (sauf si votre employeur organise un proxy et ses propres certificats sur votre poste de travail).
SSL ne garantit pas que le site est vrai, que les gens derrières sont honnêtes avec des comptes à rendre à des services administratifs que vous pouvez contacter ou qu'un acteur étatique n'est pas en train de faire mentir le système.
La technique imposée ne résoudra pas le problème qu'on est tous obligés en tant qu'utilisateur de se former au risque nouveau et inhérent de communiquer sur internet.
Je m'inquiète que les geeks se satisferont que de ça.
"En coûts cachés comme la charge en calcul pour cryptage. J'aimerais d'ailleurs une étude qui mesure l'impact sur un usage omniprésent de SSL."
En 2016, l'impact de TLS est très faible.
Mais c'est à toi de faire les tests, bien sûr, puisque la charge dépend des ciphers, et surtout que tu parles d'impact, donc de valeur relative, donc ça dépend de l'importance de la partie réseau par rapport à la construction de la réponse.
Quand GMail est passé au tout SSL en 2010, l'impact était de moins de 1%.
Mais c'est un domaine qui a beaucoup évolué, et il n'y a pas que TLS à prendre en compte mais aussi ce que ça permet, par exemple d'activer HTTP2 qui peut permettre de descendre la charge serveur en n'ayant qu'une connexion active par client, et qui permet de diminuer un peu le volume de données, que ce soit par quelques astuces comme la compression des headers, ou par la possibilité d'utiliser la compression Brotli pour les ressources statiques aux navigateurs qui gèrent cet algorithme (Chrome et Firefox, bientôt Edge, et probablement Safari un jour).
Sinon, tu passes un peu vite sur l'intérêt de chiffrer les connexions. Je ne vais pas trop m'étendre mais tu devrais te remettre à jour sur le dossier : les attaques sur du non chiffré se sont multipliées (par exemple pour injecter du code affichant des pubs, pister l'utilisateur... http://www.infoworld.com/article/2925839/net-neutrality/code-injection-new-low-isps.html ).
Peu importe que TLS ne soit pas une garantie de sécurité parfaite, le fait est qu'entre rien et quelque chose, c'est toujours mieux d'avoir quelque chose.
J'ai mis en place TLS sur mon propre site il y a 5 ans, avant que Google promette un impact sur le SEO (qui est inexistant ou du moins imperceptible, du reste), avant ces histoires d'apparence dans la barre d'adresse, parce que je suis convaincu de l'intérêt de tout chiffrer. Penches-toi sur le sujet quelques temps, je pense que tu finiras par l'être aussi.
@oomu
Il existe des certificat SSL gratuit comme Let's Encrypt parfait pour les sites sans réel besoin de SSL
pour une entreprise cela reste un coût, ne serait-ce qu'en gestion.
"les sites non sécurisés qui affichent un champ de connexion avec un mot de passe": enfin! C'est ridicule de masquer les mots de passe à l'écran, et de les envoyer en clair sur internet. J'espère que MacG en profitera pour passer en SSL sa page de login!!!
@oomu "Le plan est de progressivement imposer SSL pour tout, même sur des sites sans mot de passe." Sans mot de passe, je suis d'accord que ça ne sert pas à grand chose. Par contre avec mot de passe, c'est vachement important, même sur un vague blog pour ado! Vu que bon nombre de gens utilisent le même couple login/mot de passe sur tous les sites, la moindre fuite sur un blog mal sécurisé et pouf, on a accès à tous les mails, facebook, linkedin, sites de shopping, de rencontres et autre, et la les conséquences peuvent être dramatiques: usurpation d'identité, chantage etc.
"même sur un vague blog pour ado" : Mouais. Enfin, l'admin, voire tous les admin de ce fameux site pour Ado ont déjà accès à ton mot de passe. Ton mot de passe est donc, d'une certaine manière, "public", dans le sens ou il est connu de plusieurs personnes. Il s'agit donc d'expliquer à son ado que le mot de passe qu'il utilise pour son blog ne devra en aucun cas être le même que d'autres sites. Idéalement, aucun mot de passe ne sera identique.
"l'admin de ce fameux site pour Ado a déjà accès à ton mot de passe": c'est vrai et c'est aussi un gros problème. On n'en a pas forcément conscience non plus. Je ne comprends pas qu'il n'y ait pas un un truc standard en http pour que le browser n'envoie au serveur qu'un hash du mot de passe (après salage avec un paramètre envoyé par le serveur), de façon à ce que personne côté serveur n'ai connance du mot de passe lui-même. Et les browser afficheraient dans ce cas une icône dans les champs de mot de passe pour indiquer si 1) le mot de passe est envoyé en clair 2) le mot de passe est chiffré, mais déchiffré côté serveur 3) seul le hash est envoyé, et de façon chiffrée.
Sur tous les sites un peu sérieux, les mots de passe sont déjà hashés et aucun administrateur n'a heureusement accès à la version en clair...
Oui, mais c'est le serveur qui décide de hasher (ou non) le mot de passe avant de le stocker. Le navigateur du client, et donc l'utilisateur, n'a aucun moyen de savoir si c'est le cas ou non. Peut-être certains sites font le hash côté client en javascript, mais ça n'est pas standard. Seul un standard au niveau HTTP (ou peut-être HTML?) permettrait au navigateur d'afficher le niveau de chiffrage réel du champ mot de passe, voire de demander confirmation à l'utilisateur avant toute utilisation d'un champ pas entièrement sécurisé.
@HoulaHup
Si le site est fait avec les pieds, oui, sinon non. Ils ne devraient avoir qu'un hash.
@HoulaHup
L'admin du site n'est pas censé avoir ton mot de passe. Il peut le réinitialiser mais pas le voir. Sinon, ça veut dire pas de cryptage et c'est interdit
"Chrome de son côté a opté pour un cadenas rouge avec une mention explicite."
Pas de cadenas rouge mais un i dans un cercle en gris foncé.
Bonjour,
et leVPN, il est où ?
Ont-ils enlevé le ralentissement drastique des performances ?
Ralentissement qui impacte égalementt macOS ?
Lire le figaro nuit gravement aux internets ?
@Liena
Je préfère lire encore Le Figaro, Les Échos, Le Canard enchaîné et le Point que ce ramassis de merde qu'est l'Obs, Marianne et surtout Libération.
C’est quoi le rapport avec Firefox ?
Troll…
"d’ajouter la règle CSS sticky qui permet de laisser un élément défiler uniquement jusqu’en haut de l’écran."
Pourquoi ? Avant il allait plus haut ?!
Note : tiens, je n'ai pas trouvé comment faire le point exclarrogatif (interrobang en anglais, unicode 203D) sous iOS. Une idée ?
Le tout SSL est un vrai danger pour la neutralité du net. Ce n'est en aucun cas une bonne nouvelle.
Un billet qui résume bien (quoi que vulgairement) la situation : http://sametmax.com/pourquoi-obliger-le-ssl-par-defaut-est-une-grosse-connerie/