Behind The Cloud…. or How Internet works?

 

« How this crap works? » « I type the name in g**gle and I access to the website, that’s all. » « Give me a break, it’s secure, it’s come from an HTTPS website »

Well, that seems like fantasy but we all heard this kind of pleasant comments on Internet or from family and sometimes even from IT workers. And to explain the truth, it’s often difficult to simplify the way taken by our data or why HTTPS doesn’t mean verifiable data. Even if for the last one, you can simply point out that Fox News has an HTTPS website 🙂

Multilingual source is available here.

Facebooktwitterlinkedin

Derrière les nuages…

« Comment ça marche Internet? », c’est une question récurrente dans le monde de l’informatique et dont certains n’ont pas la réponse. Celle-ci est complexe et nécessite de solides bases en réseau, en cryptographie, en architecture et même en développement!

Cette affiche a pourtant vocation d’expliquer tout ça et plus encore de permettre de comprendre comment un système de P2P a construit notre internet et lui a permis d’être indépendant de toute autorité centralisée.

Facebooktwitterlinkedin

Initiation au Post-Quantique: Comprendre les réseaux euclidiens

L’algorithme d’échange de clef CECPQ1 développé par Google pour répondre au besoin du post-quantique se base sur deux algorithmes: X25519 basé sur la célèbre courbe elliptique open-source 2225-19 et l’algorithme NewHope, un algorithme post-quantique basé sur les réseaux euclidens et le problème RLWE.

Mais qu’est-ce qu’un réseau euclidien et comment sa sécurité fonctionne?

Explication du fonctionnement de LWE et des réseaux euclidiens.
Facebooktwitterlinkedin

Cryptographie Quantique

Le quantique est aujourd’hui perçu comme une menace par le milieu de la cryptographie mais au delà de la crainte terrifiante que Schor se réveille un matin avec un nouvel algorithme pour détruire le monde, le quantique c’est aussi un volet d’opportunités nouvelles et la possibilité de construire sur des propriétés physiques en plus de mathématiques.

Facebooktwitterlinkedin

[Conférence] Blockchain et Lutte anti-blanchiment (Lamy)

Nous avons réalisé le 19 Septembre une conférence sur la Blockchain et ses implications dans le blanchiment d’argent avec Madame Yvonne Müller pour le compte des éditions Lamy. Comme toujours, les supports de conférence pour ma partie sont publiés sous licence CC-by-sa sur ce site.

Le premier support correspond à la définition du terme de Blockchain, à ses implications et surtout à son fonctionnement pratique avec l’illustration concrète d’un échange de monnaie virtuelle avec le Bitcoin.

Quand Alice rencontre Bob, ou l’histoire d’un scandale financier animé.

Le second support, fait un focus sur les différents usages de la Blockchain. En effet aujourd’hui la Blockchain peut résoudre de nombreux problèmes, tant dans le domaine du Civil que des applications plus pécuniaires…

Des usages de la Blockchain
Facebooktwitterlinkedin

33c3 – You can -j REJECT but you can not hide: Global scanning of the IPv6 Internet (Tobias Fiebig)

Cet article est aussi disponible sur CERT Devoteam

Cette conférence était axée sur la manière de scanner Internet à l’ère de l’IPv6. En effet, s’il est possible de réaliser un scan IPv4 sur l’ensemble des plages en quelques minutes, il devient difficile voire impossible de scanner les plages IPv6 avec les outils actuels (zmap ou massscan). Il faudrait aujourd’hui 7.532×1023 années pour scanner cet espace. Le conférencier a alors cherché à réduire l’espace à scanner via des analyses d’attribution. En l’état, les études réalisées l’ont été par des grands CDN, des accès DNS et un IXP européen et permettent une prédiction à 40% d’une adresse IPv6 active. Le conférencier n’ayant pas accès à de tels moyens, il a cherché à découvrir une autre méthode de découverte des adresses.

Le conférencier s’est alors appuyé sur une propriété native des résolutions DNS. En effet grâce au DNS, il est possible de mapper chaque adresse via une requête DNS ainsi la résolution de 8.8.8.8.ip4.arpa donnera 8.8.8.8. En IPv6, cette résolution marche avec .ip6.arpa . De plus la RFC8020 spécifie (notamment) la norme pour les codes d’erreur DNS permettant de déterminer si un nom de domaine n’a pas été trouvé parce qu’il n’existe pas (NXDOMAIN) ou parce que le top level n’est pas attribué (NOERROR), cette propriété permet donc d’obtenir les IPv6 attribués par dichotomie en descendant le long des domaines par exemple en suivant :

  • .ip6.arpa
  • .f.ip6.arpa
  • .e.f.ip6.arpa.
  • e.e.f.ip6.arpa

Via cette méthode, le conférencier a découvert 1.6 millions d’enregistrements en 65 heures d’exécution.

Le problème réside dans l’absence d’implémentation de la RFC8020 par une partie des DNS. Le conférencier a alors complété sa recherche avec l’agrégation de vue BGP ou du seeding BGP et a porté son nombre d’IPv6 obtenues à 5.3 millions en 70.5h.

Le bilan de ce scan se conclu par une magnifique cartographie d’IPv6 incluant notamment le réseau de la ville de Francfort mais aussi de la Nasa et du .mil avec la présence de résultats intéressants comme des machines de supervision bigbrother, d’un serveur Amiral Achbar ou un frigo connecté. Beaucoup de devices IPv4 ont été trouvé également via des serveurs DHCP (des imprimantes dans l’essentiel) ainsi que des instances elasticsearch.

Facebooktwitterlinkedin

33c3 – Deploying TLS 1.3: the great, the good and the bad (Filippo Valsorda, Nick Sullivan)

Cet article est en grande partie basé sur la conférence « Deploying TLS 1.3: the great, the good and the bad » cependant certains éléments ont été étudiés plus en profondeur via la consultation du draft de la RFC « The TLS Protocol version 1.3 ».

TLS 1.3 apporte une modification profonde dans l’établissement d’une connexion chiffrée via TLS. En effet de 4 messages dans le cas de TLS 1.2 pour l’établissement d’une connexion standard, TLS 1.3 permet d’établir une connexion en 2 messages en cas de connexion standard. Cette évolution a été apportée grâce à un envoi direct de la part du client de la négociation de clef via l’utilisation de groupes Diffie-Hellman communs, de sorte que le serveur n’ait plus qu’à valider sa part de l’échange en complétant le Diffie-Hellman, en validant l’algorithme AEAD utilisé et en envoyant le certificat. Le client peut alors commencer directement la connexion chiffrée avec le paquet finished. En cas de besoin de renégociation du serveur, un envoi supplémentaire est fait avec de nouveaux arguments.

Continue reading →

Facebooktwitterlinkedin