Programme thème Sécurité RMLL 2012 & 2 entretiens avec Werner Koch et Eric Leblond

Dans le cadre des RMLL 2012 qui se déroulent à Genève du 7 au 12 Juillet, le thème Sécurité vous propose trois demi-journées autour des thématiques suivantes :

• sécurité réseau ;
• reverse engineering (une conférence et un atelier) ;
• fonctions d'appui à la sécurité ;
• et enfin, préservation de la vie privée et des données personnelles.

Lundi 09 Juillet 2012 :
Après midi :

• Avancées récentes de l’IDS/IPS Suricata par Eric LEBLOND
• Scan réseau avancé avec nmap 6 par Henri DOREAU
• Naxsi - une approche positive du filtrage applicatif Web par Didier CONCHAUDRON, Sébastien BLOT
• Le WebSSO LemonLDAP::NG : présentation et nouveautés de la version 1.2 par Clément OUDOT
• Reverse Engineering sur plateforme open source par Paul RASCAGNERES

Mardi 10 Juillet 2012 :
Matin :

• Introduction aux antivirus et présentation de ClamAV par Antoine CERVOISE
• Atelier : Reverse Engineering sur plateforme libre par Paul RASCAGNERES
• Simplifier l’authentification avec Kerberos : du mono-poste à la PME par Matthieu CERDA
• Construire son application web de gestion de contenu d’annuaire LDAP par Clément OUDOT

Après midi :

• OpenPGP and S/MIME are both on the STEED par Werner KOCH
• Mozilla BrowserID/Persona et la vie privée sur le Web par Jean-Yves PERRIER
• Elections en ligne vérifiables avec Helios par Stéphane GLONDU
• L’accès à internet est un sport de combat par Kevin DENIS

Enfin, vous trouverez dans la suite de la dépêche 2 entretiens avec Werner Koch d'une part (GnuPG, STEED et la vie privée sur le net) et avec Eric Leblond d'autre part (Suricata, IDS/IPS et la Sécurité).

Venez nombreux : c'est du lourd, c'est du libre, et … c'est gratuit !

Sommaire

• Entretien avec Werner Koch sur STEED et GnuPG
• Entretien avec Eric Leblond sur Suricata, les IDS et la Sécurité

Entretien avec Werner Koch sur STEED et GnuPG

Introduction :
Le thème Sécurité des RMLL 2012 accueillera 2 conférences qui parleront de vie privée et de gestion des données personnelles sur Internet.

La première sera donnée par Jean-Yves Perrier de Mozilla. Jean-Yves présentera le projet Persona/BrowserID de Mozilla. La seconde conférence sera donnée par Werner Koch qui nous parlera de STEED, un projet STEED, un projet de simplification et de généralisation de l’usage du chiffrement et de la signature du courrier électronique.

Échangeons maintenant avec Werner, le créateur et développeur principal de GnuPG et fondateur de g10code.

Question : Bonjour Werner. Votre collègue, Marcus Brinkmann, est venu l’an passé aux RMLL 2011 donner une conférence débutant par "Pourquoi le chiffrement pour la messagerie a échoué" et a exposé les premières idées qui seraient derrière STEED, le projet que vous avez lancé en Octobre 2011. Pour les créateurs de GnuPG, le standard de fait du chiffrement pour la messagerie, une telle introduction est un message assez fort. Pouvez vous expliquer quelles sont vos idées là dessus et nous présenter le projet STEED ?

Werner Koch : Il y a quelque temps, Marcus et moi avons travaillé sur l’intégration de la cryptographie au sein de téléphones portables. Ce travail incluait de nombreux et longs voyages en train qui nous ont donné l’opportunité de parler de l’aspect inutilisable du chiffrement de bout en bout. Depuis que Phil (ndt : Philippe Zimmermann, créateur de PGP) est arrivé avec PGP il y a 20 ans, les bases techniques pour un bon chiffrement sont vraiment disponibles. Même aujourd’hui où la plupart des gens sont accros au net, l’utilisation du chiffrement pour les communications privées est pratiquement inexistante. Nous, les hackers, avons voulu rendre ce chiffrement aussi bon et sûr que possible, mais nous n’avions que les mathématiques et l’ingénierie à l’esprit. Nous avons négligé le monde réel de la communication : les attaques ciblées par courrier sont très rares pour la plupart des gens, il n’y a généralement pas d’interception de communication (ndt : « no man in the middle »). Ainsi, nous pouvons faire sans toutes les techniques pointues de sécurité auxquelles nous sommes habitués. Nous n’avons pas besoin de moyens ultra sécurisés pour communiquer avec quelqu’un que nous ne connaissons pas encore vraiment.

