Firefox 59 (Nightly) : tous les sites HTTP marqués comme non sécurisés via une option
Le 15 décembre 2017 à 09h47
2 min
Logiciel
Tous les navigateurs vont dans la même direction : à terme, les pages HTTP seront considérées comme non sécurisées et HTTPS deviendra le comportement « normal ». Qui sera le premier à réellement sauter le pas ? L'avenir le dira. Firefox vient de son côté de passer une étape supplémentaire avec sa version 59, actuellement dans le canal « Nightly ».
En effet, comme le rapportent nos confrères de Ghacks, l'option security.insecure_connection_icon.enabled
est désormais disponible. Désactivée par défaut, elle permet d'afficher un cadenas barré et un message d'alerte sur tous les sites non HTTPS. Pour le moment, ce n'est le cas que si un formulaire est disponible au sein de la page.
De quoi permettre aux éditeurs de se préparer, les derniers récalcitrants évoquant la publicité pour justifier du fait qu'ils ne protègent pas la navigation de leurs visiteurs. Une situation d'autant plus détestable lorsque ces services proposent une connexion non sécurisée, laissant les mots de passe transiter en clair entre le navigateur et leurs serveurs.
Pour activer cette nouvelle option, tapez about:config
dans la barre principale de Firefox et cherchez l'option, un double clic suffira alors à modifier le comportement... en attendant qu'il ne devienne celui par défaut.
Le 15 décembre 2017 à 09h47
Commentaires (5)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 15/12/2017 à 12h26
#1
C’est une option qui sera sûrement activée par défaut pour TOR browser.
Mozilla avait dit qu’il créerait des options pour que cette variante en bénéficie et qu’ainsi l’équipe du projet TOR n’ait plus le besoin de faire des bidouilles dans le code de Firefox.
Le 15/12/2017 à 23h44
#2
C’est une bonne idée pour Tor Browser.
Par contre, pour tous ceux qui utilisent du http en local, c’est de plus en plus gênant. Il faudrait peut-être exclure les ip privées (en IPv4) et les ip du même /64 en IPv6 de ce comportement, car on ne peut pas, sauf à générer sa propre CA, générer des certificats pour des IP privées (l’utilisation d’adresses publiques n’est pas toujours possible ni souhaitable), donc pour du local le HTTPS est vraiment contraignant et peu nécessaire (la faille KRACK ne compte qu’à moitié, elle a été plutôt bien patchée)
Le 16/12/2017 à 12h15
#3
Donc, pour eux, le téléchargement de CRL doit se faire en HTTPS ? Oeuf-Poule ?
EDIT : ok pas de formulaire, j’ai rien dit …
Le 16/12/2017 à 15h41
#4
Y’a une seconde option à activer pour ignorer les IP local.
Le 18/12/2017 à 14h26
#5
Ils veulent pas chiffrer l’ouverture de documents locaux tant qu’ils y sont ?
Nos téléphone passent le plus clair de leur batterie à décoder et à encoder de la merde chiffrée.