Firefox 36 est désormais compatible avec le HTTP/2

Firefox 36 est désormais compatible avec le HTTP/2

Comme vont l'être tous les navigateurs prochainement

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

25/02/2015 2 minutes
87

Firefox 36 est désormais compatible avec le HTTP/2

Mozilla vient de publier la version 36 de son navigateur Firefox. La plus grosse nouveauté est clairement l’implémentation du protocole HTTP/2, tout juste finalisé. La plupart des autres améliorations concernent les développeurs, mais des changements sont à noter également du côté de la sécurité.

Firefox 36 inaugure donc le support officiel du HTTP/2. Même si ce dernier n’est pas encore à proprement parler un standard (ce n’est pas un document RFC), ses spécifications sont quand même finalisées, laissant libres les éditeurs de navigateurs d’en implémenter les mécanismes, basés en bonne partie sur le protocole de SPDY de Google. Notez que ce dernier sera d’ailleurs abandonné, Mountain View ayant expliqué récemment qu’il n’avait plus lieu d’être.

L’intégration du HTTP/2 n’est dans l’absolu pas une urgence puisqu’il faut encore que le protocole soit pris en charge par tous les acteurs, y compris par les sites web. Mozilla envoie cependant un signal fort pour indiquer que son navigateur est prêt. Rappelons tout de même que l’arrivée de HTTP/2 dans Chrome est imminente et que les deux prochains navigateurs de Microsoft (Internet Explorer « 12 » et Spartan) le gèreront également.

Firefox 36 ne propose cependant que peu de nouveautés visibles pour l’utilisateur. La seule fonctionnalité à évoluer est la page Nouvel Onglet, dont les vignettes peuvent maintenant être synchronisées via le compte Firefox, si l’utilisateur en possède un.

Voici une liste des autres changements notables dans cette version 36 :

  • L’envoi des rapports de plantages s’affichera avant que Firefox ne ferme complètement
  • Les certificats possédant des clés RSA 1024 bits ne sont plus acceptés
  • Plusieurs améliorations dans le support des CSS et d’ECMAScript 6
  • 20 failles de sécurité corrigées, dont 3 critiques
  • Des changements dans la compatibilité de certaines extensions

Les notes complètes de version peuvent être consultées depuis cette page.

Comme d’habitude, la nouvelle mouture peut être téléchargée directement depuis Firefox via les mises à jour intégrées. Ceux qui souhaitent récupérer l’installeur pourront le faire depuis l’un des liens ci-dessous :

87

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (87)


Super. Il manque plus que des serveurs HTTP/2 maintenant…


et quel est le serveur qui est compatible HTTP/2, parce que sur APACHE j’ai rien vue et sous Windows encore moins.


Et pourtant (cf wikipedia : )



Support





  • IIS supports HTTP/2 in Windows 10

  • OpenLiteSpeed 1.3.7 and 1.4.4 support HTTP/2 draft 16.




Et , pis bon, le gain pour l’utilisateur n’est pas si important …franchement.



Tant que nous verrons les pubs (flash et consorts) s’afficher et s’animer avant la page que tu veux regarder ….


Un module Apache est en cour d’écriture.

Et la version de IIS de Windows 10 (Windows Server 2015 ?) le support, d’après Wikipedia.



Ah oui, clairement, quel grosse merde flash, je paierais ma tournée quand ce truc sera mort.&nbsp;<img data-src=" />








Papa Panda a écrit :



Et , pis bon, le gain pour l’utilisateur n’est pas si important …franchement.



Tant que nous verrons les pubs (flash et consorts) s’afficher et s’animer avant la page que tu veux regarder ….





tu en sais quoi au juste que le gain n’est pas si important?

des pubs sur internet? ou ca?



Ouais enfin t’oublies qu’avant le flash y’avais rien de léger, interopérable et réactif.



Real Player&nbsp; <img data-src=" />&nbsp; Windows Media Player uniquement sur IE 5 et 6 <img data-src=" />&nbsp; <img data-src=" />, Java qui a essayé et s’est crouté totale <img data-src=" /> <img data-src=" /> <img data-src=" /> et DivX avec son plug in qui avait une compréhension de vidéo sur un PC&nbsp; <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /> …. <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Bref en 2003 Flash Player c’était l’avenir, Duke Nukem dans Firefox , des vidéos quasi instantané sur une nouvelle plateforme Youtube.



Alors oui le HTML5 est mieux a présent, mais a l’époque et pendant presque 10 ans c’était le désert.








Papa Panda a écrit :



Et , pis bon, le gain pour l’utilisateur n’est pas si important …franchement.



Tant que nous verrons les pubs (flash et consorts) s’afficher et s’animer avant la page que tu veux regarder ….





Ça c’est au prog de le prendre en compte.