Nous avons examiné quelques idées existantes comme SSH et les infrastructures de clés publiques pour concevoir une système permettant de rendre le chiffrement la plupart du temps invisible. STEED est notre concept visant à faire fonctionner ces idées ensemble et à les intégrer aux logiciels de messagerie existants. L’idée de base est simple : si votre programme de messagerie voit que vous n’avez pas avoir une clé pour votre compte de messagerie actuel, il en crée une en arrière plan. La clé publique sera ensuite envoyée à une base de données mondiale. En fin de processus, vous recevez un mail de notification de cette base de données vous indiquant que votre clé est maintenant disponible mondialement. Désormais, lorsque vous êtes sur le point d’envoyer un mail, les logiciels de messagerie compatible Steed vont chercher la clé du destinataire dans cette base de données mondiale. Si une clé a été trouvée, le message sera chiffré, sinon, il est envoyé en clair. Plus tard, quand vous envoyez un autre mail, la base de données mondiale est interrogée comme d’habitude, mais le résultat sera également comparé avec une base de données locale, afin de vérifier si la clé renvoyée par la base globale correspond à celle utilisée lors de l’envoi précédent. Si ce n’est pas le cas, une alerte est émise et un court message d’explication expliquera qu’une possibilité d’interception type « man in the middle » existe.

Question : À quelle étape de votre feuille de route en êtes vous rendu : des premiers articles, des preuves de concepts, des échanges avec des fournisseurs d’identité du marché ?

Werner Koch : J’ai donné plusieurs conférences sur le projet et nous avons produit des versions revues de nos articles pour la conférence GUUG de ce printemps. LWN a publié un article sur elle et je suis heureux qu’à cette occasion nous ayons pu gagner un peu d’attention. Il n’y a pas pour l’instant beaucoup de nouveau code, parce que nous avons à peu près tout mis en œuvre dans GnuPG. La prochaine étape sera d’implémenter ce concept dans un client de messagerie. Cependant, avant que nous puissions le faire, nous avons besoin d’avoir un moyen de stocker les clés.

Question : Dans votre article initial, la base de données utilisée pour stocker les clés était le DNS. Avez-vous été en mesure d’échanger avec certains fournisseurs de DNS pour voir s’ils seraient enclins à ouvrir leur infrastructure afin de permettre à leurs utilisateurs de stocker ce genre d’information ? Avez-vous besoin de plus de contacts avec des fournisseurs d’infrastructure ?

Werner Koch : Malheureusement, je n’ai pas eu de succès dans cette entreprise. J’ai parlé à certains fournisseurs, mais la tendance générale semble être : aucune expérimentation. Ils attendent un effet direct en termes de retour sur investissement et ne voient pas comment le chiffrement pourrait y aboutir. Pour être honnête, je comprends cette position. Au cours de ces 15 dernières années, la promesse a été que le chiffrement serait bientôt utilisé de manière banalisée pour le courrier électronique. Nous savons tous que cela ne s’est pas produit. C’est comme la promesse depuis 25 ans d’aboutir à une organisation en entreprise zéro papier. Nous avons besoin de changer de stratégie. S'il n’y a aucun moyen direct d’obtenir l’attention des fournisseurs de messagerie, nous devons fournir une infrastructure de secours agissant en tant que fournisseur d’identité proxy, infrastructure qui serait gérée par nous.

Question : Pour l’architecture Persona/BrowserID de Mozilla qui va également être présentée aux RMLL 2012, Mozilla gère un service BrowserID.org qui contribue à l’amorçage du projet et donc, pour ne pas avoir à attendre l’ouverture généralisée de l’infrastructure des fournisseurs d’identité (dans leur cas, les fournisseurs de messagerie). Serait-ce une idée intéressante pouvant être réutilisée pour STEED ? Si oui, de quelle manière ?

Werner Koch : Exactement. J’ai réfléchi à l’idée de mettre en place un groupe de fournisseurs d’identité sous le domaine gnupg.net où chacun pourrait s’occuper d’un groupe entier d’adresses mail. Cela pourrait se faire en hachant l’adresse, en encodant ce hash en Base32 et en utilisant cela comme clé dans le DNS. Nous aurions besoin d’écrire un système facile à installer pour fournir cette infrastructure et la déléguer à des personnes de confiance. Évidemment, Mozilla, confrontée aux mêmes problématiques, a eu la même idée. Je suis heureux que vous m’ayez orienté vers browserid.org ; il est beaucoup plus simple de se greffer sur un système comme celui-ci que de commencer à concevoir un programme similaire. Il donne même une meilleure expérience utilisateur. BrowserID pourrait être une incitation à essayer STEED. Techniquement, nous pourrions implémenter cela en interrogeant un champ spécial auprès du fournisseur de messagerie qui permettrait de savoir si le fournisseur est compatible STEED. Si le résultat est négatif, nous nous reposerions sur une base de données des clés publiques basée sur browserid.org.

