Faille SSL/TLS:Mozilla envisage de désactiver le plug-in Jav

[G_HZ]

Faille SSL/TLS : Mozilla pourrait désactiver le plug-in Java sur Firefox, pour prévenir le contournement de politique de la même origine


Dans la foulée de la crise que soulève la faille critique des protocoles SSL et TLS récemment démontrée, la fondation Mozilla patauge encore et peine à trouver une issue de secours rapide pour son navigateur.

Firefox ne supporte pas encore les versions plus récentes et non vulnérables du protocole pour les imposer (TLS 1.1 et 1.2). C'est pourquoi la fondation pointe du doigt le plug-in Java sur lequel elle envisage de tirer une croix.

La présence du plug-in d'Oracle est effectivement un maillon indispensable pour le PoC BEAST. Cette chaîne d'exploit que deux chercheurs ont mis au point pour démontrer la faisabilité de leur attaque par récupération de texte clair.

La vulnérabilité, qui affecte le mode d'opération d'enchaînement des blocs, ne peut être exploitée sans le contournement de la politique de la même origine (Same Origin Policy [SOP]), censée empêcher les communications avec d'autres serveurs.

Et c'est précisément ce qu'une faille auparavant connue de Java facilite.

Les développeurs de Mozilla estiment que c'est à Oracle de combler cette faille en premier, mais devant le silence de ce dernier, ils envisagent de désactiver temporairement son plug-in.

« De ce que j'ai compris, Oracle pourrait être ou non conscient des détails de cet exploit du Same Origin. Jusqu'à maintenant, nous n'avons aucune estimation du temps nécessaire pour avoir un correctif du plug-in Java », explique Brian Smith, l'instigateur de cette proposition.

Si l'on arrive là, nombreux sont les sites et services qui en seront affectés, la nouvelle fonctionnalité de chat vidéo de Facebook n’en est qu’un exemple.

La solution de Mozilla est, vu les circonstances, plus critique que celles de ses concurrents.

Google a choisi d’implémenter une technique sophistiquée pour brouiller le texte à chiffrer en y injectant des paquets vides. Actuellement en test sur la version instable de Chrome, cette solution semble ne poser problème qu'avec très peu de sites. Elle pourrait donc être intégrée à la prochaine version 15 du navigateur.

Microsoft recommande d'activer TLS 1.1 et TLS 1.2, supportés par Internet Explorer, mais désactivés jusque-là par défaut. Pour communiquer avec les serveurs qui ne supportent que les anciennes versions, Redmond préconise de mettre en priorité l'algorithme de chiffrement RC4, insensible aux attaques par récupération de texte clair.

Source : Bugzilla


Source de l'article : developpez.com

[Abraxas]

Quelle daube ce Java. Déjà, j'aimerais bien que FF bloque le lancement du plugin JRE quand une page web affiche un applet Java, même si le plugin est actif par défaut. Je crois que Chrome propose ça, ça éviterait de lancer Java sur les onglets nouveaux ouverts que l'on referme vite parce que ça nous soule de se taper le lancement de JRE et le chargement de l'application Java.
Bref, un moyen d'autoriser Java à la volée quand un onglet le demande.

[Bob49]

Bonsoir

Que Java soit pointé du doigt, ce n'est pas très étonnant..les cochonneries ont bien souvent arrivé par celui-ci !
Même moi, je m'étais fais avoir sous W98 en désactivant mon antivirus moins d'une minute et en récoltant 7 trojans dans un dossier Java. Heureusement, l'antivirus les avait détecté dés son activation.

Bref, un moyen d'autoriser Java à la volée quand un onglet le demande.

Tout à fait d'accord. En attendant, le plugin Java est désactivé pour tous mes Firefox.

[adenan]

Quelle daube ce Java. Déjà, j'aimerais bien que FF bloque le lancement du plugin JRE quand une page web affiche un applet Java, même si le plugin est actif par défaut.
[...]
Bref, un moyen d'autoriser Java à la volée quand un onglet le demande.

Bonsoir,

L'add-on QuickJava fait ça (entre autres choses sympathiques) : https://addons.mozilla.org/fr/firefox/addon/quickjava/
Fonctionne très bien, je l'ai utilisé un moment pour le même usage (bloquer les applets java par défaut, et les réactiver d'un clic au besoin).

[Abraxas]

Merci pour l'info.
Je vais voir aussi si Bugzilla propose un ticket pour autoriser le Java à la volée.

[teoli2003]

Voilà l'exemple même d'un désinformation G_HZ. Ton message est bourré d'approximation.

1) Firefox 7 (y. c. avec Flash dernière version) n'est pas sujet à la faille de BEAST. Certaines vieilles versions sont susceptibles de tomber face à BEAST, mais pas Fx7.
2) Java peut être utilisé pour compromettre des Fx (avec un BEAST modifié), d'où le problème. (Une raison pour s'en débarrasser, mais la peur d'en avoir besoin est grande chez les utilisateurs...)
3) D'autres plugins pourraient aussi l'être (mais comme ils sont peu courant, personne ne s'en inquiète vraiment).
4) Mais surtout supporter TLS 1.1 et 1.2 n'est pas suffisant pour contrer BEAST! En effet, il faut également que:
- les serveurs supportent TLS 1.1 et 1.2, ce qui n'est de loin pas le cas
- empêcher les downgrades de TLS 1.1/2 -> 1.0, ce qui ne peut être fait, car 95% des sites https ne fonctionneraient plus.

Donc, Mozilla ne patauge pas, puisque le navigateur est protégé. Seuls les plugins sont susceptibles d'être utilisés pour BEAST. Donc il faut désactiver tous les plugins inutiles. (Ce que l'on dit depuis longtemps).