Charger les images, le javascript&nbsp; et même le CSS en dernier , c’est déjà un bon début

Quand tu te retrouve à Pétaouchnok les bains sur un vieux tél et une connexion pourri, juste le HTML suffirait parfois :).









jeje07 a écrit :



des pubs sur internet? ou ca?







Dans les articles. <img data-src=" />









jamesdu75 a écrit :



Ouais enfin t’oublies qu’avant le flash y’avais rien de léger, interopérable et réactif.



Real Player&nbsp; <img data-src=" />&nbsp; Windows Media Player uniquement sur IE 5 et 6 <img data-src=" />&nbsp; <img data-src=" />, Java qui a essayé et s’est crouté totale <img data-src=" /> <img data-src=" /> <img data-src=" /> et DivX avec son plug in qui avait une compréhension de vidéo sur un PC&nbsp; <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /> …. <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Bref en 2003 Flash Player c’était l’avenir, Duke Nukem dans Firefox , des vidéos quasi instantané sur une nouvelle plateforme Youtube.



Alors oui le HTML5 est mieux a présent, mais a l’époque et pendant presque 10 ans c’était le désert.





Je ne me rappelle plus exactement, mais il me semble que sur Mac, on n’avait pas de flash et ça marchait très bien sans sur le web.



[quote=&quothttp://en.wikipedia.org/wiki/HTTP/2”]Goals[edit]

The working group charter mentions several goals and issues of concern:[3]



Negotiation mechanism that allows clients and servers to elect to use HTTP 1.1, 2.0, or potentially other non-HTTP protocols.

Maintain high-level compatibility with HTTP 1.1 (for example with methods, status codes, and URIs, and most header fields)

Decrease latency to improve page load speed in web browsers by considering:

Data compression of HTTP headers

Server push technologies

Fixing the head-of-line blocking problem in HTTP 1

Loading page elements in parallel over a single TCP connection

Support common existing use cases of HTTP, such as desktop web browsers, mobile web browsers, web APIs, web servers at various scales, proxy servers, reverse proxy servers, firewalls, and content delivery networks[/quote]





Si le nouveau standard va sans aucun doute rendre la navigation Internet plus fluide, le gain de performance n’est pas quantifié avec précision. La seule indication à laquelle on peut se référer est l’amélioration de 55 % de la vitesse de chargement des pages Web que Google dit avoir obtenu avec le SPDY

voilà la seule chose que nous ayons …(et encore là c’est avec le spdy)



Il n’y a rien sur le réel gain apporté avec le http/2 et encore, c’est plus les échanges avec un serveur que cela apporte qque chose, donc cela servira plus aux serveurs qu’à nous ,j’en suis sûr.





Sinon oui, lorsque tu charge une page internet, tu vois tjs les cadres et leur contenu des pubs avant même le texte de ton lien chargé …

Même si , certaines extensions me corrigent ce pb ,perso <img data-src=" />

mais sur l’exploreur de mon tél , j’ai l’impression de revenir 20 ans en arrière… les pubs flash (entre autres) s’affichent avant la page voulu …


“Les certificats possédant des clés RSA 1024 bits ne sont plus acceptés”

&nbsp;

ça veut dire quoi ? Que cette version est finalement moins sécurisée ?&nbsp;<img data-src=" />








Fantassin a écrit :



“Les certificats possédant des clés RSA 1024 bits ne sont plus acceptés”

&nbsp;

ça veut dire quoi ? Que cette version est finalement moins sécurisée ?&nbsp;<img data-src=" />





C’est Mega qui est chiffré ainsi non ?



Ca fait déjà un bon moment que les clés de 1024 bits en RSA sont considérées comme légères. Il est préférable de monter à 2048 bits.


salut tout le monde



Perso avec ette derniere version, il m’est impossible de lire les vidéos sur jeuxvideo.com par exemple, donc obligé de revenir à l’ancienne version….








Fantassin a écrit :



“Les certificats possédant des clés RSA 1024 bits ne sont plus acceptés”

 

ça veut dire quoi ? Que cette version est finalement moins sécurisée ? <img data-src=" />







Non elle est davantage sécurisée : clés RSA 2048 bits minimum.









kanesectore a écrit :



salut tout le monde



Perso avec ette derniere version, il m’est impossible de lire les vidéos sur jeuxvideo.com par exemple, donc obligé de revenir à l’ancienne version….





pas de problème pour moi, les vidéos fonctionnent



Rendez vous dans quelques siècles pour l’obligation des clés 4096 bits <img data-src=" />


j’ai aussi un ami qui me le confirme…..sans doute un module complémentaire qui fout la m








kanesectore a écrit :



j’ai aussi un ami qui me le confirme…..sans doute un module complémentaire qui fout la m





essayes de vider le cache.









kras a écrit :



Je sens la différence, ça va nettement plus vite.





La puissance de l’effet placebo&nbsp;<img data-src=" />









John Shaft a écrit :



Rendez vous dans quelques siècles pour l’obligation des clés 4096 bits <img data-src=" />







Quelques siècles ? Tu es optimiste (ou pessimiste, c’est selon).



Cracker une clé RSA 2048 bits prend plutôt de l’ordre du million de milliards d’années. Même en parallélisant sur des milliers de CPU les plus rapides du monde, et même si la puissance des CPU est multipliée par 1000 dans les 100 prochaines années, ça reste plusieurs milliards d’années <img data-src=" />



sauf si on trouve comment diminuer drastiquement le temps nécessaire pour craquer une clé : aka une faille dans l’algorithme ou son implémentation.








jeje07 a écrit :



essayes de vider le cache.





Je confirme, c’est bien un module qui mettait le bazar, plus précisément celui de IDM (version 7.3.93) donc désactivé et problème reglé

par contre je vois pas à quoi il servait….vu que mes dl fonctionne toujours comme d’habitude









Konrad a écrit :



Quelques siècles ? Tu es optimiste (ou pessimiste, c’est selon).







Mes siècles n’ont pas la même durée (oui ma vitesse est élevée) <img data-src=" />







geekounet85 a écrit :



sauf si on trouve comment diminuer drastiquement le temps nécessaire pour craquer une clé : aka une faille dans l’algorithme ou son implémentation.







Dans l’algo nan, RSA est fiable (c’est assez bête comme méthode). Dans l’implémentation, c’est un autre problème. Surtout que pour certaines choses (type générateur de nombres pseudo-aléatoires), faut quand même le niveau en math kivabien ™. Perso, je serai la NSA, c’est par ces périphéries que je passerai <img data-src=" />









kanesectore a écrit :



Je confirme, c’est bien un module qui mettait le bazar, plus précisément celui de IDM (version 7.3.93) donc désactivé et problème reglé

par contre je vois pas à quoi il servait….vu que mes dl fonctionne toujours comme d’habitude





je ne sais pas ou tu as téléchargé ce module de daube, mais je doute que ce soit sur le site de firefox.

les modules se téléchargent uniquement sur le site de firefox, et encore il faut être prudent…..

si on télécharge n’importe quoi n’importe ou, faut pas s’étonner d’avoir des problèmes









Papa Panda a écrit :



Et , pis bon, le gain pour l’utilisateur n’est pas si important …franchement.



Tant que nous verrons les pubs (flash et consorts) s’afficher et s’animer avant la page que tu veux regarder ….





Tu l’as regardé en détails cette version 2 ? On manque encore de benchmarks bien sûr, mais le protocole offre pas mal de solutions pour améliorer l’existant. Entre lemultiplexage, la fin du head-of-line blocking, la compression des headers, la gestion des priorités/dépendances, on devrait obtenir des requêtes plus compactes et un rendu plus réactif pour l’utilisateur (et j’ai même pas fini de lire la “spec”). Ca devrait logiquement se traduire par des perfs réelles et ressenties améliorées.



Pour ceux que ça intéresse:http://daniel.haxx.se/http2/http2-v1.9.pdf



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



La NSA ne t’as pas attendu pour prendre cette voie .. :p


Faut que j’arrête de traîner avec des spécialistes de la théorie des nombres moi <img data-src=" />


Bon, et ce electrolysis, il arrive quand ?








NXi a écrit :



Les certificats possédant des clés RSA 1024 bits ne sont plus acceptés





Euh … Il ne supporte plus les clefs de grande taille ? Ou j’ai mal compris ?



Edit &gt; OK j’avais pas lu la suite. Donc 2048+ supporté et tout ce qui est inférieur rejeté (bonne chose dans ce cas).









John Shaft a écrit :



Dans l’algo nan, RSA est fiable (c’est assez bête comme méthode).





Oui et non, la méthode on la connait déjà, on ne sait juste pas encore la mettre en pratique. Il n’est pas impossible que ça devienne possible dans le siècle à venir : Algorithme de Shor

Mais là, évidement, passer à 4096 bits serait inutile…



Oui <img data-src=" />



Ma pensée était hors algo quantique où là ça serait effectivement la foire à la saucisse <img data-src=" />


Concrètement on doit faire quoi sur son site pour qu’il passe HTTP/2 ?

Ca modifie genre les appels ajax ? les appels vers webservice ?



Ou c’est seulement si on utilise du cryptage qu’il faut adapter son code ?



Ou autre chose encore ?








Koxinga22 a écrit :



Concrètement on doit faire quoi sur son site pour qu’il passe HTTP/2 ?

Ca modifie genre les appels ajax ? les appels vers webservice ?



Ou c’est seulement si on utilise du cryptage qu’il faut adapter son code ?



Ou autre chose encore ?





Il suffit que le serveur web qui héberge le site implémente le protocole. Après ce que ça va changer dans les habitudes (inlining, domain sharding, etc) ça reste à voir. Mais si je comprend bien ça rend caduques pas mal de stratégies utilisées depuis des années pour améliorer les perfs.



Google est déjà compatible !



<img data-src=" />



Sinon avec SPDY HTTP/2 qui est un module Firefox ça te rajoutera un petit éclair dans la barre d’adresse qui te dira si le site ou en partie est en SPDY ou en HTTP/2.



La couleur de l’éclair changera, bleu pour HTTP/2, vert pour SPDY.



<img data-src=" />



<img data-src=" />


Cyberfox passe à la 36 aussi, ils se mettent à jour rapidement depuis quelques temps.








John Shaft a écrit :



là ça serait effectivement la foire à la saucisse <img data-src=" />





Je ne sais même pas s’il existe un algo de chiffrement à clé publique qui ne se base pas sur la difficulté à factoriser des grands nombres. Foire à la saucisse semble même plutôt optimiste.









Bleuarff a écrit :



Il suffit que le serveur web qui héberge le site implémente le protocole. Après ce que ça va changer dans les habitudes (inlining, domain sharding, etc) ça reste à voir. Mais si je comprend bien ça rend caduques pas mal de stratégies utilisées depuis des années pour améliorer les perfs.





Hmm … très bien très bien.

Donc si l’on héberge pas soi-même, rien à faire à part attendre la prise en charge.



Pour les optimisations caduques je trouve ça plutôt bien, ça va remettre tout le monde à niveau. Je fais confiance aux plus acharnées pour trouver de nouvelles bidouilles.



Y a pas d’algos quantiques de chiffrement ?



Et sinon, dans mon langage, la foire à la saucisse, c’est déjà du niveau du final de Braindead <img data-src=" />








kras a écrit :



Je sens la différence, ça va nettement plus vite.







Le pire c’est que j’ai ris à ton commentaire durant 15 bonnes secondes <img data-src=" />



Merci pour le lien <img data-src=" />


MSE semble clairement prendre pas mal de ressource en moment, j’ai l’impression que c’est passé en 2nd plan.

Il y a aussi un chantier CSS pour le rendre logique (écriture verticale) qui prend aussi pas mal de ressources. Après, je n’ai pas une vrai vision d’ensemble, mais vu le nombre de bugs à ce propos sur central.








Koxinga22 a écrit :



Hmm … très bien très bien.

Donc si l’on héberge pas soi-même, rien à faire à part attendre la prise en charge.



Pour les optimisations caduques je trouve ça plutôt bien, ça va remettre tout le monde à niveau. Je fais confiance aux plus acharnées pour trouver de nouvelles bidouilles.





Normalement oui. Après il y aura du coup peut être d’autres “bidouilles/optimisations” pour le HTTP/2.



Ouais mais windows 10 n’est pas encore sorti et la version serveur encore moins…

Et puis IIS ne peut que suivre un (ancien) draft et pas la RFC qui est sorti y’a 2j…


C’est un peu pareil pour Firefox… ou alors il y a eu de patch récent sur Beta le concernant.








geekounet85 a écrit :



sauf si on trouve comment diminuer drastiquement le temps nécessaire pour craquer une clé : aka une faille dans l’algorithme ou son implémentation.







Je pense que l’algorithme est assez fiable, je pencherais plutôt pour des problèmes dans une implémentation, ou une entité qui aurait une «master key» (NSA?). Là forcément, la sécurité tombe à zéro…



Pour invalider complètement les approches de ce type, il n’y a que l’ordinateur quantique (qui sera capable de déchiffrer une clé 2048 bits ou 4096 bits en quelques fractions de seconde). Mais ce type d’ordinateur reste au stade théorique pour le moment.



Il y avait pas une histoire de SME supporté à partir de la 36, pour permettre notamment la lecture des vidéos 60fps sur Youtube (ce que Chrome fait depuis 3 mois)? C’est en place?








Papa Panda a écrit :



Il n’y a rien sur le réel gain apporté avec le http/2 et encore, c’est plus les échanges avec un serveur que cela apporte qque chose, donc cela servira plus aux serveurs qu’à nous ,j’en suis sûr.







Le gain de qq ms pour afficher une page sera tres peu perceptible par les utilisateurs, c’est une evidence. Mais l’interet est clairement du coté des hebergeurs et des fournisseurs de services web.

Imagine un gain de 10% de perfs a l’echelle de Google, ce sont des dizaines de milliers de serveurs en moins et des centaines de GB/s libérés.



Si on peut ralentir un tout petit peu la croissance des datacenters ou leur consommation ne serait ce que pendant qq mois grace a une techno de ce genre, ce sont des volumes d’energie considerables qui seront economisés.



A l’echelle d’un utilisateur, ca n’aura pas beaucoup d’utilité mais d’un autre coté, ca ne changera pas non plus ses habitudes. Par contre, coté serveurs, la difference sera considerable.



@konrad @geekounet85 @JohnShaft Il y a bien plus simple que tout ça, s’introduire via une faille dans les servers possedant les cléfs privées et déchiffrer toutes les communications ensuite … <img data-src=" />


Sinon Twitter a déjà implémenté le HTTPS/2 sur ses servers. Mes connexions via FF36 utilisent bien le nouveau protocole.



P.S.: Impossible d’éditer mon commentaire du dessus.



&nbsp;








jamesdu75 a écrit :



Ouais enfin t’oublies qu’avant le flash y’avais rien de léger, interopérable et réactif.



Real Player&nbsp; <img data-src=" />&nbsp; Windows Media Player uniquement sur IE 5 et 6 <img data-src=" />&nbsp; <img data-src=" />, Java qui a essayé et s’est crouté totale <img data-src=" /> <img data-src=" /> <img data-src=" /> et DivX avec son plug in qui avait une compréhension de vidéo sur un PC&nbsp; <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /> …. <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



Bref en 2003 Flash Player c’était l’avenir, Duke Nukem dans Firefox , des vidéos quasi instantané sur une nouvelle plateforme Youtube.



Alors oui le HTML5 est mieux a présent, mais a l’époque et pendant presque 10 ans c’était le désert.





Flash léger…qu’est-ce qu’il faut pas lire. <img data-src=" />



Plus simple, tu sors un logiciel au code dégelasse et bourré de failles. Tu l’appelles OpenSSL et tu fais en sorte qu’il soit majoritairement utilisé dans le chiffrement (génération de clés INcluses) (demi-)<img data-src=" /> <img data-src=" />


Et interopérable <img data-src=" />


et à l’époque et pendant presque 10 ans on s’est fait chier.

ça a été rigolo quoi ? 1 an ? 2 an ?



Va faire du Flash sur une Debian Sarge, on s’est éclaté !


Maintenant que tu le dis, ça semble est encore mieux que la crypto classique : Cryptographie quantique (par contre dans l’article mentionné, je ne vois pas comment on se protège d’un man in the middle)

Après comme ça nécessite de tout recâbler internet en quantique-compatible, ça risque d’arriver après que la NSA ait son ordinateur quantique à elle toute seule.


Et moi je te trouve plutôt pessimiste sur la puissance des processeurs.



On a en gros multiplié la puissance par 2 millions en moins 50 ans.



Même en supposant qu’on s’éloigne de plus en plus de la loi de Moore, il suffit de multiplier la puissance par 2 tous les 10 ans pour multiplier la puissance par 1000 en 100 ans.


C’etait un complement avant tout :)



