Le 20/02/2013 à 00h 45

Allez, en rapport avec les commentaires :



http://i.imgur.com/3plzq.jpg

Le 18/02/2013 à 15h 52

sniperdc a écrit :



C’est bien cela le plus inquiétant visiblement Java a grossi tellement vite et visiblement sans corriger assez rapidement ses failles.



Avant Open Source sous Sun microsytem depuis son rachat par Oracle, Java semble de plus en plus perméable aux attaques avec injection de code arbitraire.







Toutes les failles corrigées récemment, avec une ou deux exceptions, datent de l’époque de Sun.



En fait, depuis quelques années, Java est devenu une cible des chercheurs de failles (black hat comme white hat) suite à la découverte et à la publication de plusieurs méthodes d’exploitation qui garantissent 100% de chances d’exécution de code pourvu qu’une faille soit trouvée : il suffit de trouver une faille dans le code trusté de la JRE.



Avant cette époque, la majorité des failles Java se trouvaient dans la partie native, donc plus difficiles à exploiter, et avec des taux de réussite bien moindres.

Le 18/02/2013 à 15h 40

Quelques éclaircissements car je n’ai pas interprété le post de facebook de la même manière sur tous les points :





Le mois dernier, plusieurs employés de Facebook ont navigué sur le site web d’un développeur. La version mobile du site était en fait contaminée par un malware.





Ce n’était pas la version mobile du site qui était contaminée, mais le site d’un développeur d’applis pour mobiles (c’est ce que je comprends du blog en tout cas, mais ce n’est pas très clair c’est vrai).





Le site lui-même contenait plusieurs méthodes pour détecter d’éventuelles failles à exploiter sur les machines des visiteurs.





Non, le site contenait un malware, tout simplement (probablement hébergé à l’insu du propriétaire du site).





Une fois l’une d’elles trouvée, le malware pouvait s’installer.





En fait, le malware utilisait une faille 0-day de Java pour s’installer. Je n’ai pas lu qu’il utilisait plusieurs vecteurs pour s’installer (de toute façon, une faille 0-day est généralement suffisante).





La cellule Sécurité de Facebook précisait en outre que les portables des employés étaient parfaitement à jour et utilisait un antivirus possédant les dernières définitions.





C’est ce qui me fait conclure que c’était bien une faille 0-day (corrigée depuis).

Le 16/02/2013 à 10h 14

Einstein-Rosen-Podolsky a écrit :



je pense être d’accord avec Xavier NIEL lorsque lors de sa conférence sur les nouveaux forfaits, il a affirmer que son entreprise n’avait pas d’actionnaires, contrairement aux autres FAI, ce qui pouvait lui permettre de baisser les prix!



Donc, voilà que les autres FAI virent les actionnaires, ou qu’ils mettent une limite à leurs revenus d’actionnaires.







Free est côté en bourse (c’est Iliad), si tu veux acheter des actions, tu peux le faire sans problème :)



Par contre, Niel étant l’actionnaire majoritaire, c’est lui qui décide de tout. Donc, quand on parle de “les actionnaires de Free”, en fait on parle de Niel, les autres possesseurs d’actions ne pouvant rien dire ni rien faire quand Niel prend une décision.

Le 15/02/2013 à 15h 52

Mihashi a écrit :



Avoir le code source (partiel en plus, de mémoire) de MS ne sert à rien, car rien ne prouve que c’est le même code qui a été compilé pour créer l’installateur ou les mises à jour utilisés (alors qu’avec du libre il suffit de compiler).







C’est faux, car qu’est-ce qui prouve que le compilateur est digne de confiance ?



Un papier de Thompson sur ce problème : http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

Le 15/02/2013 à 15h 43

Fueg a écrit :



un bout de l’astéroïde vient d’être retrouvé !

après les analyses, il semblerait qu’il y ait de la viande de cheval dedans " />







N’importe quoi, c’est du boeuf de roumanie.

Le 11/02/2013 à 15h 26

Drepanocytose a écrit :



Ok au temps pour moi, je me suis enflammé sur le “AUCUN”.

Ceci dit, ca n’enlève rien au fait que si faille il y a (volontaire : backdoor, ou involontaire : erreur) elle ne sera pas documenté, bien sûr…



Et dire ceci ne dit pas que l’opensource est vierge de tout défaut, bien au contraire. Les failles que tu cites et qui sont connues sont un bon exemple.



Mais je ne peux m’empêcher de me dire qu’un code public, que beaucoup de gens ont pu aller regarder (et sans avoir besoin de decompiler quoi que ce soit) sera plus fiable qu’un code, certes décompilable et avec les sources dispo (mais ca j’aimerais en être certain), mais qui n’aura été revu que par une poignée de gens, aussi experts soient-ils….







En fait, les faits montrent que le seul facteur qui joue vraiment, c’est la popularité d’un logiciel.



Le simple fait de rendre le code source disponible ne va pas attirer comme par magie des milliers de chercheurs en sécurité.



Les chercheurs en sécurité iront naturellement étudier les logiciels populaires, qu’ils soient libres ou non. Mais effectivement, s’ils sont libres, ils ont plus de chance encore d’attirer des chercheurs : on sait d’avance qu’on aura plus de facilité à étudier le soft. L’impact est difficile à quantifier par contre.



