Firefox 46 bêta renforce la sécurité du code JavaScript JIT

Firefox 46 bêta renforce la sécurité du code JavaScript JIT

En échange d'une micro-chute de performances

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

14/03/2016 3 minutes
17

Firefox 46 bêta renforce la sécurité du code JavaScript JIT

Depuis quelques jours, les testeurs peuvent récupérer la bêta de Firefox 46. Peu de nouvelles fonctionnalités, mais on y note quelques changements importants pour la sécurité. Les sites sans HTTPS proposant un formulaire de connexion seront ainsi marqués comme non sécurisés.

Firefox 46 ne brillera pas par ses nouveautés visibles. La grande majorité des changements se trouve sous le capot. L’intégration GTK3 pour Linux est ainsi présente, et cette fois-ci pourrait être enfin la bonne. Rappelons que cette prise en charge fait des allers retours dans Firefox depuis quelques versions, Mozilla n’étant finalement pas satisfait du niveau de qualité pour une version finalisée. Le support de GTK3 permet de réduire la dépendance à X11, une meilleure intégration dans les thèmes ou encore une compatibilité renforcée avec le HiDPI.

De la sécurité avant tout

La nouvelle version présente également deux changements importants pour la sécurité. D’une part, l’activation du marquage des sites comme non sécurisés quand ils proposent un formulaire de connexion sans HTTPS. Nous avions abordé en détails ce mécanisme, qui établit un changement significatif de paradigme : ne plus mettre en avant les sites possédant une connexion sécurisée, mais uniquement ceux qui n’en ont pas. Le fait qu’un site possède une connexion chiffrée devient ainsi la situation « normale ».

D’autre part, Mozilla annonce une meilleure sécurité pour la compilation Just-in-Time de JavaScript. Elle se fait au travers d’un mécanisme baptisé W^X, qui intervient sur le code RWX (read-write-execute). Ce dernier peut présenter des soucis de sécurité car il constitue une exception à certaines règles fixées par les systèmes d'exploitation, comme le stockage du code dans une zone où la mémoire peut être exécutée, mais non écrite.

L’activation de W^X permet d’interdire par défaut l’écriture dans les pages mémoire contenant du code JIT. Les développeurs ont donc intérêt à jeter un œil pour vérifier que la compatibilité est préservée, même s’il ne devrait y avoir aucun problème particulier. Il existe cependant un petit écart de performances, Mozilla estimant la chute comprise entre 1 et 4 % selon la configuration et le type de code.

La version Android sait mieux exploiter les onglets en cache

Pour le reste, Firefox 46 corrige divers bugs, l’utilisation du Content Decryption Module pour lire les contenus AAC et H.264 quand c’est possible, de meilleures performances pour WebRTC ou encore le support de HKDF pour l’API Web Crypto.

Quant à la version 46 pour Android, elle apporte une paire de fonctionnalités bienvenues. Par exemple, les onglets contenant des sites mis en cache peuvent maintenant être lus sans aucune connexion internet. Cet ajout n'est pas forcément compatible avec tous les sites, mais Firefox indiquera dans tous les cas en bas de l'écran quand il est exploité. Outre une compatibilité avec le nouveau système de permissions de Marshmallow (Android 6.0), le navigateur indique également l'adresse de la page quand il lance une notification au sujet d'un onglet ouvert en arrière-plan.

Attention tout de même, il s'agit de la toute première version Android à se débarrasser du support d'Honeycomb, plus précisément les versions 3.0 à 3.2.6 du système mobile. Les utilisateurs concernés ne pourront donc pas installer ce navigateur.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

De la sécurité avant tout

La version Android sait mieux exploiter les onglets en cache

Commentaires (17)


En parlant de sécurité, FF 45 affiche un triangle jaune sur la version https de NXI.








Inny a écrit :



En parlant de sécurité, FF 45 affiche un triangle jaune sur la version https de NXI.





idem, pas sur la page d’accueil, mais sur les pages des articles.



C’est parce que certains éléments sont chargés en HTTP (probablement des images et/ou des scripts)


oui il s’agit du certificat ssl278987.cloudflaressl.com et non pas celui de NXI d’où l’avertissement du navigateur.


D’ailleurs, je me suis souvent demandé pourquoi tout n’était pas envoyé sous HTTPS, images et scripts compris. Sont-ce des raisons de performance ?








StephaneGames a écrit :



oui il s’agit du certificat ssl278987.cloudflaressl.com et non pas celui de NXI d’où l’avertissement du navigateur.





Ca c’est normal, le domaine *.nextinpact.com et nextinpact.com sont déclarés dans les noms alternatifs du certificats.



Le soucis vient bien d’éléments non chiffrés.





Par exemple, les onglets contenant des sites mis en cache peuvent maintenant être lus sans aucune connexion internet.





Ca c’est une bonne nouvelle ! C’est rageant de voir la page se recharger juste parce qu’on n’a pas pas tout lu la première fois.

J’espère que les autres navigateurs feront de même, ça serait bien pratique (et économiserait le forfait mobile).








CryoGen a écrit :



Ca c’est normal, le domaine *.nextinpact.com et nextinpact.com sont déclarés dans les noms alternatifs du certificats.



Le soucis vient bien d’éléments non chiffrés.





Bien sur que non ce n’est pas normal !

Le certificat qui apparait a comme CN ssl278987.cloudflaressl.com pour le site nextinpact.com.