Nous ne sommes pas les seuls a nous lire :)


Au dela de ca, il a raison en disant que Flash a comblé un manque a une epoque et c’est vrai…

Flash a tous les defauts du monde mais il a ete là au bon moment.



Aujourd’hui, on s’en est (enfin) debarrassé, merci bien








Papa Panda a écrit :



Certes, c’est pas faux <img data-src=" />





C’est quel mot que tu comprends pas ? <img data-src=" />









Lawliet a écrit :



Bon, et ce electrolysis, il arrive quand ?





Tu peux le tester sur les versions Nightly pour aider Mozilla



La protection contre le MIM est liée au principe de non clonage référencé dans l’article.



J’essaie de simplifier, j’espère ne pas dire de c…ie:

&nbsp;

La physique quantique sait que non-seulement toute mesure perturbe la grandeur mesurée, mais que si essaie de ne pas en tenir compte on finira par se planter dans ses déductions.

Par contre, on peut s’arranger pour envoyer des données telles que toute perturbation entrainée par une mesure soit immanquable.



Donc on s’arrange pour pouvoir vérifier que les données qui servent à la confidentialité de l’échange n’ont pas été observées (donc mesurées) en cours de route.

&nbsp;


Non. Le non clonage empêche à Eve de se mettre au milieu et d’écouter ce qui passe sans le modifier.