Quant à ta dernière phrase, je pense au contraire qu’une poignée de chercheurs en sécurité, missionnés pour auditer du code, seront bien plus efficaces qu’un millier de codeurs “classiques” : on ne trouve pas une faille par hasard, il faut connaître plein de techniques bas niveau, étudier le code à partir d’un certain angle, ce n’est pas si simple. Un exemple très concret : libpng, librairie pourtant beaucoup utilisée et analysée par des développeurs, a été auditée par un expert en sécurité de chez Google. Le gars a rapporté presque une dizaine de vulnérabilités :http://scary.beasts.org/security/CESA-2004-001.txt

Le 11/02/2013 à 14h 39

Drepanocytose a écrit :



Tu me vois venir gros comme une maison je pense : si MS avait l’idée de mettre un backdoor, il n’y aurait AUCUN (et j’insiste : AUCUN) moyen de s’en rendre compte.







Oui, bien sûr, d’ailleurs OllyDbg et IDA Pro n’existent pas, les décompileurs n’existent pas non plus, et d’ailleurs c’est pour ça que personne ne trouve jamais de failles dans les produits MS : car il n’y a AUCUN moyen d’analyser leur code.



Même sans désassembler ou décompiler du code, on peut utiliser WinPCap pour voir le trafic réseau, ou si vraiment on n’a pas confiance, on peut utiliser une passerelle sous linux qui logge tout le trafic.



Plein de chercheurs en sécurité passent tout leur temps à analyser des soft MS, donc tu peux insister sur “AUCUN” tant que tu veux, ça ne changera pas les faits : il est tout à fait possible de se rendre compte d’un backdoor dans windows (et je pense qu’il ne tiendrait pas 2 jours sans être trouvé, si on en ajoutait un).



PS : et je ne parle pas des backdoors dans des softs tels que unreal IRCd, pourtant logiciel libre. Je pourrais parler également du serveur RedHat qui a été hacké sans que RedHat s’en rende compte avant un certain temps. Kernel.Org a également été hacké et aurait pu distribuer des kernels vérolés… Debian et ses dérivés qui, pendant 2 ans, ont généré des clés RSA et DSA devinables. Bref.

Le 11/02/2013 à 14h 27

GruntZ a écrit :



J’ai simplifié en parlant de chiffrement; le travail portait sur beaucoup plus de choses, et l’intégration de GPG (probablement avec tout ou partie du code d’Enigmail) n’était qu’une partie.

http://adullact.net/plugins/mediawiki/wiki/milimail/index.php/Trustedbird_Projec…





Le plus gros problème, c’est qu’un code propriétaire, si bien foutu et documenté soit-il, reste SA propriété, et qu’il peut en faire ce qu’il veut, y compris :

• modifier l’API sans garantie de rétro-compatibilité (ton investissement en dèv est à jeter),
  


• l’abandonner avec ses bugs sans te livrer les sources (si ça ne lui rapporte pas assez, il passe à autre chose),
  


• ne développer une fonctionnalité que dans la version (payante) suivante (mais il te ferra un prix d’ami ;) )
  


• ne rendre cette nouvelle version disponible que sur SON nouvel OS (payant aussi).
  
  
  
  Et comme toutes ces actions, légales, sont bonnes pour son commerce, je doute qu’il se prive de les mettre en œuvre quand la pression de ses actionnaires se fera sentir.
  
  
  
  
  
  
  
  Je suis tout à fait d’accord, mais je vais ajouter quelques remarques :
  
  
  


• modifier l’API sans garantie de rétro-compatibilité (ton investissement en dèv est à jeter),
  
  
  
  
  
  
  
  1. On peut aussi rester sur une version où ça fonctionne.
     
  
  
  2. La même chose peut arriver avec un logiciel libre, et il faudra alors payer des devs pour maintenir un fork par exemple, pas simple.
     
     
     
     
     
  
  


• l’abandonner avec ses bugs sans te livrer les sources (si ça ne lui rapporte pas assez, il passe à autre chose),
  
  
  
  
  
  
  
  1. On peut rester sur la dernière version fournie
     
  
  
  2. La même chose peut arriver avec un logiciel libre, et il faudra alors payer des devs pour faire évoluer le logiciel mort, pas simple.
     
     
     
     
     
  
  


• ne développer une fonctionnalité que dans la version (payante) suivante (mais il te ferra un prix d’ami ;) )
  
  
  
  Oui, mais si tu veux une certaine feature, sur un logiciel libre, tu fais comment ? Il va falloir payer quelqu’un pour le faire, puis payer des gens pour maintenir un fork, ce n’est pas si simple.
  
  
  
  
  


• ne rendre cette nouvelle version disponible que sur SON nouvel OS (payant aussi).
  
  
  
  
  
  
  
  1. On peut aussi rester sur une version où ça fonctionne.
     
  
  
  2. La même chose peut arriver avec un logiciel libre, et il faudra alors payer des devs pour maintenir un fork par exemple, pas simple.
     
     
     
     
     
     Bref, souvent les défauts du logiciel propriétaire ont leurs pendants dans le libre. Tout n’est pas si simple et il faut factoriser tous ces éléments. Le logiciel propriétaire a aussi des avantages sur le libre, par exemple, on peut faire pression sur le fournisseur pour avoir une fonctionnalité développée, surtout si on est un gros client. Pour le libre, si les devs n’en veulent pas, il faudra payer quelqu’un pour le développer et pour maintenir un fork, chose pas rentable.
     
     
     
     L’important est de faire le choix en fonction de ses besoins, et de ne pas céder au chant des sirènes, d’un côté comme de l’autre, mais de savoir faire la part des choses et choisir en fonction des besoins réels.
  
  