Si le certificat était celui de nextinpact ce serait bon.

La cela revient au même que si les connexions subissaient un man in the middle de la part de cloudeflaressl !



 

Toi tu fais référence à un autre souci qui peut se poser ou effectivement il y a un mélange de contenu HTTP et HTTPS sur la page.



Non pas une attaque man in the middle étant donné que cloudflare fournit a nextInpact aussi bien un proxy contre les ddos qu’un service de cache et que la gestion du ssl. Il est donc normal que le certificat ssl soit d’eux. Le problème vient d’une unique image provenant du domaine pbs.twimg.com en http.








StephaneGames a écrit :



Bien sur que non ce n’est pas normal !

Le certificat qui apparait a comme CN ssl278987.cloudflaressl.com pour le site nextinpact.com.

Si le certificat était celui de nextinpact ce serait bon.

La cela revient au même que si les connexions subissaient un man in the middle de la part de cloudeflaressl !



 

Toi tu fais référence à un autre souci qui peut se poser ou effectivement il y a un mélange de contenu HTTP et HTTPS sur la page.







Le CN principal est au nom de clouflare mais dans la liste des CN supplémentaire il y a bien nextinpact. Renseigne toi un peu sur les certificats, cloudflare etc.

Ensuite on parle de l’alarme firefox qui est bien du au mélange https/http, rien à voir avec le certificat.







Meewan a écrit :



Non pas une attaque man in the middle étant donné que cloudflare fournit a nextInpact aussi bien un proxy contre les ddos qu’un service de cache et que la gestion du ssl. Il est donc normal que le certificat ssl soit d’eux. Le problème vient d’une unique image provenant du domaine pbs.twimg.com en http.







Ah merci pour la précision, étant donné que j’ai désactivé les éléments sociaux, je me demande pourquoi cette image serait chargée…









CryoGen a écrit :



Le CN principal est au nom de clouflare mais dans la liste des CN supplémentaire il y a bien nextinpact. Renseigne toi un peu sur les certificats, cloudflare etc.

Ensuite on parle de l’alarme firefox qui est bien du au mélange https/http, rien à voir avec le certificat.





Effectivement je ne connaissais pas cette partie du certificat “Certificate Subject Alt Name”.

 

 





CryoGen a écrit :



Le CN principal est au nom de clouflare mais dans la liste des CN supplémentaire il y a bien nextinpact. Renseigne toi un peu sur les certificats, cloudflare etc.

Ensuite on parle de l’alarme firefox qui est bien du au mélange https/http, rien à voir avec le certificat.







Ah merci pour la précision, étant donné que j’ai désactivé les éléments sociaux, je me demande pourquoi cette image serait chargée…





Donc si l’image incluse provenait d’un des sites mentionnés dans la liste des sites Alt Name on n’aurait pas d’alerte du navigateur ?

Si c’est ça c’est vraiment pas terrible. Si un des sites de la liste  est compromis les autres le sont aussi par ricochet.

 









StephaneGames a écrit :



Donc si l’image incluse provenait d’un des sites mentionnés dans la liste des sites Alt Name on n’aurait pas d’alerte du navigateur ?

Si c’est ça c’est vraiment pas terrible. Si un des sites de la liste  est compromis les autres le sont aussi par ricochet.







Si l’image était chargée en HTTPS avec un certificat valide (en l’occurrence celui de twitter) ou le même que celui utilisé actuellement par Nxi alors on aurait pas d’alerte de sécurité vu qu’il n’y a pas de problème de certificat. Le HTTPS (tout comme le HTTP) ne dit pas que les éléments d’un autre domaine ne doivent être chargé.



 Je ne connaissais pas ce champ “Certificate Subject Alt Name”

https://en.wikipedia.org/wiki/SubjectAltName

 

http://wiki.cacert.org/FAQ/subjectAltName



Un point important pour les certificats s’il y a un champ SAN alors le CN du certificat ne doit pas être pris en compte.

 

cf extrait de stackoverflow :

as per RFC 6125,

published in ‘2011 the validator must check SAN first, and if SAN

exists, then CN should not be checked. Note, that the RFC 6125 is

relatively recent and there still exist certificates and CAs that issue

certificates, which include the “main” domain name in CN and alternative

domain names in SAN. I.e. by excluding CN from validation if SAN is

present, you can deny some otherwise valid certificate.

 

Merci Cryogen pour l’info.








CryoGen a écrit :



Si l’image était chargée en HTTPS avec un certificat valide (en l’occurrence celui de twitter) ou le même que celui utilisé actuellement par Nxi alors on aurait pas d’alerte de sécurité vu qu’il n’y a pas de problème de certificat. Le HTTPS (tout comme le HTTP) ne dit pas que les éléments d’un autre domaine ne doivent être chargé.





oui merci. De temps en temps un petit rafraichissement de la mémoire ne fait pas de mal.



Je vois que vous parlez du triangle de Firefox dans les commentaires, mais chrome fait la même chose :  c’est grisé.



Edit : et à priori ça vient effectivement de ressources chargées en http (alors qu’elles existent en https), mais je laisse ça au service technique&nbsp;<img data-src=" />


Bonjour

Vous mentionnez la version 46 pour Firefox beta et les chargements proposés mentionnent la version 45.

Merci de corriger.

&nbsp;


“Avant”, on aurait pu dire que c’est pour des questions de perfs. Maintenant, avec la généralisation du haut débit, ça se justifie plus vraiment.