Firefox était l’un des premiers navigateurs à avoir intégré un mode lecteur, avant que la fonction devienne courante. Pour rappel, le lecteur reprend le texte de la page en cours et l’affiche sous une forme simple, débarrassée de toute distraction.
La nouvelle version 129 apporte plusieurs nouvelles options à ce mode. Dans les réglages, on trouve ainsi des paramètres pour l’espacement entre les lettres, l’espacement entre les mots et l’alignement du texte. Le panneau des thèmes s’enrichit de nouveaux venus et autorise surtout la pleine personnalisation.
Plusieurs autres améliorations significatives sont présentes. Par exemple, les onglets en arrière-plan peuvent maintenant afficher un aperçu du site quand on y passe la souris (la fonction est en cours de déploiement). Le remplissage automatique des adresses est enfin disponible en France (et en Allemagne).
Tout aussi important, HTTPS est désormais le protocole par défaut pour la barre d’adresses. Si un site n’est pas disponible en HTTPS, Firefox basculera automatiquement en HTTP. En outre, les enregistrements DNS HTTPS peuvent maintenant être gérés par le résolveur DNS du système (Windows 11, Linux, Android 10 +) et ne nécessitent plus DoH (DNS over HTTPS).
Outre la prise en charge de plusieurs nouvelles langues sur Mac via VoiceOver, Firefox 129 corrige aussi 14 failles de sécurité, dont 11 de sévérité élevée.
Commentaires (17)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 08/08/2024 à 09h03
Sinon pour le mode lecture, je trouve qu'il manque une option "masquer les images" personnellement, mais c'est pas mal quand même d'avoir plus de paramètres.
Le 08/08/2024 à 09h15
L'un suit les recommandations de la sémantique du web, l'autre vend entrainer une IA pour le faire.
Le 08/08/2024 à 09h52
Les thèmes par contre, c'est nouveau.
Le 08/08/2024 à 10h22
Par contre, ce qu'il manque, c'est d'avoir un peu plus de choix de police; c'est quand même dommage, pour un mode lecture, de ne pas pouvoir choisir facilement* Literata, Bookerly ou OpenDyslexic - même si le pré-requis est qu'elles soient installées sur le système !!
*C'est faisable en activant un truc legacy dans about:config et avec un userContent.css, mais je ne considère pas ça "facile" - surtout qu'avec FF 129, ça a changé. D'ailleurs, la question sur superuser.com qui a presque 9 ans a une nouvelle réponse datée ... d'hier, intitulée «Firefox 129 and onwards»
Le 08/08/2024 à 10h20
La bascule automatique sur http évitera donc pas mal de soucis avec les appareils locaux comme les freebox. Pour le wan, j'imagine que cela est devenu rare.
Sur mes serveurs, le port 80 est à l'écoute uniquement pour la validation letsencrypt ou la redirection vers https.
Peut être que je vais remplacer la redirection par une erreur 444 un jour car plus personne ne vas avoir de bonne raison d'essayer en http par défaut.
Le 08/08/2024 à 10h32
Je peux déjà le bloquer dans les paramètres et c'est une obligation chez moi pour que mon pihole soit opérationnel.
Il existe en outre déjà plusieurs modes intermédiaires qui activent ou non DOH en fonction du contexte. Peut être que ce sont les règles de choix automatique qui ont évolué.
Le 08/08/2024 à 11h19
En https, ce n'est pas nécessaire d'avoir cette protection puisque si une réponse DNS te donne une mauvaise IP pour te rediriger vers un faux serveur. Le faux serveur sur lequel tu vas te connecter ne pourra pas avoir de certificat valide, et le navigateur t'empêchera d'accéder à la page web au bout du compte.
J'ai deux choses à ajouter la dessus:
- Repasser en DNS classique permet au fai, ou n'importe qui sur le passage entre toi et le serveur DNS de voir les requêtes en clair et en déduire les sites que tu visites.
- Je ne sais pas si DoH, DoT, DoQ, ... sont implémentés coté Windows, mais re-passer par le resolver de Windows permet juste de mettre le niveau de sécurité de Firefox au niveau de sécurité de l'OS à ce niveau là. Ce que je trouve bien plus propre, plutôt que chaque appli implémente son resolver. Surtout pour ceux qui utilisent des solutions comme PiHole, Adguard, etc...
Le 08/08/2024 à 11h40
Je partage ton point de vue concernant le fait que la résolution est l'affaire de l'OS.
Je peux comprendre que ff s'en charge pour les vieux OS plus mis à jour mais pas pour les autres.
Le 08/08/2024 à 13h27
Le 08/08/2024 à 16h30
DoH, DoT, DoQ, DNSSEC, ...
La question, c'est toujours "A qui tu fais confiances?"
C'est valable dans le cas du resolver DNS que t'utilises, mais aussi pour ceux qui utilisent des "VPN" (je parles des CyberGhost et autre trucs relayés par les youtubeurs), etc...
Modifié le 08/08/2024 à 14h21
En même temps, ça va un peu à l'inverse de ce qui est expliqué au #.5.3 là sur les enregistrements de type https.
Le 08/08/2024 à 14h47
Après, il peut y avoir un résolveur cache local mais ce n'est pas obligatoire.
Avec DOH, le navigateur ignore tout simplement les informations du système et demande directement à google ou autre, y compris pour les noms de machines locales : pas de domaine racine ou un domaine racine comme .loc ou .home
C'est donc un comportement plutôt dêsirable sur un téléphone mobile ou en wifi non sécurisé pour l'accès à des ressources globales, mais cela pose des problèmes en entreprise ou sur un réseau local.
Modifié le 08/08/2024 à 13h41
L'autorité fait une résolution inverse comme pour le mail pour vérifier ?
Sinon windows 11 fait du DOH/DOT, ça se configure sur l'interface (2 fois v4 et V6).
Le 08/08/2024 à 14h38
Un faux serveur n'est simplement pas en mesure de produire un certificat valide sauf en cas d'attaque de l'homme du milieu institutionnelle comme le DPI en entreprise mais cela implique d'installer des certificats racine dans les OS des machines clientes pour signer les certificats de complaisance.
Les seuls certificats qui ne sont pas du tout vérifiables sont les certificats autosignés que l'on ne trouve quasiment plus qu'en local.
Avec les attaques de l'intérieur qui peuvent se produire via une caméra IP par exemple, ce genre de certificats devient dangereux.
C'est pour cela qu'il faudrait selon moi mettre en place la gestion des certificats racines locaux. Ces certificats pourraient être générés et gérés par les box ou les routeurs et seraient réservés à des domaines locaux: .home ou .loc et ne pouraient correspondre qu'à des adresses non globales.
Avec une telle chose, il serait possible de rendre accessible à tout le monde un moyen de sécuriser son réseau local sans grandes connaissances. La box pourrait ainsi générer les certificats pour le nas, la caméra ip, l'imprimante bref, tous les serveurs d'un lan relativement lamba.
Le 08/08/2024 à 16h25
Q1:
L'adresse IP n'est pas dans le certificat. Mais avec https, ce n'est pas important.
Pour imager ce que je dis, imaginons qu'il y a un site www.toto.com qui résoud en 1.2.3.4.
Imaginons qu'un DNS malintentionné te réponds que www.toto.com est à 5.6.7.8 et que ton navigateur s'y connecte. Alors 2 cas possible:
- en http: ton navigateur va s'y connecter, et il si le site est correctement imité, tu ne seras pas capable de dire si tu est sur le vrai www.toto.com ou une copie destiné à récupérer tes identifiants par exemple.
- en https: Au moment de la vérification du certificat, le serveur qui prétend être www.toto.com ne sera pas en mesure de fournir un certificat valide qui certifie qu'il est www.toto.com.
Dans ce second cas, le certificat qui va t'être présenté aura au moins l'un des caractéristiques suivantes:
- reconnu par une CA publique, mais pas émis pour le domaine www.toto.com
- émis pour le domaine www.toto.com, mais pas reconnu par une CA publique
=======================
Q2:
Pour des certificats EV, c'est un process manuel au départ où tu dois envoyer un Kbis de ta société. C'est un cas particulier qui représente très peu de site web. Ca permet de mettre le nom de la société dans le certificat.
Aujourd'hui, 99% des sites web sont signés avec Let's Encrypt de façon automatique. Ca ne prouve pas que abc.com appartient à la société ABC, mais juste que le site abc.com appartient bien à celui qui possède le nom de domaine abc.com.
Le process le plus utilisé est le suivant (mais il y en a d'autre moins utilisé):
- Le client (serveur à protéger) se connecte à Let's Encrypt ("LE") en demandant un certificat "bidule.com"
- "LE" t'envoi un challenge pour lequel tu dois mettre la réponse dans un path bien spécifique (.acme/xxx)
- "LE" se connecte à http://bidule.com/.acme/xxx pour vérifier que tu es bien le propriétaire de bidule.com en s'assurant que le challenge est réussi
- "LE" génère un certificat signé par la RootCA Let's Encrypt et l'envoi au client.
Ce qui signifie que si tu n'es pas le propriétaire de bidule.com, tu ne pourras pas créer un champs A ou CNAME pour envoyer bidule.com vers l'IP de ton serveur, et donc "LE" ne pourras pas vérifier le challenge.
PS:
Avec "LE", tu peux aussi faire un système de challenge via DNS, mais c'est moins utilisé.
Certaine grosses boites font carrément leur propre certificate authority et s'auto signe ensuite (Google par exemple). Tu peux regarder dans le magasin de certificat de Firefox, y'en a des centaines.
Modifié le 08/08/2024 à 12h07
Une explication de ce que permet ces enregistrements. Ça permet en gros d'être plus rapide.
J'ai signalé l'erreur pour proposer une amélioration du texte de la brève.
Le 11/08/2024 à 23h26