Par contre, rien n’empêche Eve de se mettre au milieu, de répondre à Alice en prétendant être Bob, et de transmettre une autre clé à Bob en prétendant être Alice. Bref d’établir deux canaux sécurisés, un avec Alice, et un avec Bob, tout en faisant croire à chacun qu’il y a un seul canal.

Ce qui est précisément ce qu’on appelle un man in the middle.








Amabaka a écrit :



Et moi je te trouve plutôt pessimiste sur la puissance des processeurs.



On a en gros multiplié la puissance par 2 millions en moins 50 ans.



Même en supposant qu’on s’éloigne de plus en plus de la loi de Moore, il suffit de multiplier la puissance par 2 tous les 10 ans pour multiplier la puissance par 1000 en 100 ans.







La loi de Moore ne dit rien sur la puissance des CPU…



La loi de Moore prédit que le nombre de transistors par unité de surface double environ tous les deux ans. Malgré les difficultés techniques, cette prédiction est encore relativement suivie aujourd’hui.



En revanche, la puissance des CPU n’est pas proportionnelle au nombre de transistors. On est passé à des CPU qui ont 2, 4, 8 cœurs, et qui sont donc capables de gérer davantage de tâches simultanément, des tâches plus complexes, etc. Mais grosso modo, chaque core n’est pas plus efficace puisque les fréquences n’augmentent plus de façon aussi significative. Et malheureusement, un processeur Dual Core à 1 GHz n’offre pas autant de puissance qu’un processeur mono-core à 2 GHz.