Le 11/02/2013 à 14h 07

ff9098 a écrit :



Oui bien sur, le code dégueulasse est dans le LL et les API dans les logiciels privateurs







Typique des intégristes du libre ça (malheureusement) : faire dire aux autres ce qu’ils n’ont pas dit.



À aucun moment je n’ai dit quoi que ce soit qui se rapproche de ce que tu affirmes.



Sinon, des vrais arguements peut-être ?" />

" />

Le 11/02/2013 à 13h 50

GruntZ a écrit :



Le principe même des Logiciels Libres, c’est justement qu’on n’a pas à tout re-dévellopper, il suffit de compléter ou de modifier ce qui existe. C’est ce que la gendarmerie a fait avec Thunderbird pour la partie chiffrement des échanges.







Ce n’est pas exclusif aux logiciels libres : nombre de logiciels proposent une API qui permet de tout faire… D’ailleurs il est très simple d’interfacer Outlook avec GPG, il n’y a même rien besoin de développer car la solution existe déjà.



Je suis d’ailleurs à peu près sûr que c’est la même chose pour Thunderbird.



L’inverse est aussi vraie : ce n’est pas parce qu’un logiciel est libre, qu’il est simple d’y ajouter une fonctionnalité. Il vaut mieux un code fermé, et une belle API, qu’un code spaghetti dégueulasse où la simple compréhension du bloc qui nous intéresse nécessite 6 mois à temps plein, et où la moindre modification a des conséquences inattendues à l’autre bout du logiciel.





Voir aussi l’ADULLACT, dont le président, F. Ellie résume le problème d’une belle phrase : “L’argent public ne doit être dépensé qu’une fois pour une même chose.”





Il y a encore mieux : «Il ne sert à rien de réinventer la roue». Pourquoi dépenser de l’argent public pour re-déveloper une solution de chiffrement pour Thunderbird, alors qu’elle existe déjà ?

Le 11/02/2013 à 13h 30

Khalev a écrit :



Je sais, je plaisantais.



Mais moi ce qui me choque c’est que là on va filer de l’argent à Microsoft, pour qu’ils puissent continuer à développer leur produit, et donc qu’il soit encore plus performant, histoire qu’on puisse encore plus difficilement passer à la concurrence.







Mais c’est horrible" />



On va donner de l’argent à une entreprise pour un bien ou un service rendu ! Et les concurrents n’auront pas cet argent !



Alors que si on avait donné cet argent à Red Hat… Bon, ok, ce serait exactement la même chose, mais Red Hat c’est pas Microsoft, donc ça va !





Alors c’est gentil de dire que les produits concurrents ne correspondent pas à ce qu’on veut, mais à un moment si on veut éviter le “monopole Microsoft” il faut prendre le taureau par les cornes, regarder sérieusement toutes les alternatives possibles, choisir la plus prometteuse pour nos besoins et investir dedans (argent, main d’oeuvre, infra ou autre…). Et là c’est même pas une question de libre ou pas c’est d’avoir une solution qui correspond à nos besoins et qui assure notre indépendance.





Oui et donc, la solution qui correspond maintenant aux besoins c’est celle de Microsoft. C’est bien beau de dire qu’il y a une autre solution prometteuse, et qu’il faut investir dedans, mais ce n’est absolument pas le rôle du ministère.



Et pour assurer notre indépendance, le seul moyen c’est de développer tout en interne, ce qui n’est certainement pas faisable.

Le 11/02/2013 à 13h 17

coolspot a écrit :



Non pas avec le système de libre-échange. Tu verra jamais un produit chinois se conformer au règle écologique et sanitaire de l’UE par exemple.







Les sigles CE et RoHS sur tout ce qui est made in china, c’est pour faire joli ?



" />

Le 11/02/2013 à 12h 54

Drepanocytose a écrit :



Mauvaise formulation de ma part en parlant de manuel, mais c’était pour rebondir.

En opensource, en dernier recours tu as : le code !!!







Depuis quand le code est de la documentation ?

Lire le code en guise de documentation, c’est très mauvais, car :

• On ne comprend pas forcément l’intention du dev qui a écrit le code
  


• On peut supposer qu’une fonction fait telle ou telle chose, alors que c’est un simple effet de bord, et que ça changera dans le futur
  


• On peut interpréter un bug comme étant le comportement nominal
  


• On ne sait pas vraiment ce qui est l’API et ce qui est “privé”
  
  
  
  
  
  
  
  Il vaut mieux une doc succinte qui explique ce que doit faire une fonction, que de lire le code pour essayer d’en déduire ce qu’elle doit faire.
  
  
  
  En revanche, avoir le code permet de débugger plus facilement, c’est sûr.
  
  
  
  
  
  Sinon que tout chez MS soit documenté, c’est une plaisanterie…
  
  
  
  
  
  Oui, il y a bien quelques fonctions du kernel et même certainement de l’API win32 qui ne sont pas documentées, mais en général ce n’est pas sans raison, et on n’est jamais obligé de les utiliser.

