Alors que nous étions sans nouvelles de l'activation par défaut de l'alerte d'authentification non sécurisée au sein de Firefox, Mozilla évoque ses plans. La version 46 dédiée aux développeurs est ainsi la première concernée, afin de les sensibiliser. La suite reste à définir.
Récemment, nous avons évoqué la volonté de Mozilla d'introduire une alerte en cas d'authentification non sécurisée. Par-là, il faut comprendre que les sites qui proposent une connexion sans passer par une page HTTPS, et donc laissent passer le mot de passe en clair, afficheront une alerte sous la forme d'un cadenas barré et d'un message.
Alerter les développeurs sur les mauvaises pratiques
Prévue au départ pour être introduite dans Firefox 44, elle avait été mise de côté le temps de corriger quelques bugs. Pour le moment, il est néanmoins possible de l'activer en suivant la procédure suivante :
- Taper about:config dans la barre d'adresse de firefox
- Rechercher l'option security.insecure_password.ui.enabled
- Effectuer un clic droit puis sélectionner Inverser pour passer la valeur à true
Mais dans un billet de blog intitulé « Les formulaires de connexion en HTTPS, s'il vous plaît », Mozilla indique une première étape pour l'activation par défaut de cette fonctionnalité. Elle est ainsi pour le moment intégré de la sorte dans l'édition dédiée aux développeurs, actuellement basée sur la branche 46. Selon le calendrier de la fondation, celle-ci est prévue pour arriver dans le canal général, et donc diffusée à tous les utilisateurs, d'ici le mois d'avril prochain.
Elle précise d'ailleurs au passage qu'il faut non seulement envoyer les informations de connexion via HTTPS mais que le formulaire doit lui-même être diffusé de la sorte pour éviter tout problème.
Mais Mozilla semble surtout vouloir lever le pied sur la généralisation de cette alerte, sans doute pour éviter de faire paniquer tout le secteur. En effet, la grande majorité des sites (hors des gros services) n'utilise pas du tout HTTPS pour la phase de connexion comme nous l'avions évoqué précédemment. Voir un cadenas barré se généraliser ainsi pourrait constituer une information claire donnée aux utilisateurs, mais aussi leur faire perdre toute confiance en les sites qu'ils visitent au quotidien.
HTTPS doit devenir la norme
L'objectif est donc tout d'abord de sensibiliser les développeurs, qui sont en première ligne pour cette évolution des mentalités. L'affichage de cette indication dans le navigateur est ainsi la suite logique de l'avertissement qui était déjà en place au sein de la console.
Dans une FAQ assez détaillée sur la question de la sécurisation de la phase de connexion qui vient d'être publiée elle confirme qu'aucun plan précis n'est pour le moment en place pour une activation dans le canal Beta ou général. Néanmoins, la fondation rappelle qu'elle va à terme considérer comme obsolète les sites accessibles uniquement en HTTP, tout comme Google avec Chrome. L'arrivée d'initiatives comme Let's Encrypt facilite d'ailleurs grandement le passage de nombreux sites à HTTPS.
Reste maintenant à voir si les développeurs et les éditeurs de sites prendront cette question en considération, ou s'il faudra en passer par une activation par défaut plus large d'une alerte pour que les choses bougent enfin.
Commentaires (37)
#1
Voir un cadenas barré se généraliser ainsi pourrait constituer une
information claire donnée aux utilisateurs, mais aussi leur faire perdre
toute confiance en les sites qu’ils visitent au quotidien.
Pourtant il faut bien être secoué pour prendre conscience du danger.
Ce n’est pas la version “developer” du navigateur qui va faire changer les choses. La prise de conscience se fera avec la version stable (et pas que celle de Firefox).
sensibiliser les développeurs, qui sont en première ligne pour cette évolution des mentalités
Malheureusement les décideurs ne sont pas forcément aussi ouverts à ces changements
En général on fait les changements quand il y a eu une alerte voire un gros pépin, pas avant. Donc attendons avril pour le faire en urgence, n’anticipons rien, comme d’hab !
#2
Je rappelle la solution pour les devs : passer les champs “password” en “text” et mettre une librairie js qui cache les caractères quand même.
#3
C’est ça qu’on attend de Mozilla, tirer le web vers le haut.
J’ai l’impression qu’ils sont de retour en force depuis 2 mois chez Mozilla.
#4
Cette croisade ridicule…
#5
Je suis d’accord. Ils se restructurent bien, et repensent leurs projets.
Bordel, si j’ai pu mettre du HTTPS sur mon raspberry pi en quelques minutes sans être sysadmin de mon métier, je comprends pas pourquoi le https n’est pas la norme !
#6
il y a au moins 3 raisons a cela:
Cela coute chere ( pour ma boite on est pas loin des 3000€ )
Avant LetsEncrypt ca ne s’industrialisait pas
ca a un cout CPU, donc necessite d’upgrader les configs materiel pour absorber cela ….
#7
3000€ pour ? Pour ma boite, 4 certificats wildcards on est à 400€…
#8
#9
#10
#11
Et le certificat ?
#12
C’est quoi le rapport entre un développeur et HTTPS?
HTTPS, c’est du boulot de SYSADMIN, c’est qui qui va gérer la mise en place des certificats et la configuration du serveur web.
Le seul truc que le développeur doit faire, c’est de ne pas mettre HTTP en dur dans ses URL.
Ensuite, let’s encrypt permet d’obtenir gratuitement des certificats et de faciliter la procédure d’installation.
Mais let’s encrypt ne permet pas d’avoir du HTTPS sur des offres d’hébergement web mutualisés. (ce qui représente une partie non négligeable de sites web, les plus impactés étant ceux qui auto-hébergent leurs blogs/wordpress)
#13
on a masse de wildcard et surtout enormement de domaines differents
il faut aussi savoir qu’il y a plusieurs niveau de certificat, les plus evolués sont plus chers que les rapidssl
voir ici par exemple:https://www.symantec.com/fr/fr/ssl-certificates/
#14
#15
Let’s Encrypt est une véritable plaie, bon courage à ceux qui l’installent :
https://blog.imirhil.fr/2015/12/12/letsencrypt-joie-deception.html
#16
#17
Alors où ça a bien évolué, ou l’auteur du blog ne fait pas vraiment d’effort pour trouver des solutions.
* Des paramètres par défaut insuffisants –> chez moi les clef généré font 4098 bits
* Arrêt de production ou HTTPS only non supporté –> j’utilise le mode web-root qui va écrire le chalenge dans l’arborescence du serveur web, donc sans aucun arrêt
* Non prise en compte des standards annexes de HTTPs –> j’utilise DANE avec letsencrypt et le renouvellement des certificats dans le DNS est automatisé chez moi
Alors oui, il y a quelques problèmes, mais ça reste une béta et letsencrypt communique bien avec la communauté sur https://community.letsencrypt.org
De plus je pense que la limite de validité de 90 jour est surtout là pour la béta. Il semblerai que plus de souplesse puisse être proposé a la fin de la béta https://community.letsencrypt.org/t/pros-and-cons-of-90-day-certificate-lifetimes
#18
Pourquoi essayer de tout mettre en httpS
certains sites ( informatifs ou autres ) ne devraient meme pas en avoir besoin
seulement pour capter ce que fait l’internaute qui y passe les boites ont developpé la vilaine manie googolienne
de mettre des trackers internes partout pour definir le(s) profil(s) de ses utilisateurs
Par ailleur il me semble qu’il y a une faille dans le tls et que le ssl a eu en 2015 son lot de gruyere
alors “encrypter” les connections aux sites sensibles : banques / assurances / boites mail / site gouvernementaux
lorsque l’on consulte ses données ok
mais vouloir mettre du https sur un www.wikipedia.com .. heu comment dire :/
si “ils” veulent securiser quelque chose, qu’ “ils” commencent par securiser les connections et transmissions des objets connectés
nb : remplacer par votre site internet preferé commehttp://www.archive.org/ par exemple
#19
tu oublies le mode “Michu” qui permet la réutilisation à l’infini du même passwd de 6 caractères (le nom du chien en général)
rajoute du http sur du wifi public, et ton michu est à poil partout
le httpS devrait être utilisé partout où il y a un secret à transmettre, et wikipedia transmet un secret quand tu t’identifie
#20
#21
#22
C’est plus facile de mettre en place un certificat SSL que de faire cette bidouille…
#23
Ridicule en quoi ? Je trouve bien que Mozilla se préoccupe de sécurité et pousse les devs WEB à faire de même.
Ou alors, je n’ai pas compris ta remarque …
#24
#25
Ce que je trouve ridicule, c’est de vouloir à terme forcer tout le monde à utiliser l’HTTPs, alors que cela n’est pas utile partout. Ce choix ne concerne en rien Mozilla.
#26
#27
Surtout que c’est bien beau de dire à tout le monde de passer “https allez-y vous serez sécurisé” alors que les sites web sont bardés de spywares.
#28
Ça concerne Mozilla parce que la sécurité et la vie privé sur le web font partie des missions de la fondation. On peut pointer les positions hypocrites qu’ils adoptent parfois sur ces points, reste que c’est sensé être un de leur but.
On peut aussi discuter si imposer https partout est un moyen efficace pour s’approcher de ce but.
Pour moi c’est le grand n’importe quoi des implémentations de SSL/TLS actuelles qui les poussent à prendre certaines décisions drastiques et contestables (http/2 sur tls uniquement). Nom de nom, les 3⁄4 des grosses boutiques en lignes ou journaux ont leurs formulaires de connexion et sessions en http, avec juste l’envoie du login/mdp vers une page https, ce qui tient du placebo de sécurité; surtout trouvé un site de porn sur https c’est toujours compliqué en 2016 :)
#29
Sinon à part cette fonctionnalité pour la version de Firefox 46, y a t-il d’autres nouveautés + ou - intéressantes ?
#30
Sauf que cela n’apporte rien. Prenons PCI par exemple. Passer au HTTPS n’apporte strictement rien, à moins que des membres ne s’échangent des informations hautement confidentielles par message privé, auquel cas ils
mériteraient les pépins qui pourraient leur arriver si par malheur leur connexion à PCI était sniffée.
PCI n’a rien de sensible, et les données sont stockées en clair sur les serveurs. En conséquence:
En conclusion, je vois la généralisation du HTTPS d’un très mauvais œil.
#31
Je ne pense pas vraiment que l’intérêt de TLS soit super critique pour PCI, après c’est juste mieux en https que sans… moi je me connecte pas en clair, mais je suis parano, spa pareil. Mais faut pousser TLS (correctement mis en place) sur pleins de sites, ça c’est clair aussi.
#32
On pourrait trouver cela bien d’un point de vue sécurité et vie privée, mais il faut rappeler que le HTTPS n’est pas gratuit, tant du point de vue ressources serveur que du point de vue client. La consommation d’énergie du web va encore augmenter alors que c’est déjà un problème.
#33
Parfait! La solution ultime
" />
#34
Le plus embêtant c’est que jusqu’à récemment les virtual host ne sont pas supporté en SSL, du coup un site SSL = IP.
Il faut soit mettre à jour vers des versions d’Apache, IIS qui supportent le SNI tout en gardant à l’esprit que certains navigateurs ne le supportent pas.
Peut-être que ça accéléra le déploiement de l’IPv6 et encore ça ne résoudra pas les problèmes de compatibilité.
Les sites ne pouvant déployer du https et ayant besoin d’une authentification se tourneront sans doute vers du SSO de type Google, Facebook ou OpenID.
Notre dépendance aux géants va encore augmenter car je ne suis pas sûr que l’on nous laisse le choix.
#35
Le support SNI est déjà bien déployé, pas parfait mais déjà très bon et qui s’améliore rapidement.
Les navigateurs problématiques c’est IE sur windows XP et android2, des configs mourantes déjà plus supporté officiellement par un paquet de sites.
Coté serveur c’est déjà déployé en masse et “facile” à mettre à jour (pour les solutions FLOSS en tout cas, pour IIS aucune idée), au pire tu mets un ptit nginx en front de ton serveur legacy, c’est 3h de taf pour un sysa débutant.
#36
0€/an chez StartSSL
#37
Let’s Encrypt. C’est sûr que maintenant c’est facile et que ça ne l’a pas toujours été, mais quand même… Si le https existait et était utilisé, c’est que ce n’était pas insurmontable !