Petit résumé des causeries que j'ai retenues des JRES 2015.
Centralisé, décentralisé, pair à pair, quels mots pour l'architecture des systèmes répartis ?
Une causerie sur le vocabulaire permettant de décrire des systèmes répartis à l'échelle de l'Internet, c'est-à-dire des systèmes multi-entités. L'objectif est d'éviter les débats épidermiques comme « IRC est acentré » ou « dns est centralisé » ou « dns est décentralisé car il y a plusieurs serveurs qui servent la racine ».
FranceConnect : un accès universel aux services en ligne
- Service ministériel de tiers de confiance selon une architecture OpenID (fournisseurs d'identité, fournisseurs de services, fournisseurs de données, etc.) ;
- Les fournisseurs d'identité vérifient plus ou moins fortement les identités et l'existence d'un lien entre une identité et une personne physique (ce qui différencie FranceConnect de FacebookConnect, par exemple). FranceConnect pourra utiliser des fournisseurs d'identités européens (utile pour un résident UE qui doit remplir de la paperasse en France, par exemple). L'harmonisation en matière de contrôle de l'identité sera cadrée par le règlement européen iDAS ;
- Afin d'éviter les doublons, il y a une recherche dans le Registre National des Identités des Personnes Physiques, fichier géré par l'INSEE et accessible sur décision ministérielle ;
- FranceConnect permet de mettre en relation des services qui ont besoin de données (exemple : un revenu fiscal de référence) et un fournisseur de données (exemple : la DGFIP). Les données échangées ne circulent pas par FranceConnect, seulement la mise en relation sécurisée ;
- FranceConnect : OpenID ; Fédération d'identité Enseignement Supérieur et Recherche : SAML. Passerelle afin de faire communiquer ces deux mondes technologiques ;
Passage à l'échelle de l'infrastructure réseau d'une solution de virtualisation avec VXLAN
- Architecture : VLANs entre des pare-feux (OpenBSD) et des machines virtuelles (KVM-libvirt), avec tout un réseau dorsal entre les deux ;
- Limites de 802.1q : explosion de la taille des tables de commutation, limitation à 4096 VLANs, et exploitation pénible (pour ajouter/modifier/supprimer un VLAN, il faut configurer l'hyperviseur, les pare-feux et toooous les switchs entre les deux) ;
- Autre solution envisagée : MVRP, protocole de signalisation et de remontée automatique des VLANs à travers tout le réseau, depuis les commutateurs auxquels sont branchés les hyperviseurs, jusqu'aux commutateurs auxquels sont reliés les pare-feux. Ce protocole ne répond pas au cahier des charges : le nombre de VLANs reste limité et l'explosion de la table de commutation n'est pas endiguée ;
- VXLAN : overlay network, encapsulation des trames ethernet dans des entêtes VXLAN qui fonctionne lui-même sur UDP ;
- Comment gérer le trafic broadcast, multicast et unicast sans association MAC<->IP ? Préremplir les tables de commutation VXLAN des VTEP (nom des points d'entrés d'un réseau VLAN), ce qui dupliquera le trafic vers toutes les entrées de cette table, ou utiliser un groupe multicast pour transporter le trafic VXLAN, ainsi les infos clés (IP, MAC) sont distribuées partout et les tables de commut' se remplissent ;
- Les pare-feux OpenBSD sont également des passerelles VXLAN entre le réseau VXLAN et l'extérieur (IP vers Internet, etc.) ;
- VXLAN-EVPN permet d'avoir un control plane basé sur MP-BGP ;
- VXLAN nécessite de réduire la MTU des hyperviseurs ou d'augmenter la MTU sur le réseau transportant VXLAN, car VXLAN induit un overhead de 50 octets minimum (14 octets pour Ethernet, 20 octets pour IP, 8 octets pour UDP, 8 octets pour les entêtes VXLAN).
Bonnes pratiques de sécurisation de BGP
Quelques rappels concernant la sécurité du routage Internet : bonnes pratiques (RFC 7454), RPKI+ROA pour valider cryptographiquement l'origine des annonces de route, BGPSec pour valider cryptographiquement le chemin complet des routes.
- Le route flap dampering (suppression temporaire des routes instables) s'est remis de sa disgrâce d'il y a quelques années : le RFC 7196 le conseille avec une pénalité de 6000 (ce qui laisse la possibilité de 6 instabilités, chacune ayant une pénalité de 1000 points) ;
- RFC 8097 : communauté BGP étendue non-transitive pour transmettre l'état de validation RPKI+ROA d'une route au sein d'un même AS.
Caliopen - retrouver une vie privée en ligne
Présentation de Caliopen par Laurent Chemla : écosystème (association, charte, garanties) libre d'instances fédérées agrégeant les communications (email, jabber, XMPP, message privé, SMS, etc.) par personnes participant à la conversation, plus par sujet de la conversation ou par protocole. La confidentialité s'améliorera grâce à des indices de confidentialité, des conseils, et un jeu pour faire progresser son évaluation publique. Projet peu soutenu par la communauté.
- La publication des documents fuités par Snowden a permis une prise de conscience autour de la vie privée, mais cela n'a pas suffit à faire changer les habitudes. En cause, la surveillance coûte peu cher grâce à la centralisation des acteurs Internet, mais la vie privée demande d'importants efforts alors que les citoyens ne lui reconnaissent qu'une importance faible ;
- La simplicité d'utilisation et la gratuité des plateformes centralisées empêchent l'émergence de solutions identiques, mais sécurisée et payantes, ce qui fait qu'un utilisateur de Protonmail, par exemple, a 1 chance sur 1000 de communiquer avec un autre utilisateur de Protonmail… tous ses autres échanges ne seront pas confidentiels. Les solutions plus radicales, comme Pond ou BitMessage font perdre l'essentiel des contacts ;
- Dans Caliopen, améliorer la confidentialité de ses communications ne sera pas la fonctionnalité principale : d'abord on attire l'utilisateur par l'agrégation de ses communications et une expérience utilisateur satisfaisante, ensuite on l'aide à améliorer sa sécurité ;
- Les indices de confidentialité permettent de retrouver une notion perdue avec le numérique : étudier l'aspect d'une enveloppe voire celui des enveloppes scellées par le sceau royal permettait d'attribuer un niveau de confidentialité à son courrier. Exemples d'indices évalués : chiffrement de bout en bout, chiffrement des métadonnées (TLS), utilisation d'un protocole acentré, utilisation d'un service sécurisé (pas un ordinateur dans un cybercafé à l'étranger, double authentification, etc) ;
- Sur un terminal jugé de faible confidentialité, Caliopen affichera uniquement les messages d'un niveau de confidentialité faible. L'utilisateur pourra contourner cela, mais il perdra des points, et ses correspondants seront informés que tels messages sont devenus moins confidentiels, ceci afin de prendre conscience qu'il n'y a pas que lui dans une conversation et que le choix de sacrifier la confidentialité devrait être discuté ;
- Caliopen utilisera DANE OpenPGP pour la diffusion et la récupération des clés publiques de chiffrement. Car les serveurs de clés OpenPGP sont compliqués à utiliser, qu'ils peuvent être submergés (xxxx clés soumises par un attaquant pour un même utilisateur) et que les certificats S/MIME dépendent d'autorités de certification qui ont montré leurs faiblesses ;
- Un projet d'échange des clés publiques par le protocole d'envoi des mails (SMTP) a échoué sa normalisation : SMTP and SUBMISSION Service Extensions For Address Query. Selon moi, sa sécurité repose sur DANE TLSA qui permet de protéger un échange STARTTLS, donc autant utiliser DANE OpenPGP ;
- Un RFC normalise le format des indices de confidentialité dans l'entête des emails ;
Le SDN pour les nuls
Une causerie sur les solutions de réseaux informatiques programmés (Software Defined Network - SDN).