Le 11/02/2013 à 12h 47

Drepanocytose a écrit :



Sinon pour ton “RTFM”, disons que l’avantage avec Linux et plus généralement l’opensource, c’est qu’il existe, déjà, le manuel !







Alors là, citation needed, hein, parce que l’énorme majorité des projets opensource, la doc c’est au grand maximum du doxygen sur un quart de l’API, et éventuellement des exemples sans explication.





Va demander à MS des détails sur certaines de leurs fonctions, on verra bien…





MicrosoftIl y a absolument TOUT dessus.



Donc, donne-moi tes exemples, sur les fonctions de l’API non détaillées et que MS ne veut pas documenter.

Le 11/02/2013 à 14h 43

WhiteAngel a écrit :



En quoi ce n’est pas moral?



Est-ce plus moral de laisser des propos incitant à la haine ?





En vertu de la liberté d’expression, on devrait avoir le droit de dire ce que l’on veut.

Le 08/02/2013 à 14h 17

Bien fait pour les webmasters qui remplissent leurs pages de scripts extérieurs.



Et après on s’étonne que les gens utilisent de plus en plus adblock… Qui permet de bloquer facilement tous les scripts pourris de facebook, twitter, google & co.

Le 08/02/2013 à 07h 51

Mouais, pour ceux qui y croient, n’oubliez pas qu’on n’a aucune nouvelle des Ubuntu TV, qui devaient arriver fin 2012 grand max selon Shuttleworth.

Le 04/02/2013 à 12h 50

IAmNotANumber a écrit :



Il avait même été démontré qu’une machine sous 98 plantait automatiquement au bout d’un certain temps de fonctionnement. Perfide, le journaliste de SVM avait précisé que ce bug ne se rencontrerait jamais en utilisation normale vu que de toutes façons personne n’avait jamais réussi à faire fonctionner un PC sous 98 aussi longtemps sans planter " />







Il me semble que c’était Windows 95, qui plantait quand le nombre de millisecondes depuis le démarrage du système débordait (overflow) et repassait à 0.



Stocké sur 32 bits, ce nombre ne pouvait dépasser 4294967296, ce qui donne 49,71 jours.



Mais à vérifier, je sors ça de tête et ça fait longtemps…

Le 04/02/2013 à 11h 04

JBrek a écrit :



La success story à l’état pur. Tous nos jeunes devraient aspirer à ce genre de réussite !

Chapeau Monsieur Persson.







Tout à fait, mais quand je vois ce genre d’articles, je me dis que notre pays est vraiment dans la merde.



Ça me fait vraiment peur de voir que tout ce que veut la majorité des jeunes diplômés (je fais partie de la minorité, heureusement) est une bonne planque où ils pourront ne rien foutre.

Le 01/02/2013 à 18h 36

erimas a écrit :



J’aurais souhaité une autre fin : Celle de Google qui aurait dé-référencé la presse (journaux connus) en ne laissant que le contenu de qualité gratuit et indépendant.



