Flux RSS
108538 documents trouvés, affichage des résultats 2661 à 2670.
| < Les 10 documents précédents | Les 10 documents suivants > |
(06/09/2011 17:01:09)
Entretien Yukihiro Matsumoto : « nous travaillons pour adapter Ruby aux terminaux mobiles »
Le langage Open Source Ruby a été créé par le développeur Yukihiro « Matz » Matsumoto en 1995. Aujourd'hui devenu un classique parmi les langages de programmation, il est utilisé par des sociétés comme SalesForce.com, Twitter et sert de base pour le framework d'applications Web, Ruby on Rail. Pour élaborer Ruby, Yukihiro Matsuomoto a combiné plusieurs langages tels que Perl, Smalltalk, Eiffel, Ada et Lisp.
Dans une interview à nos confrères de InfoWorld.com, le fondateur explique son intention d'augmenter la présence de Ruby sur les plate-formes mobiles et donne des détails sur l'histoire du langage.
Pourquoi avez-vous inventé Ruby?
J'ai commencé à développer à l'âge de 15 ans et j'ai toujours été intéressé par les langages de programmation en général. Je me suis spécialisé en informatique pour les étudier. Après cela, je voulais créer mon propre langage de programmation. Au début, c'était surtout conçu comme un langage de script. En 1995, beaucoup de personnes estimaient que la programmation orientée objet était trop compliquée pour faire du script. Mais je voulais vraiment que mon langage soit orienté objet.
Pour lire la suite, cliquer ici
L'iCloud d'Apple utiliserait les infrastructures d'Azure et d'AWS
Depuis juin, des rumeurs circulent selon lesquelles Apple aurait décidé de s'appuyer sur les ressources de Microsoft et d'Amazon plutôt que de développer sa propre infrastructure pour son offre iCloud. Le site britannique «Register.com» cite une source proche de Microsoft indiquant que la rumeur est fondée, et que les partenaires auraient signé un accord de confidentialité concernant ce projet. En s'appuyant sur les services de deux des plus grands fournisseurs, Apple évite de dépendre d'une seule société en cas de défaillance. «Register.com» souligne néanmoins le défi posé par l'hébergement de données clients dans deux clouds différents.
Une solution temporaire ?
A noter que même si Apple semble aujourd'hui avoir renoncé à utiliser sa propre infrastructure cloud, la firme de Cupertino construit actuellement un gigantestque centre de calcul en Caroline du Nord, pour un coût estimé à 500 millions de dollars. Une fois ce centre opérationnel, rien ne dit qu'Apple ne reprendra pas à son compte la gestion de son service iCloud. L'accord conclu avec ses deux concurrents ne serait donc qu'une solution «de secours» temporaire.
Le site «Business Insider» avance trois hypothèses :
- La plus vraisemblable, Apple sauvegarderait la plupart des contenus dans ses propres centres de calcul, et n'utiliserait AWS et Azure que comme solution de sauvegarde ou pour des fonctionnalités limitées, comme le streaming de contenus vidéo ou audio.
- Apple s'appuierait sur les services d'autres fournisseurs le temps d'étendre ses propres capacités et expertises. Une analyse curieuse quand on sait qu'Apple a débauché Kevin Timmons, le responsable des datacenters de Microsoft, pour travailler sur les infrastructures d'iCloud.
- Enfin, l'explication la plus loufoque, la firme à la pomme construit un centre de calcul de 46 000 mètres carrés pour intimider ses concurrents et ne compterait pas l'utiliser.
Certificats SSL DigiNotar : L'Iran à l'origine d'une opération d'espionnage informatique (MAJ)
Le faux certificat, livré le 10 juillet par le CA néerlandais, suite au piratage de ses serveurs, a été révoqué le 29 août. « Nous avons identifié environ 300 000 adresses IP uniques ayant envoyé des requêtes vers google.com, » indique Fox-IT dans son document. À partir du 4 août, le nombre de requêtes a rapidement augmenté, et ce jusqu'au 29 août, date à laquelle le certificat a été révoqué. Plus de 99 % de ces adresses IP ont été localisées en Iran. « La liste de ces adresses sera remise à Google. Le géant de l'internet pourra alors informer les utilisateurs que, pendant cette période, leurs emails ont pu être interceptés, » ajoute Fox-IT. « Pas seulement l'email lui-même, mais aussi le cookie de connexion, » indique encore l'entreprise de sécurité. Avec ce cookie, un pirate peut se connecter directement à la boîte aux lettres Gmail de l'utilisateur et à d'autres services de Google auxquels il est abonné. « Le cookie de connexion reste valide pendant une période plus longue, » explique Fox-IT, qui conseille aux utilisateurs iraniens « au moins de se déconnecter et de se reconnecter au service de Google, mais mieux encore, de changer leurs mots de passe de connexion. »
Toujours selon ce rapport, le reliquat d'adresses IP restantes, et repérées pendant cette période, venaient principalement de nodes Tor-exit, de proxies et d'autres serveurs VPN (réseau privé virtuel), mais quasiment pas de connexions directes. Ces conclusions ont été tirées de l'analyse des logs de requêtes OCSP (Online Certificate Status Protocol). Les navigateurs actuels effectuent un contrôle OCSP dès que le navigateur se connecte en mode SSL (Secure Sockets Layer) à un site web sécurisé par le protocole HTTPS (Hypertext Transfer Protocol Secure). Tor est un réseau distribué anonyme utilisé par certains internautes pour éviter d'être pistés ou pour se connecter à des services de messagerie instantanée et à d'autres services dans le cas où ils sont bloqués par leurs fournisseurs de services Internet locaux.
L'objectif : intercepter des communications iraniennes
Au total, 531 certificats numériques ont été émis pour des domaines appartenant à google.com, la CIA et le Mossad israélien. Selon Fox-IT, « compte tenu des domaines visés et du fait que 99 % des internautes ont été localisés en Iran, on peut penser que l'objectif des pirates était d'intercepter des communications privées en Iran. » Le 29 août, Google avait fait état de rapports signalant une « tentative d'attaques SSL de type man-in-the-middle (MITM) » contre les utilisateurs de Google. Ces attaques sont utilisées pour intercepter le trafic entre les internautes et les services cryptés de Google ou autres. Les personnes visées se trouvent principalement en Iran. L'attaquant a utilisé un faux certificat SSL émis par DigiNotar, révoqué depuis, comme l'a confirmé Google dans un message publié sur son blog.
Trend Micro, une autre entreprise de sécurité, a fait remarquer, hier, que le nom domaine validation.diginotar.nl, utilisé par les navigateurs Internet pour vérifier l'authenticité des certificats SSL émis par DigiNotar, avait été essentiellement chargé par des internautes néerlandais et iraniens jusqu'au 30 août. DigiNotar, dont les clients se trouvent principalement aux Pays-Bas, avait la qualité d'autorité de certification, c'est-à-dire l'autorisation d'émettre des certificats SSL. « Normalement, ce nom de domaine doit être essentiellement demandé par des internautes néerlandais et éventuellement par quelques utilisateurs situés d'autres pays, mais certainement pas par un aussi grand nombre d'Iraniens, » a déclaré Feike Hacquebord, chercheur spécialisé dans le piratage informatique chez Trend Micro. L'analyse des données effectuée par le Trend Smart Protection Network, révèle que le 28 août, un nombre important d'utilisateurs Internet situés en Iran ont chargé l'URL du certificat d'authentification SSL de DigiNotar. Mais à partir du 30 août, ce trafic a disparu, et le 2 septembre tout le trafic iranien avait disparu.
[[page]]
Toujours selon le rapport de Fox-IT, c'est le 29 août au soir que l'on a su qu'un faux certificat x.google.com était présenté par un certain nombre d'utilisateurs internet se connectant depuis l'Iran. Selon DigiNotar, ce faux certificat a été révoqué le soir même. L'entreprise de sécurité, contactée le lendemain, a du procéder à une enquête. Dans son rapport, Fox-IT indique que la première intrusion dans les serveurs de DigiNotar a pu avoir lieu le 17 juin. De son côté, DigiNotar dit avoir constaté l'incident le 19 juin au cours de sa procédure normale de vérification quotidienne. Mais il semblerait qu'elle n'a pris alors aucune mesure à ce sujet. L'entreprise n'a pour l'instant pas fait de commentaire sur ce point.
Le premier certificat compromis x.google.com, a été émis le 10 juillet. Tous les autres certificats ont été livrés entre le 10 et le 20 juillet. « Le piratage laisse penser que la configuration du réseau et les procédures de DigiNotar n'étaient pas suffisamment sécurisées pour éviter ce genre d'attaque, » indique Fox-IT. « Il arrive que des serveurs hébergeant des données critiques laissent passer des logiciels malveillants, mais ceux-ci peuvent normalement être détectés par les logiciels antivirus. La protection des données critiques n'a pas fonctionné, ou alors il n'y en avait tout simplement pas, » ajoute le rapport.
(MAJ) Un pirate du nom de Comodohacker a revendiqué sur le site Pastbin le vol des certificats SSL de l'autorité de certification DigiNotar. L'identité du présumé pirate n'est pas inconnu car il s'agit de celui de l'affaire Comodo en mars dernier. Le pirate se définit comme un jeune iranien de 21 ans et justifie ses actes par des questions politiques. Pour les récents vols de certificats SSL, il souhaite punir le gouvernement hollandais dont les soldats ont laissé les soldats serbes à tuer 8 000 musulmans en 1995 à Sebrenica. Le hacker précise dans son message qu'il dispose d'autres accès aux comptes de 4 importantes autorités de certification et pourrait réémettre des faux certificats SSL.
| < Les 10 documents précédents | Les 10 documents suivants > |