Jette un œil à ce graphe par exemple : la loi de Moore est bien respectée (en vert : densité de transistors), en revanche depuis 2005 la fréquence des CPU (ou de chaque core) a atteint un plateau, situé autour de 4 GHz.



Alors, même si la loi de Moore continuait encore pendant 100 ans (ce qui est physiquement impossible, on va rapidement se confronter aux échelles de l’atome), la puissance brute des CPU n’en fera pas autant. Le meilleur moyen de continuer de gagner en puissance sera de paralléliser les applications, et de passer à des CPU qui ont 8 core, puis 16, 32…



Même avec de telles machines et des milliers de CPU, il restera difficile de diminuer le temps de cassage d’un chiffrement RSA 2048 bits en-dessous du milliard d’années.









Konrad a écrit :



en revanche depuis 2005 la fréquence des CPU (ou de chaque core) a atteint un plateau, situé autour de 4 GHz.







Et dire qu’avec NetBurst, Intel nous prédisait des fréquences de 10 Ghz <img data-src=" />









Zerdligham a écrit :



Je ne sais même pas s’il existe un algo de chiffrement à clé publique qui ne se base pas sur la difficulté à factoriser des grands nombres. Foire à la saucisse semble même plutôt optimiste.





Courbes elliptiques

Logarithme discret (ElGamal, Diffie-Hellman)