Le journalisme aujourd’hui est lamentable : Bourré de désinformation, prise de parti pour tel ou tel bord politique, souvent rempli de bêtises et de marronniers récurrents débiles ( Il y’a un topic très complet la dessus sur HFR " /> ) et ce à l’exception de quelques sites (dont PCI fait partie bien entendu pour l’informatique et autres blogs intéressants…).







Exact, tu oublies d’ajouter que toute la presse est financée par l’État à hauteur de centaines de millions d’euros, donc malheureusement pour avoir une presse indépendante il faut aller voir à l’étranger…

Le 01/02/2013 à 09h 52

Ph11 a écrit :



Mouais, bon, les reportages éco-socio-militants d’Arte…



Allez, je parie qu’il y avait des musiques un peu inquiétantes, des méchantes industries turbocapitalistes, accusées d’être la source de tous nos maux et que les solutions proposées sont l’intervention de l’état ?



Au fait :



1/ qui les faits ?

2/ qui sont interviewés ?

3/ les faits sont ils vérifiables ?

4/ quel est le message ?

5/ y-a-t-il débat ou juste une narration ?

6/ les interviews sont complets ou coupé selon le sens de l’auteur ?



N’oubliez pas qu’une photo montre ce que veut montrer le photographe, un reportage n’est pas une démonstration scientifique, mais l’utilisation de l’image pour convaincre l’auditeur d’un message à forte tendance politique. Bref, de la propagande. Si quelqu’un le fait, c’est qu’il a une raison de le faire.







Je ne peux qu’approuver ce message.

J’ajouterais :

7/ la présentation des faits est-elle agrémentée d’une poudre de “nous vous révélons ce que le gouvernement vous cache” ?

Le 29/01/2013 à 14h 54

sepas a écrit :



J’ai mis 30 secondes avant de réaliser que c’était un capot. J’ai cru que c’était un slip, du coup, je ne voyais pas le rapport " />







J’ai beau chercher en slip, en retournant l’image dans tous les sens, impossible.



Toi y en a " />" />" />

Le 25/01/2013 à 17h 52

darkbeast a écrit :



a quand les news sur les dièse-mots #unbonjuif gazouillé depuis une tablette tactile de chez pomme.







Arrête de massacrer notre magnifique langue française !! " />



On dit un mot-dièse !!



" />

Le 24/01/2013 à 19h 41

carbier a écrit :



Arbitraire ?

C’est valable pour toutes formes de racisme… on a le droit de penser et dire ce qu’on veut dans un cercle privé mais pas dans un cercle public… ce qu’est tweeter…



Ou est le problème ?

Que la loi interdise les propos ouvertement racistes ?



Les gens ont tout simplement tendance à oublier que quand on poste sur tweeter, potentiellement tout le monde peut avoir accès à leur prose plus ou moins intéressante… " />







Il y a des pays où il existe une vrai liberté d’expression : USA et UK.

Le 24/01/2013 à 10h 30

J’espère que google ne va pas utiliser des touches classiques pour les raccourcis.



Je déteste ces sites qui détournent les touches utilisées pour naviguer (typiquement les flèches, la barre d’espace, les raccourcis genre alt+d) et qui empêchent de naviguer au clavier comme sur n’importe quel autre site.



Ou alors, ça doit être désactivable facilement.

Le 23/01/2013 à 22h 16

En voyant le nombre de commentaires qui disent que chaque nouvelle version de Java est installée en plus des anciennes, j’en déduis qu’il y en a beaucoup qui installent le JDK au lieu du JRE.

Le 23/01/2013 à 17h 55

David_L a écrit :



Il fout une barre dans le navigateur (dans Chrome il passe par une install via la base de registre sans confirmation qui sera limitée dans la version 25 qui est actuellement dans le canal bêta)







Mais y a pas une case à décocher lors de l’install, pour qu’il s’installe proprement et tout seul ?

Le 23/01/2013 à 09h 52

Pour la déduplication, j’ajouterai les précisions suivantes : mega explique que si un même fichier est uploadé plusieurs fois et que la clé AES-128 générée aléatoirement est identique à un upload précédent, alors il y aura déduplication.



Les chances que cela arrives sont extrêmement minces (1 sur 2^128, soit 1 sur 340000000000000000000000000000000000000), mega explique donc que ce cas est prévu mais n’arrivera pour ainsi dire jamais.



Le cas le plus courant de déduplication sera effectivement la copie de fichiers à travers le file manager : du coup, dans ce cas là, une seule copie du fichier est gardée, et la même clé AES est du coup utilisée pour toutes les copies. Donc, dans le cas d’une copie entre différent comptes d’utilisateurs, j’imagine que la clé AES est simplement re-chiffrée avec la master-key du nouvel utilisateur.



Bref, effectivement, mega a bien répondu aux doutes que j’avais :)

Le 23/01/2013 à 09h 46

On apprendra aussi que l’ensemble des serveurs dispose d’un certificat SSL exploitant une clef de chiffrement sur 2048 bits, à l’exception des « statiques » qui contiennent les fichiers.





Non, ce n’est pas ce qui est expliqué. Il est expliqué que mega.co.nz dispose d’un certificat avec une clé RSA de 2048 bits, et les serveurs de contenu statique disposent d’un certificat avec une clé RSA de 1024 bits “seulement”.





MEGA explique que cette procédure est redondante de son point de vue (les fichiers étant déjà chiffrés) mais que les navigateurs n’aiment pas accéder à du contenu HTTP non sécurisé dans une page HTTPS (une erreur est alors souvent affichée). Ces serveurs se contentent donc d’un chiffrement 1024 bits afin de les satisfaire, sans imposer une charge CPU supplémentaire.





Inexact, il est expliqué que du point de vue de MEGA, une clé RSA 1024 bits n’est pas suffisante au niveau de la sécurité, et que c’est pour cela que du code javascript chargé depuis le serveur principal (donc avec clé de 2048 bits) vérifie l’intégrité de tout ce qui est chargé depuis les autres serveurs. Du coup, ils auraient pu se passer complètement de HTTPS pour les serveurs secondaires, mais comme ça génère des messages de warning dans les navigateurs, ils ont choisi d’utiliser une clé RSA 1024 bits pour éviter ça, tout en ayant un surplus de charge CPU acceptable.

Le 23/01/2013 à 09h 02

Fuinril a écrit :



var fichier = \(('fileInput').files[0];

\)(‘hiddentextinput’).text = mega.crypt(fichier.readAsBinary(), getCookie(‘privateKey’));

form.submit();





PS : c’est juste un exemple hein, je ne sais pas si c’est fait comme ça







Effectivement, j’ai trouvé ça :http://www.w3.org/TR/file-upload/



Mais c’est HTML5 only apparemment (bon, ça ne pose plus vraiment de problème de nos jours).

Le 22/01/2013 à 20h 45

bzc a écrit :



Ne pas lire un article qu’on commente il faut déjà un certain niveau, mais ne pas lire ce qu’on cite ça atteint des sommets.







Ne pas comprendre que je demande des infos sur la méthode utilisée, car je n’ai aucune idée de comment on peut accéder au contenu d’un fichier en javascript, c’est quel niveau ? Everest ?

Le 22/01/2013 à 19h 07

David_L a écrit :



Toute la partie Crypto est gérée en JS en local. Les clefs sont stockées, mais chiffrées avec la masterkey de l’utilisateur (elle même chiffrée avec un hash spécifique à l’utilisateur).