Question : Quel genre d’aide avez vous vraiment besoin de la part de la communauté afin d’accélérer le développement du projet ?

Werner Koch : Tout d’abord, dites à vos amis que le chiffrement des messages est important, même à l’âge de Facebook. Ils regretteront peut-être plus tard d’avoir négligé de prendre un peu de soin de leur vie privée. Deuxièmement, s’impliquer à partir du moment où l’outillage sera développé. J’entends par là, d’utiliser effectivement le système et d’aider à l’intégrer au sein d’autres clients de messagerie. Nous avons également besoin d’idées pour faire face au spam de manière décentralisée.

Question : Quelle est votre prochaine étape dans ce projet ?

Werner Koch : Trouver un moyen de financer la maintenance et le développement de GnuPG. C’est une condition sine qua non à l’implémentation de STEED.

Dernière question : vous venez aux RMLL 2012. Qu’attendez-vous d’une présentation dans un événement comme les RMLL où les participants viennent d’horizons très éclectiques (militants du logiciel libre, des développeurs noyaux, des administrateurs système, etc) ?

Werner Koch : Les concepts soutenant STEED ne sont pas encore assez connus. Je suis heureux d’avoir l’occasion de présenter STEED à une grande conférence technique et nous espérons attirer l’attention d’autres personnes créatives. Parler en personne est souvent mieux qu’échanger uniquement par courrier électronique. Je suis allé aux RMLL 3 ou 4 fois dans le passé et je me rappelle de bons échanges avec d’autres personnes intéressantes. Il est dommage que je ne puisse rester que 2 jours.

Entretien avec Eric Leblond sur Suricata, les IDS et la Sécurité

Question : Bonjour Eric Tu viens présenter l’avancement du projet d’IDS/IPS open source Suricata pour lequel tu es un des développeurs principaux. Peux-tu, tout d’abord, nous présenter rapidement ce projet et ses principaux éléments différenciateurs avec ses concurrents libres ou propriétaires ?

NdM : IDS: Intrusion Detection System, système de détection d'intrusion

Eric Leblond : Suricata est un IDS/IPS réseau qui a été développé depuis zéro sous l’impulsion de Victor Julien qui reste développeur principal et leader du projet. Il appartient à la même famille d’IDS/IPS que snort dont il a repris le langage de signatures. L’idée derrière ce choix était de permettre de reprendre les jeux de signatures existant qui sont souvent la vraie richesse d’un IDS de ce type. Avec un développement commencé en 2008, Suricata a une base de code moderne et a pris le parti d’utiliser des technologies récentes. Une des principales conséquences a été l’utilisation du multithreading. Suricata est ainsi capable de tirer avantage des architectures multicores qui sont incontournables actuellement. Un des autres points forts de Suricata est la détection automatique de protocoles et les mots clés protocolaires. Pour donner un exemple concret, Suricata va déterminer automatiquement qu’un flux sur le port 3456 est du HTTP et il appliquera alors les signatures HTTP sur le flux. Celles-ci peuvent utiliser des mots clés comme http_body ou http_uri qui recherche des correspondances dans les versions normalisées des flux pour ce protocole. Il n’y a donc pas besoin de chercher manuellement le décalage pour ces champs dans les requêtes et toutes les subtilités du protocole HTTP (comme le chuncking) sont gérées de manière transparente.

Question : quels sont les axes sur lesquels tu interviens le plus ? quels outils et langages utilises-tu ?