&nbsp;





John Shaft a écrit :



Dans l’algo nan, RSA est fiable (c’est assez bête comme méthode).





L’algorithme RSA est mathématiquement fiable. Mais les suspicions autour de l’implication de la NSA dans la société RSA et la possibilité que certaines implémentations aient été vérolées ont poussés la communauté infosec à se méfier. C’est d’ailleurs pour cela que l’EITF a annoncé l’arrêt du spport de RSA pour la séquence d’échange de clé dans TLSv1.3:&nbsp;http://www.theinquirer.net/inquirer/news/2343117/ietf-drops-rsa-key-transport-fr…

&nbsp;



Oui et comme on est dans une news Mozilla/Firefox, il serait temps que ça sorte les doigts et qu’ils implémentent au moins ChaCha20-Poly1305 histoire de se passer aussi de AES sur certaines plateformes, notamment sur les mobiles (Android) où il existe une version mobile de Firefox.



Il serait bon aussi d’implémenter à terme Curve25519 (Ed25519) mais je ne pense pas qu’il soit encore suffisamment finalisé pour être intégré complétement.


Haaan, j’avais pas du tout suivi l’actu sur TLS 1.3. C’est une bonne nouvelle ça. Du coup, je suppose que ça veut dire que cette version de TLS fournira au minimum de la forward secrecy ?


“C’est côtelette que vous comprenez pas ? “








Glyphe a écrit :



Oui et comme on est dans une news Mozilla/Firefox, il serait temps que ça sorte les doigts et qu’ils implémentent au moins ChaCha20-Poly1305 histoire de se passer aussi de AES sur certaines plateformes, notamment sur les mobiles (Android) où il existe une version mobile de Firefox.



Il serait bon aussi d'implémenter à terme Curve25519 (Ed25519) mais je ne pense pas qu'il soit encore suffisamment finalisé pour être intégré complètement.







https://bugzilla.mozilla.org/show_bug.cgi?id=917571

https://bugzilla.mozilla.org/show_bug.cgi?id=943639



La dernière technologie semble en plein chantier:http://tools.ietf.org/html/rfc5639



Media Source Extensions (MSE) a été déprogrammé de la version 36.



Il y a 2 semaines youtube était complètement inutilisable alors que cela fonctionnait courant janvier.

Si tu veux suivre la mise en place de la technologie:

https://bugzilla.mozilla.org/show_bug.cgi?id=778617