La différence vis à vis de MU c’est que : sans les pass utilisateur les données sont inutilisables. Sans la clef AES, un fichier ne peut pas être téléchargé et son nom reste inconnu.



Pour Hotmail et Gmail j’ai testé moi même : Hotmail > Spam ; Gmail > Boite de réception. Mais ça a été reçu dans les deux cas.







Donc le fichier est chiffré avant envoi à MU ? C’est fait avec quoi ça ? Nouvelle feature du HTML5 ?

Le 21/01/2013 à 09h 59

Resman a écrit :



Le problème ne vient pas de Java, mais de l’idée d’exécuter un bloc de code binaire venu d’Internet dans un navigateur, même si c’est dans une machine virtuelle c’est une tâche trop compliquée de sécuriser un langage générique à 100%. Microsoft a déjà essayé avec ActiveX, ça ne lui a pas trop réussi.



Il est temps d’abandonner l’idée avant que la réputation de Java soit complètement ruinée car tout le monde fait l’amalgame entre le plugin Java et le langage Java qui en soi n’est pas moins sécurisé que par exemple C++.







Marrant venant de quelqu’un qui fait l’amalgame avec ActiveX.



ActiveX n’est rien d’autre qu’une API pour faire des plugins scriptables pour IE.

C’est l’exact équivalent de la NPAPI de Firefox.

NPAPI que Google a entièrement réutilisée dans Chrome.



Le problème est qu’à l’époque (2000-2001), énormément de plugins ActiveX ont été développés, et à l’époque l’aspect “sécurité” des plugins était largement sous-estimé. Les plugins ActiveX étaient donc des nids à failles.



Les plugins ActiveX existent toujours (contrairement à ce que tu as écrit), on y trouve notamment Flash, Adobe Reader, Foxit Reader. Les mêmes plugins Flash, Adobe Reader, et Foxit Reader qui existent pour Firefox sous forme de plugins NPAPI.



Et donc en cas de faille dans un de ces plugins, peu importe qu’ils soient exécutés sous Firefox, Chrome, ou IE : les conséquences seront les mêmes.

Le 19/01/2013 à 15h 20

David_L a écrit :



Each user account uses a symmetric master key to ECB-encrypt all keys of the nodes it keeps in its own trees. This master key is stored on MEGA’s servers, encrypted with a hash derived from the user’s login password.







Mouais donc ça confirme que le serveur déchiffre lui-même au login la master key et l’envoie au client déchiffrée.



C’est pas bon du tout pour la sécurité, idéalement le serveur ne devrait avoir à aucun moment connaissance de la clé.



Par contre cette phrase ne fait à aucun moment mention de l’utilisation de crypto asymétrique, et le concept décrit n’a pas besoin de crypto asymétrique.



Tu as le droit de nous filer le doc d’où ça provient, ou c’est complètement interdit ?" />

Le 19/01/2013 à 09h 51

David_L a écrit :



Vu les questions sur cette partie, on va rendre ça un peu plus digeste en même temps que l’on rajoute quelques infos ce matin ;)







Ok parfait :)







David_L a écrit :



On verra les réactions et ce que l’on peut faire, après comme évoqué plus haut, je doute qu’un hébergeur veuille facilement s’allier à MEGA sauf à vouloir faire parler de lui. Ce devrait donc être compliqué avec ceux qui ont pignon sur rue du style d’OVH (mais je peux me tromper).



De toutes façons, on va déjà laisser MEGA sortir, et on verra :)







Ouaip, dès que j’ai un peu de temps, j’analyserai en détail ce qui se passe lors de l’upload/download d’un fichier, mais je pense que d’autres le feront avant moi de toute façon :)

Le 19/01/2013 à 08h 46

Lanthares a écrit :



Je ne suis pas sûr d’avoir bien compris : à chaque fois que l’utilisateur upload un fichier, une clé de 128 bits est générée aléatoirement côté client pour le chiffrer en AES, et l’ensemble des clés générées sont stockées sur les serveurs de Mega (jusque-là j’ai bon ?).



Ensuite pour que Mega/un hacker/la justice… ne puisse pas déchiffrer les fichiers stockés chez Mega, l’ensemble des clés est chiffré avec une Master Key (toujours bon ?).

Cette Master Key c’est une paire de clés publique/privée.(?)



L’utilisateur chiffre ses clés AES 128 bits avec la composante publique de la Master Key et déchiffre avec la composante privée elle-même chiffrée via une phrase de passe correspondant au hash du login et du mdp. (?)



C’est comme ça que j’ai interprété le passage “L’ensemble des clefs est stocké sur votre compte MEGA mais protégé par une clef principale (Master key) qui est elle-même chiffrée depuis une empreinte calculée à l’aide de votre login et de votre mot de passe.” même si je pense me tromper. " />











David_L a écrit :



Je fais un gros dodo, et on en reparle " /> " />









C’est ce que j’ai compris aussi. Mais ça reste bizarre.



Les implications sont :

-Impossible de partager un fichier, sauf à donner l’accès à son compte

-Le chiffrement des fichiers est fait entièrement côté serveur. Il utilise la clé publique du client pour chiffrer la clé AES-128 du fichier une fois le chiffrement fait.