[Modaquitaine]

Bonjour,
Ce ne serait pas une bonne nouvelle pour la communauté éducative scientifique : on ne compte plus les animations de sciences physiques et naturelles, ou de géométrie, qui sont sous Java !
Le plugin Java est alors indispensable !
Exemple de site institutionnel : http://micro.magnet.fsu.edu/primer/virtual/virtual.html riche en animations Java.
Il y a eu le procès Adobe Flash, il y a celui maintenant de Oracle Java.
Et nous, les utilisteurs, dans tout ça ?

[G_HZ]

Voilà l'exemple même d'un désinformation G_HZ. Ton message est bourré d'approximation.

Ce n'est pas moi qui l'ai écrit cet article, je n'ai fait que le véhiculer ...

[teoli2003]

Et nous, les utilisteurs, dans tout ça ?

Tu navigues avec Java coupé et tu l'actives (3 clics) au besoin. Puis tu le coupes.

[Modaquitaine]

Et nous, les utilisteurs, dans tout ça ?

Tu navigues avec Java coupé et tu l'actives (3 clics) au besoin. Puis tu le coupes.

Evidemment ! Mais ce n'est pas une solution en réseau où 1 salle informatique (collégiens, lycéens) est en train de travailler !!! D'autant plus que les droits sont très restreints, y compris sur les profils chargés de FF.
C'est là que le problème réside !
En 10 ans de pratique de salles informatiques en réseau d'établissement scolaire (jusqu'à 600 postes avec des utilisateurs interchangeables), jamais JAVA n'a provoqué de catastrophe sur les postes utilisateurs (les serveurs doivent être sécurisés de sorte que les sites à risque sont filtrés par exemple). !
Vraiment, les problèmes ne sont pas les mêmes suivant le type d'utilisateurs !! Java rend des services immenses dans le monde de l'éducation. Ne pas l'oublier.
Bien cordialement

[teoli2003]

Le problème reste Oracle. C'est bien joli d'utiliser Java, mais sans contrat avec Oracle, vous êtes à la merci de leur politique commerciae. S'ils n'ont pas intérêt à fermer les failles de sécurité, vous êtes dans la mouise.

Il est grand temps de commencer à migrer les applets Java vers le web.

[Modaquitaine]

Le problème reste Oracle. C'est bien joli d'utiliser Java, mais sans contrat avec Oracle, vous êtes à la merci de leur politique commerciae. S'ils n'ont pas intérêt à fermer les failles de sécurité, vous êtes dans la mouise.

Il est grand temps de commencer à migrer les applets Java vers le web.

Bonsoir,
Malheureusement, on est toujours à la merci de quelqu'un : Adobe pour flash, Oracle pour Java, etc... Il en est ainsi de tout : on ne vit pas dans des "processus isolés" les uns des autres dans une abbaye de Thélème de partage gratuit de savoirs "inoffensifs".
Il a fallu désinstaller OOo pour Libre Office et demain, ce sera encore autre chose.
Non, cela ne tient pas ; Oracle "colmatera" ses failles de sécurité mais le "zéro défaut" est un mythe, au même titre que la sûreté des centrales nucléaires.
Des risques partagés mais, n'exagérons rien, qui n'ont tué personne (Java) ce qui relativise les "dangers" terribles que l'on court avec ce Java si peu "sécurisé".
Victimes de Java, faites-vous connaître !
Bien cordialement

[teoli2003]

Ben c'est un choix que tu fais. Tu choisis une technologie propriétaire, contrôlée par une seule société capitaliste au possible. Faut pas te plaindre ensuite que cette société t'entube. Choisir de baser des heures et des heures de travail sur le bon vouloir d'une seule société, c'est un risque gigantesque.

Même si j'ai déjà utilisé du Java, j'ai jamais basé mon travail uniquement là-dessus. Idem avec XUL: j'ai utilisé pour des trucs ponctuels, mais j'ai jamais utilisé pour basé tout mon business dessus. Bien trop risqué.

Être client captif d'une société c'est jamais une bonne chose.

[scoobidiver]

Choisir de baser des heures et des heures de travail sur le bon vouloir d'une seule société, c'est un risque gigantesque.

Si on suit cette logique, il faut que les 89% d'utilisateurs de Windows et 10% d'utilisateurs de Mac OS X migrent vers Linux.
L'important n'est pas la technologie propriétaire, surtout quand la distribution est gratuite, c'est la pérennité du produit.

[teoli2003]

Choisir de baser des heures et des heures de travail sur le bon vouloir d'une seule société, c'est un risque gigantesque.

Si on suit cette logique, il faut que les 89% d'utilisateurs de Windows et 10% d'utilisateurs de Mac OS X migrent vers Linux.
L'important n'est pas la technologie propriétaire, surtout quand la distribution est gratuite, c'est la pérennité du produit.

Ton raisonnement est complètement foireux, mais oui, c'est la pérennité du produit. Et lorsque c'est propriétaire, elle n'est jamais assurée sans clause contractuelle particulière. C'est une condition nécessaire mais pas suffisante (c'est pas parce que c'est ouvert que c'est garanti non plus)

J'ai négocié avec des sociétés pour ajouter qu'en cas de faillite, le code source de leurs bibliothèques nous soit donné, sans quoi nous n'utilisions pas leurs produits (et le code était déposé chez un tiers).

Tout ça pour dire que si Java est un problème de sécurité, il faut le bloquer au plus vite et sans état d'âme. Ceux qui l'utilisent n'auront qu'à l'activer. Et tout nouveau développement sur le web ne doit plus utiliser Java, il n'a pas d'avenir là.