Tanguy Ortolo

• Contenu : explications sur la cryptographie, SSL et PGP puis signing-party
• Lieu : EPN la Bourdonnais, 105 avenue de la Bourdonnais, 75007 Paris
• Date : 2012-05-21 18:45+02:00
• Durée : 02:15

Le lundi 21 mai au soir, à Paris, se tiendra une conférence organisée par Parinux, où j'expliquerai les principes de base de la cryptographie et leur application dans les systèmes SSL et PGP. Cette conférence sera suivie par une signing-party PGP et CAcert.

Pour le déroulement de la signing-party, je vous demanderai de :

1. générer un paire de clefs si vous n'en avez pas déjà une ;
2. m'envoyer votre clef publique et vous inscrire ;
3. imprimer quelques exemplaires de votre empreinte de clef ;
4. imprimer la liste des participants que je vous enverrai ;
5. venir munis de tout cela ainsi que d'un stylo et d'une ou deux pièce d'identité.

Read more Signing-party et conférence crypto

Je n'ai probablement rien à vous apprendre apprendre au sujet de l'affaire Copwatch Nord-Paris IDF elle-même : le ministère de l'Intérieur, plutôt que d'attaquer l'auteur de ce site Web qui est parfaitement identifiable, a obtenu d'ordonner aux fournisseurs d'accès principaux de le censurer. Cette censure, qui sera effectuée par manipulation du système de nom de domaine ou DNS, donne l'occasion d'étudier un cas d'utilisation de ce système.

Deux cas en un

Lorsqu'on se penche sur ce cas, on constate qu'il est double. En effet, la censure ordonnée aux fournisseur d'accès n'est pas encore en place, néanmoins maints internautes éprouvent déjà des difficultés à accéder à ce site Web. En fait, comme WikiLeaks avant eux, Copwatch ont commis sans s'en rendre compte une erreur technique qui dégrade fortement leur service, probablement en prenant des mesures de défense d'urgence.

Deux cas à étudier donc : l'erreur de Copwatch et méthode de censure. Nous allons nous concentrer sur l'erreur de Copwatch, le sujet de la censure par DNS étant déjà amplement couvert par ailleurs.

Read more DNS : le cas Copwatch

Supposons que vous vouliez publier des fichiers volumineux à l'usage de plusieurs correspondants, par exemple un album de photos. Le protocole de distribution pair-à-pair BitTorrent est probablement la solution la plus appropriée pour cela.

La distribution de fichiers avec BitTorrent nécessite traditionnellement un traqueur, serveur indiquant aux clients les adresses d'autres utilisateurs disposant des fichiers demandés. Cela implique donc de mettre en place son propre traqueur ou de sous-traiter ce service à un prestataire tiers.

Le protocole BitTorrent a depuis été étendu pour permettre de publier des fichiers sans traqueur, en utilisant à la place les services coordonnés de l'ensemble des utilisateurs BitTorrent sous la forme d'une table de hachage distribuée : en pratique, des fichiers distribués sans traqueur sont en réalité traqués par un utilisateurs quelconque — qui n'est d'ailleurs pas forcément personnellement intéressé par ces fichiers.

La table de hachage distribuée permet donc de supprimer la dépendance à un serveur, au prix d'un contrôle inférieur et d'une sécurité moindre. Pour autant que j'ai pu l'essayer, cela fonctionne correctement.

Read more Publier des fichiers avec BitTorrent

Essai de la DHT BitTorrent

Il y a un mois, constatant qu'il manquait un bon logiciel traqueur BitTorrent (bon signifiant « remplissant mes critères arbitraires »), j'envisageai d'écrire un nouveau traqueur. Quelqu'un me fit alors remarquer que je pouvais essayer d'utiliser la table de hachage dynamique ou DHT, une extension BitTorrent qui permet de se passer d'un traqueur, en se reposant sur l'ensemble des clients BitTorrent pour effectuer le travail de traque.

De fait, la DHT pourrait bien être une solution élégante à ce problème, parce qu'elle présente plusieurs avantages :

• elle repose sur les clients BitTorrent eux-mêmes, qui sont bien plus répandus que les traqueurs, et par conséquent plus développés ;
• cette fonctionnalité semble être assez bien adoptée par les logiciels clients BitTorrent usuels ;
• elle existe déjà et semble fonctionner plutôt bien !

J'étais donc parti pour essayer la distribution de torrents sans traqueur en utilisant la DHT. Mais avec BitTorrent, la distribution d'un fichier est amorcée en utilisant des fichiers métainfo, communément appelés « fichiers torrent » ou simplement « torrents » : j'avais donc besoin d'un outil pour générer des fichiers métainfo sans traqueur.

Écriture d'un nouveau générateur de métainfo

Je n'ai pas trouvé de tel outil. Les générateurs que j'ai trouvé n'implémentent pas cette extension et sont codés en C de façon assez complexe, ce dans quoi je ne souhaitais vraiment pas me lancer afin de les compléter. Voici donc gentorrent, un générateur de métainfo BitTorrent écrit en Python 3 et distribué sous licence AGPLv3, ce qui s'est avéré plutôt simple.

Je pense qu'il est assez rapide : il lui faut environ dix secondes pour calculer la métainfo pour un fichier d'un gibioctet. Il implémente toutes les extensions BitTorrent relatives aux fichiers métainfo, comme les torrents sans traqueur, la mise à disposition par HTTP/FTP ou les arbres de Merkle. N'hésitez pas à l'essayer et à m'envoyer des remarques, des critiques ou des suggestion de noms plus sympa.

Maintenant que j'ai un outil pour générer des torrents sans traqueur, je vais essayer la DHT de façon plus extensive et documenter cette façon de publier des fichiers. Si vous êtes intéressé par ce sujet, par exemple si vous maintenez un système de distribution basé sur l'antique BitTornado, restez en ligne.

Utilisation classique d'iptables

iptables(8)/ip6tables(8) est le principal outil de gestion du pare-feu Netfilter de Linux : c'est une commande qui permet en fait de configurer ce pare-feu en modifiant sa liste de règles. Il est le plus souvent utilisé dans des scripts shell qui effectuent une longue succession d'appels pour définir chaque règle :

# Supprimer les règles existantes
ip6tables -f

ip6tables -P INPUT DROP
ip6tables -P OUTPUT ACCEPT

ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -j ACCEPT

ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

ip6tables -A INPUT -p tcp --dport ssh -j ACCEPT
ip6tables -A INPUT -p tcp --dports smtp -j ACCEPT
[…]

Cette approche souffre de plusieurs défauts :

• en appelant de multiple fois la commande ip(6)tables, elle effectue beaucoup de lectures et d'écritures inutiles dans la table de règles de Netfilter ;
• si une erreur se produit pendant l'exécution du script, le pare-feu se retrouve dans une configuration à moitié appliquée.

Read more iptables-restore