-Au login, le serveur génère la clé privée en dérivant le login/pass, et la stocke dans le session storage du navigateur.

-J’imagine donc que quand on télécharge un fichier, le serveur envoie au navigateur la clé AES (chiffrée) du fichier, que le navigateur déchiffre grâce à la clé privée, et donc le déchiffrement se fait par le navigateur.



Ça ne me satisfait pas vraiment, car à chaque login, Mega est en mesure de récupérer la clé privée de l’utilisateur (car le serveur la calcule en dérivant login/mdp).

Le 18/01/2013 à 16h 46

Khalev a écrit :



Pourquoi envoyer la clé publique au serveur puisque tu le chiffres de ton côté? Ou alors j’ai pas suivi la discussion.







Oui, la discussion c’était “comment ça marche si le client ne peut pas chiffrer lui-même”, et aussi “s’ils utilisent le RSA, ça doit être soit pour pouvoir chiffrer côté serveur sans compromettre la clé privée”.



Parce que si le chiffrement/déchiffrement est fait uniquement côté client, on peut se poser la question de l’utilité d’un chiffrement asymétrique. Génération d’une clé AES à chaque fois qu’on uploade, et basta :)

Le 18/01/2013 à 16h 42

june a écrit :



Pour déchiffrer un fichier, il faudra une clé privée, point barre. C’est la base de la cryptographie.



La question est de savoir si il y aura un système de clés dérivées pour pouvoir partager seulement un fichier ou un répertoire. Je l’espère.

Cette clé serait une clé privée K2 dérivée de la clé privée ‘root’ K1, que tu ne passeras à personne.

K2 ne pourra déchiffrer que le fichier/répertoire pour lequel elle a été créée.

Et tu chiffreras avec K’2, clé publique associée à K2.







C’est le système que j’imaginais, avec une clé créée pour chaque fichier. Sinon, il sera impossible de partager un fichier sans refiler sa clé privée.

Le 18/01/2013 à 16h 41

bzc a écrit :



Non ça on s’en fout chacun partage ce qu’il veut.

Le problème (si le chiffrement/déchiffrement est bien fait coté serveur, j’ai toujours pas lu de confirmation) c’est que ça voudrait dire que tu envoies ta clé privé au serveur au moment du download. Donc utilisé du chiffrement quasi nulle.







Non, le cas de figure serait le suivant :

Le serveur dispose uniquement de la clé publique du client. Il peut donc chiffrer les fichiers. Mais il ne peut pas les déchiffrer (il a besoin de la clé privée pour ça).



Le client dispose de sa clé privée. Lors du téléchargement d’un fichier chiffré, le navigateur utilise cette clé pour déchiffrer le fichier (ça peut être fait entièrement côté client, sur le navigateur, via du javascript).



Dans ce cas de figure, à aucun moment le serveur n’a connaissance de la clé privée du client.

Le 18/01/2013 à 16h 33

Shadow aok a écrit :



Reste le déchiffrement à expliquer, quand tu télécharges un fichier via l’interface :)







C’est sûr que ça impliquerait que seul l’utilisateur qui a uploadé pourra télécharger et déchiffrer son fichier.



Du coup on serait loin d’un service de partage (sauf à partager sa clé privée, ce qui est une mauvaise idée).

Le 18/01/2013 à 16h 32

Shadow aok a écrit :



Pour le faire en AES-256, ça bouffe certes un peu plus de ressources mais pas tant que ça.







Pour faire simple, une opération de chiffrement/déchiffrement RSA est extrêmement complexe et prend énormément de temps CPU par rapport à n’importe quel algo symétrique.



C’est pour ça que le RSA est toujours utilisé pour chiffrer un tout petit bout de données, typiquement une clé AES, utilisée elle pour chiffrer/déchiffrer le reste des données (principe du SSL (HTTPS)).

Le 18/01/2013 à 16h 29

John Shaft a écrit :



C’est une méthode que je cite car je l’utilise fréquemment (pas d’autres choix ! - n’étant pas dévellopeur " />), mais je suis d’accord avec toi





Pas de problème, je ne mords pas :)











Nope, RSA n’a pas plus de raffinement qu’AES, c’est même plutôt le contraire. Je pense qu’ils ont pris RSA parce qu’ils sont mauvais et qu’ils ont du ce dire “Ça yen a être le plus utilisé sur le Web, dont nous yen a prendre ça” (" /> parce que 2048 bits offre une protection suffisante " />). Ensuite, faudrait comparer les ressources nécessaires pour chiffrer/déchiffrer en RSA 2048 et en AES-128





Voir mon dernier commentaire : si le chiffrement est fait côté serveur, sans qu’il puisse déchiffrer après coup, le RSA (ou en tout cas l’asymétrique) s’impose : le serveur chiffre avec la clé publique, seul le client peut déchiffrer avec la clé privée.



Mais sinon, un chiffrement purement RSA serait complètement dément au niveau des ressources nécessaires : la clé RSA servira probablement à chiffrer une simple clé AES, utilisée elle pour chiffrer en symétrique le fichier.

Le 18/01/2013 à 16h 27

Shadow aok a écrit :



Ah mais c’est tout simplement impossible en javascript pour le moment.

Mais si ça arrivait un jour, ça serait trop lourd sur de gros fichiers pour un navigateur.