Il est possible que dans un premier temps, seul Youtube et les vidéos en mp4 en bénéficie:

https://bugzilla.mozilla.org/show_bug.cgi?id=1097436








John Shaft a écrit :



Et dire qu’avec NetBurst, Intel nous prédisait des fréquences de 10 Ghz <img data-src=" />







Oui enfin ils promettaient qu’Internet serait plus rapide si tu achetais un Pentium III aussi, donc bon… <img data-src=" />



Je suis au courant pour les fréquences, le nombre de cores, les limites physiques, …

Seulement, il reste une question: en quoi ce n’est pas une augmentation de la puissance brut (même si elle

est plus difficile à exploiter en travaillant avec plusieurs cores) ?

&nbsp;

Je me doute que c’est un raccourci un peu rapide “nombre transitors” &lt;=&gt; “puissance”. Mais j’imagine que c’est des courbes qui suivent à peu près la même évolution.

Je ne m’y connais pas là dessus et je me trompe peut-être, mais tu ne fournis pas d’explications sur ce point.



Et pour revenir aux clés RSA, je voulais simplement souligner que si on continue d’augmenter en puissance, même à un rythme beaucoup plus faible que ces 40 dernières années, les clés RSA 2048 bits n’ont que quelques centaines d’années devant elles.

Est ce qu’on va pouvoir contourner/dépasser les limites de la technologie actuelle, c’est une autre question.


Oui toutes les suites ECC ne sont clairement pas encore finalisées mais bon ChaCha20-Ply1305 est déjà intégré dans Chrome depuis un certains temps même si le draft est encore en cours de dev une certaine stabilité dans ces deux primitives est quand même déjà largement éprouvée.&nbsp;<img data-src=" />


Un type qui n’a jamais utilisé d’applet java ? De plus il est possible de faire des trucs léger en Flash…. D’ailleurs, pour l’instant SVG est plus lourd que Flash pour ce qui est vectoriel. Il y a 10 ans, je ne trouvais pas le flash spécialement lourd… surtout à côté du JS.








Amabaka a écrit :



Je suis au courant pour les fréquences, le nombre de cores, les limites physiques, …

Seulement, il reste une question: en quoi ce n’est pas une augmentation de la puissance brut (même si elle

est plus difficile à exploiter en travaillant avec plusieurs cores) ?







La «puissance brute» est principalement contrôlée par la fréquence, qui détermine le nombre d’opérations que le processeur va effectuer à chaque seconde. Par exemple 4 GHz ça veut dire 4 milliards d’opérations par seconde (bon je simplifie parce qu’en réalité tous les cycles ne sont pas forcément utilisés mais bon).



La plupart des applications sont conçues pour fonctionner sur un seul CPU (ou un seul core). Pour ces applications là, avoir plusieurs CPU ou des CPU multi-cœurs ne changera rien puisqu’elles sont incapables de les exploiter. La seule chose qui compte c’est la fréquence. Si la fréquence n’augmente plus, ces applications ne peuvent plus devenir plus rapide.



Un moyen de pallier à cela, c’est de paralléliser les applications, c’est-à-dire faire en sorte qu’elles puissent exploiter plusieurs cores. Il faut savoir que la parallélisation a un coût, dans deux sens du terme :







  • un coût en développement : ça prend du temps et ça coûte de l’argent de paralléliser un programme, et beaucoup de programmeurs font le choix de supporter 2 voire 4 cores parce que c’est plus simple à programmer. Du coup beaucoup d’applications sont incapables d’exploiter 8, 16 ou 1024 cores, elles sont limitées à 2 ou 4. Un exemple : les jeux vidéos, de plus en plus sont capables d’exploiter deux cores, certains sont capables d’en utiliser quatre, mais rares sont les jeux capables d’exploiter 6 cores ou plus. Il en va de même pour beaucoup d’applications.

  • un coût en temps lors de l’exécution du programme : la parallélisation va forcément ajouter du temps de communication entre les threads. En faisant tourner une application sur 2 cores au lieu d’un seul, elle ne sera pas 2 fois plus rapide, mais peut-être 1,95 fois plus rapide. Sur 4 CPU elle sera 3,8 fois plus rapide. Sur 8 CPU elle sera 7 fois plus rapide… et ainsi de suite. Ceci dépend de l’algorithme bien sûr. Pour des algorithmes de calcul intensif (optimisés par les meilleurs programmeurs), tourner sur 1024 CPU peut permettre de diviser le temps d’exécution par 500 ou 600, mais pas par 1024.







    Bref, la «puissance brute» n’est pas proportionnelle au nombre de CPU (ou de cores) qu’il y a sur ta machine. Passer d’un simple core à un Dual Core change la vie et se sent tout de suite ; mais quand on passe de 8 à 16 CPU, la puissance n’est pas doublée. Même si on imagine que dans 100 ans les ordinateurs auront des centaines, des milliers, ou soyons fous, des millions de CPU, ça ne diminuera pas pour autant le temps de calcul par un million, mais par beaucoup moins.



    Comme il faut des millions de milliards d’années pour décrypter une clé RSA 2048 bits avec un CPU moderne, avec un million de CPU il faudra toujours plusieurs milliards d’années.



     





    Amabaka a écrit :



    Je me doute que c’est un raccourci un peu rapide “nombre transitors” “puissance”. Mais j’imagine que c’est des courbes qui suivent à peu près la même évolution.







    Justement non, voir le graphe dont je parlais plus haut.









    Amabaka a écrit :



    Et pour revenir aux clés RSA, je voulais simplement souligner que si on continue d’augmenter en puissance, même à un rythme beaucoup plus faible que ces 40 dernières années, les clés RSA 2048 bits n’ont que quelques centaines d’années devant elles.







    Quelques centaines d’années ? Pourquoi ? Sur quoi tu bases ce chiffre ? Une impression, une intuition ? Ou tu as fait un calcul qui le montre ? Tu ne fournis pas d’explication sur ce point…









    Amabaka a écrit :



    Est ce qu’on va pouvoir contourner/dépasser les limites de la technologie actuelle, c’est une autre question.







    Si on arrive dans le futur à construire un véritable ordinateur quantique, alors toute l’approche des clés RSA sera rendue caduque, puisqu’un tel ordinateur ne fonctionne pas comme les ordinateurs actuels, et ne mettrait que quelques fractions de secondes à décrypter une clé 2048 bits.



    Mais pour l’instant l’ordinateur quantique n’est qu’une possibilité théorique.