Eric Leblond : Je suis responsable de la partie acquisition de paquets, ce qui signifie que je gère les modes IPS et IDS et le support des différents modules d’entrées (pcap, AF_PACKET, pf_ring, Netfilter, ipfw). J’interviens aussi sur la partie journalisation et je participe avec Pierre Chifflier au développement du support du protocole TLS. Au niveau du langage c’est exclusivement du C. L’intégralité de Suricata étant développée avec ce langage si l’on excepte la partie système de build qui utilise les autotools et leur fabuleux m4. Un des points plus mineurs et exotiques sur lesquels je sois intervenu est l’ajout de tests sur le code. Il s’agit de tests utilisant l’excellent logiciel coccinelle (http://coccinelle.lip6.fr) et qui réalise une vérification de la conformité du code à des règles de programmation définies lors du développement (non utilisation de certaines fonctions interdites, utilisation conforme de certaines structures complexes).

Question : De par tes développements précédents, tu es un développeur Netfilter expérimenté. As-tu beaucoup réinvesti de cette expérience dans Suricata ? Est-ce qu’il y a eu des échanges entre les 2 communautés ?

Eric Leblond : C’est plus mon expérience sur le projet NuFW qui m’a servi pour les développements sur Suricata qui a parfois des « problèmes » que nous avions dû régler sur NuFW. Concernant Netfilter, il y a effectivement un réel échange. J’ai notamment exposé lors du dernier Netfilter Workshop certains des besoins de Suricata.

Question : De manière plus globale, toi qui est un professionnel de la sécurité depuis longtemps maintenant, penses tu que les IDS/IPS ont prouvé leur utilité en entreprises ou pour les gouvernements ? Doivent ils en partie se réinventer ? Ou le succès du déploiement d’un IDS/IPS dépend-il finalement que des objectifs que l’on fixe à ce projet (ex. : syndrome de l’outil unique qui doit tout résoudre en termes de sécurité) ?

Eric Leblond : L’IDS est bien loin de pouvoir prétendre à être un outil unique. Les informations remontées par les serveurs et notamment les journaux contiennent énormément d’informations précieuses. Je pense qu’il est nécessaire de concevoir la surveillance des systèmes de manière globale. Je suis peut-être marqué par mon expérience avec Prelude mais je ne pense pas être dans le faux. Cette façon de voir implique des coûts. Le traitement des alertes et la mise à jour des signatures (incluant l’écriture de signature dédiée) sont deux taches cruciales. Elles doivent être effectuées de manière régulière pour être vraiment utile. Sans temps et sans compétence réelles affectées sur ces taches, un IDS est complètement inutile. Il peut même être néfaste dans le cas d’un IPS mal configuré ou non maintenu.

Question : Ce projet a une particularité notable dans le fait qu’il a été fondé et est soutenu par un certain nombre d’agences gouvernementales et d’éditeurs. Peux tu nous éclairer sur ce point ainsi que sur les avantages et les inconvénients éventuels que tu y vois, toi qui est à l’intérieur du projet ?

Eric Leblond : Je trouve le financement et la gouvernance de ce projet particulièrement captivants. En arrivant dans le projet je ne pensais pas qu’ils seraient aussi indépendants. Être dans le consortium ne donne ainsi pas de droits sur la gestion des évolutions et de la feuille de route du projet. Celle-ci est discutée lors de réunions publiques (retransmise sur Internet dans la mesure du possible). Tout le monde peut y participer et apporter ses idées. Concernant le financement, l’apport initial a été fait par le projet HOST du Homeland qui sponsorise des projets Open Source. La seule exigence de cette puissante et redoutée institution a été que l’argent investi soit bien utilisé. Ils n’ont à ma connaissance jamais tenté d’influer sur des décisions techniques. Ceci s’explique en partie par la finalité de cette intervention : le Homeland a initié le projet en indiquant dès le départ qu’il souhaitait qu’un écosystème industriel se forme autour du projet pour assurer sa pérennité et son financement. La part relative ainsi que le montant absolu donné par le Homeland baisse ainsi régulièrement. Ce n’est que mon avis mais ce mode de financement et de développement me semble particulièrement intelligent.

Question : Enfin, toi qui à la fois est un orateur régulier aux RMLL mais aussi au SSTIC ou à CanSecWest par exemple : comment pourrais tu comparer ces différentes conférences sur les sujets de sécurité (les RMLL à la différence des 2 autres est généraliste) : apports sécurité de la conférence, échanges avec les autres intervenants et le public, relations qui en découlent à posteriori, ambiance etc ?

Eric Leblond : Pour moi, l’une des spécificités du track sécurité des RMLL est de ne convier quasi exclusivement que des développeurs de solutions, libres de surcroît, et non d’attaques ou d’exploits. Cet environnement me convient parfaitement puisqu’il correspond à mon expérience et à mes réalisations. Au niveau de l’apport en sécurité, il découle un aspect plus défensif des RMLLs par rapport aux autres conférences souvent plus axées sur l’offensif et le reverse.

Les RMLL sont un événement généraliste sur le Logiciel Libre et le public comporte donc des non spécialistes. Ce côté généraliste se ressent particulièrement lors des échanges hors thème (le public du thème sécurité est généralement assez spécialisé). En étant sur un stand l’an dernier, j’ai eu des échanges très variés allant d’un discours éducatif à une discussion entre ’experts’ pour envisager une future collaboration entre projets. Celle-ci porte ses frais puisque Henri Doreau (ndr : contributeur Nmap et OpenVAS, orateur depuis 2 ans aux RMLL) est en train d’encadrer un Google Summer of Code dont une des tâches est de développer dans nmap l’attaque que je viens de présenter à SSTIC et qui était encore privée à l’époque des dernières RMLL.

Entretiens de Werner Koch et d'Eric Leblond réalisées par email en Juin 2012 par Christophe Brocas, co-responsable du thème Sécurité des RMLL 2012.

Aller plus loin

• Programme Sécurité RMLL 2012 par le détail (56 clics)
• Version originale (EN) de l'entretien avec Werner Koch (10 clics)