" />



http://www-cs-students.stanford.edu/~tjw/jsbn/ => RSA en Javascript

Google=> AES, MD5, SHA-* en Javascript



Aucun problème de performance.

Le 18/01/2013 à 16h 23

Shadow aok a écrit :



Forcément côté serveur vu que l’interface est en HTML5 et ne peut donc ni chiffrer, ni déchiffrer les fichiers.

Même si technologiquement c’était possible, je vois mal Firefox (exemple) décoder un fichier de quelques Go, déjà qu’il est un peu gourmand en temps normal alors là …







Ah oui, autre explication de l’utilisation du RSA : le serveur ayant la clé publique, il peut s’occuper du chiffrement sans pouvoir déchiffrer après coup.



Mais bon, ça voudrait dire que les fichiers sont envoyés en clair, et se retrouvent donc temporairement en clair sur le serveur (le temps du chiffrement). Moyen, mais bon.

Le 18/01/2013 à 16h 21

anonyme a écrit :



C’est pas si clair que ca justement, elles peuvent (2 données différentes) exister au sein de mon compte, et etre doublons (les 2) de fichiers d’un autre utilisateur.



Et toujours en considération : Qui à des doublons de fichiers ? Et à fortiori : qui en plus uploaderai les doublons ? Non, je vois pas l’intéret de cette détection si c’est pour du compte par compte







Chaque utilisateur ayant sa propre clé de chiffrement, il ne pourra pas y avoir de doublons entre différents utilisateurs (sauf pour des très petits fichiers, mais au dela de quelques dizaines d’octets, la probabilité devient quasi-nulle).



Et des utilisateurs qui uploadent plusieurs fois le même fichier, il doit y en avoir :)

Le 18/01/2013 à 16h 16

aoemaster a écrit :



+1, personne ne parle de la fonctionnalité principale : le download !







Ah ben tiens, l’utilisation du RSA est peut-être destinée au partage. Ça permettrait de refiler la clé de chiffrement du fichier à un pote de manière complètement sécurisée.

Le 18/01/2013 à 16h 14

John Shaft a écrit :



Oué mais tu passe un coup de SHA-1 ou de MD5 sur le résultat et comme je supposes que la clé de l’utilisateur est la même pour les 2 fichiers, bin tu dois avoir un hash identiqueen sortie " />







[mode développeur en colère]

Pour comparer des fichiers, il ne faut surtout PAS faire un SHA-1 ou un MD5 dessus. Ok, ça marche, mais quel gaspillage de ressources (et encore, si on veut pinailler, le risque d’une collision étant non nul, on pourrait avoir des faux positifs) !



S’ils n’ont pas la même taille => ils sont différents.

Sinon, il suffit de simplement les comparer octet par octet. On s’arrête au premier octet différent.



Calculer un hash sur les fichiers va provoquer la lecture du fichier complet dans tous les cas (même si le premier octet est différent…), ce qui sature les I/O, et le calcul du hash prend un temps CPU non négligeable.



Quand je vois dans des codes source des trucs du genre :

if (md5_file(“x.bin”) == md5_file(“y.bin”))

echo “fichiers identiques !”;



Je me lève de ma chaise, et je vais engueuler celui qui a pondu ça.

[/mode développeur en colère]



Sinon, j’avoue ne pas bien comprendre l’utilité du chiffrement asyméatrique pour MEGA.



Une simple chiffrement AES suffit largement, et est beaucoup plus simple à mettre en place. Mais peut-être y a-t-il des raffinements au niveau sécurité qui expliquent l’utilisation du RSA, à voir dès demain.

Le 18/01/2013 à 11h 16

tazvld a écrit :



+1 : imaginez vous, si castelvania, Mario Bros, metroid et toute ces légende du JV rétro avait nécessité une connexion à un serveur Nitendo (dépassons le fait que ceci était inconcevable à l’époque), pensez vous qu’ils seraient toujours jouable aujourd’hui, 20ans après, pour des jeux même plus édités ?

Combien de temps les serveurs de Diablo III vivront-ils ? Survivront-il à la sortie d’un Diablo IV et V ?Ne tuons nous pas le rétro gaming du futur ?







S’il y a bien une chose qu’on ne peut pas reprocher à Blizzard, c’est le maintien des serveurs.



Diablo 1 (1996) : toujours online

Starcraft 1 (1998) : toujours online

Diablo 2 (2000) : toujours online

Le 17/01/2013 à 16h 54

wagaf a écrit :



Donc en gros ils admettent ne pas protéger leurs utilisateurs contre les failles 0-day ?



(failles par définition exploitées de manière beaucoup plus ciblées et donc peu présentes dans les stats globales)







Je ne sais pas ce qu’ils veulent dire exactement par 0-day (0-day avec exploit diffusé ? Ou faille 0-day sans exploit diffusé publiquement ?), mais par définition les malwares exploitant une faille 0-day ne sont pas connus, donc seul l’heuristique peut les trouver.



Quand tu regardes les dernières failles Java, pour les exploiter, il suffit d’une bête applet avec du code qui semble inoffensif, chose qu’aucun AV ne détectera en heuristique.



Et même si la signature d’un exploit est vite ajoutée à la base de l’AV, il est très facile de créer des centaines de variantes, donc ça reste très difficile à détecter.