Phenixy a écrit :



Il y avait pas une histoire de SME supporté à partir de la 36, pour permettre notamment la lecture des vidéos 60fps sur Youtube (ce que Chrome fait depuis 3 mois)? C’est en place?





Si je me trompe pas, c’était dans les nightly et donc dans la version 37 au minimum … mais ma mémoire étant ce qu’elle est, je suis pas certains ^^ Faudrait chercher dans les news récents (mais pas trop)









matroska a écrit :



Sinon avec SPDY HTTP/2 qui est un module Firefox ça te rajoutera un petit éclair dans la barre d’adresse qui te dira si le site ou en partie est en SPDY ou en HTTP/2.



La couleur de l’éclair changera, bleu pour HTTP/2, vert pour SPDY.





Bien sympa ce petit module, merci&nbsp;<img data-src=" />



Oui il y a pire que Flash en lourdeur.

Est-ce que ça fait de Flash un produit léger ?

Non, il est seulement moins lourd.


Je te dirais, ça dépends ce que tu fais avec. Ça reste moins lourd que HTML5 dans pas mal de cas… Le problème c’est qu’on s’en ait servis pour faire des trucs qui n’ont rien à avoir avec ce qui était prévu à la base. J’ai vu des animation SVG… ça donne pas franchement envie.








zefling a écrit :



Je te dirais, ça dépends ce que tu fais avec. Ça reste moins lourd que HTML5 dans pas mal de cas… Le problème c’est qu’on s’en ait servis pour faire des trucs qui n’ont rien à avoir avec ce qui était prévu à la base. J’ai vu des animation SVG… ça donne pas franchement envie.





C’est exactement ça. J’ai l’impression que beacoup ont oublié que flash à la base c’est pour faire de l’animation vectorielle, pas pour lire de la vidéo.

&nbsp;

Flash a des défauts : c’est propriétaire et souvent critiqué niveau sécurité, mais dans le domaine de l’animation vectoriel, il n’a aucune concurrence valable actuellement, que ce soit niveau légèreté ou fonctionnalité.

&nbsp;

Le HTML 5 c’est bien, très prometteur, mais on est encore loin d’atteindre les possibilités de flash dans le domaine de l’animation vectorielle…et surtout, les outils de dev actuels sont bien moins complets/efficaces que Flash (le logiciel , pas le plugin).



Le principe de non-clonage empêche non seulement d’écouter sans modifier, mais aussi d´intercepter et ré-émettre de manière indétectable.



&nbsp;Donc il empêche une attaque MiM lorsque le canal de communication a été établi correctement.



Il ne peut rien en effet contre le cas que tu décris.


dites vous n’avez pas de problème avec FF 36 lorsque vous passez le pc en veille ?



Quand je sors de veille, FF ne veut plus rien charger… et si je le ferme il reste en mémoire et est impossible à killer.



C’est ptet une extension mais ça va être lourdingue à tester vu qu’il faut à chaque fois que je reboote complètement le PC :(


Exactement, c’est le principal avantage et le gain n’est pas négligeable sur le plan de la sécurité.