Après mes trois articles Comment vérifier l'intégrité d'un fichier que l'on télécharge ?, Comment vérifier l'intégrité de Firefox quand on le télécharge ?, et Comment vérifier l'intégrité du TorBrowser quand on le télécharge ?, voici des petites explications sur comment cela marche au niveau du gestionnaire de paquets sous Debian/Ubuntu.

Rq : ce billet est une vulgarisation (et donc une simplification) ; il se veut accessible à tous et peut de ce fait contenir des approximations.

Vérification d'authenticité des paquets

Pour cette partie, je citerai le Cahier de l'administrateur Debian et plus précisément cette page http://debian-handbook.info/browse/fr-FR/stable/sect.package-authentication.html

Debian offre un moyen de s'assurer que le paquet installé provient bien de son mainteneur et qu'il n'a subi aucune modification par un tiers : il existe un mécanisme de scellement des paquets.

Cette signature n'est pas directe : le fichier signé est un fichier Release placé sur les miroirs Debian et qui donne la liste des différents fichiers Packages (y compris sous leurs formes compressées Packages.gz et Packages.bz2 et les versions incrémentales), accompagnés de leurs sommes de contrôle MD5, SHA1 et SHA256 (pour vérifier que leur contenu n'a pas été altéré). Ces fichiers Packages renferment à leur tour une liste de paquets Debian et leurs sommes de contrôle, afin de garantir que leur contenu n'a pas lui non plus été altéré.

La gestion des clés de confiance se fait grâce au programme apt-key, fourni par le paquet apt. Ce programme maintient à jour un trousseau de clés publiques GnuPG, qui sont utilisées pour vérifier les signatures des fichiers Release.gpg obtenus depuis les miroirs Debian. Il est possible de l'utiliser pour ajouter manuellement des clés supplémentaires (si l'on souhaite ajouter des miroirs autres que les miroirs officiels) ; mais dans le cas le plus courant, on n'a besoin que des clés officielles Debian, qui sont automatiquement maintenues à jour par le paquet debian-archive-keyring (qui installe les trousseaux de clés dans /etc/apt/trusted.gpg.d).

On voit donc ici que GPG est utilisé pour valider la signature des différents paquets. Quand on ajoute un nouveau dépôt (de backport par exemple), c'est pour celà qu'il faut également télécharger la clef publique du dépôt, car elle est utilisée pour valider et vérifier l'intégrité des paquets .deb qui sont téléchargés.

Si quelqu'un modifie les fichiers sans modifier la signature et la clef fournie, le fichier sera considéré comme corrompu. Ce n'est pas une sécurité ultime, mais cela apporte un peu plus de sécurité qu'un simple téléchargement sans qu'aucune vérification ne soit faite.

Debsum

debsums Vérifie les fichiers des paquets Debian installés grâce à une liste des sommes de contrôle MD5 de /var/lib/dpkg/info/*.md5sums. debsums peut générer des listes de sommes de contrôle à partir des archives deb pour les paquets n'en possédant pas.

Autre programme, debsums. Intéressant, mais comme il est précisé dans la page de man debsums est d'une utilité limitée en tant qu'outil de sécurité, à moins que le programme et tous les outils apparentés (dpkg, perl, Digest ::MD5, etc.) soient lancés d'un média reconnu comme sûr (comme un cédérom de secours bootable, voir l'option —root) et que les sommes de contrôle aient étés calculées à partir des fichiers .deb (—generate=all) présents sur ce média ou certifiées en utilisant l'option —md5sums."

C'est un peu le serpent qui se mort la queue : il faut lancer une version déjà vérifié de debsums et des outils Debian associés pour pouvoir valider les autres paquets déjà installés... Or les outils Debian sont eux-même installés par des paquets... Le plus simple est lors de l'installation, d'avoir validé/vérifié l'intégrité du support d'installation (iso, dvdrom...) et ensuite, on utilisera Debsum pour les paquets nouvellement installés (par installation à la demande ou mise à jour).

Je pense que la plupart des lecteurs de ce blog sont familiers avec Tor ou du moins en connaisse l'usage et le nom de ce système d'anonymisation et toute l'importance que l'usage et la défense de Tor ont pour moi. C'est pourquoi il est important pour moi de donner et relayer l'appel à dons pour la campagne de 2015 de l'association Nos Oignons.

Participez au réseau Tor en soutenant l'association Nos oignons, c'est soutenir une équipe de personnes motivées, sympathiques, oeuvrant dans l'ombre chaque jour pour fournir des noeuds supplémentaires (et maintenir les noeuds déjà en place). C'est soutenir l'infrastructure du réseau Tor et permettre à des millions de personnes de part le monde d'avoir un outil leur permettant d'avoir un peu plus de vie privée ou d'être en sécurité quand elles vont sur Internet.

La page d'appels aux dons explique tout en détail sur le pourquoi soutenir et donner, comment donner etc. De même que le site de NosOignons en lui-même donne beaucoup d'informations sur leurs activités.

Je tiens à remercier personnellement toute personne qui fera un don car en donnant, vous nous aidez chaque jour à avoir un réseau Tor qui continue. Alors MERCI à vous, généreux donateurs. Et que vous donniez ou pas, relayez l'information d'appels à dons, sensibilisez sur les usages POSITIFS et la nécessité du réseau Tor. Merci.

Série de liens
NosOignons - Appels à dons
NosOignons - Appels à dons English Version
Le site de NosOignons

Comment les paquets reçus par le noeud de sortie sont-ils routés vers le poste source, via le circuit Tor ?

Prerequis :
Connaitre le principe de routage et le principe de Tor (routage en oignon)
Savoir ce qu'est un paquet (avoir des notions de réseau, TCP/IP).

Le chemin aller sur Tor (connexion à un serveur web depuis le TorBrowser) est bien documenté, avec des schémas sur le routage en oignon. Mais qu'en est-il du chemin de retour ? Comment les paquets reçus par le noeud de sortie sont-ils routés vers le poste source, via le circuit Tor ? C'est cette question que je me suis posé et la réponse n'est pas facile à trouver. J'ai discuté avec pas mal de monde et la réponse exacte n'est pas claire. Je livre ici une version/interprétation plausible

Sur How are packets received by a Tor exit node routed back through the Tor circuit ?, la réponse donnait apportait des éclaircissements et j''ai donc librement traduit les réponses, en complétant le texte avec mes propres explications, pour en faire le texte qui suit.

Le chemin aller

Après sélection des différents "noeuds-relais" dans le réseau, le client effectue un échange de clés de sessions (Diffie-Hellman). Il y a une première clé de chiffrement pour le nœud d'entrée, une second clé pour le nœud du milieu et une dernière pour le nœud de sortie. Chaque noeud envoit donc une clé de session. Le premier noeud envoie sa clé au client. Le deuxième noeud envoie sa clé au 1er noeud qui la chiffre avec la clé négocié avec le client et l'envoie au client. Idem pour le troisième noeud (qui envoit de sa clé au 2nd noeud...)

Le client chiffre le paquet avec les 3 clés de session, l'envoie au 1er noeud qui pèle la première couche, qui l'envoie au deuxième noeud qui pèle la deuxième couche de chiffrement, et ainsi de suite jusqu'au noeud de sortie.

Le chemin de retour

Tor fonctionne comme une chaîne de proxys, où chaque proxy ne connait que le prochain saut et le saut précédent. Une fois que le serveur web a traité la réponse (demande d'affichage d'une page par exemple), il renvoie le paquet de réponse au noeud de sortie (étant donné que le noeud de sortie est vue comme l'ordinateur s'étant connecté au serveur web). Le nœud de sortie utilise une table (un équivalent d'une table NAT, mais avec plus d'informations) qui lui permet de décider d'où renvoyer la réponse. Le noeud de sortie chiffre de nouveau le paquet et l'envoie au noeud suivant, le noeud intermédiaire, qui fera alors la même chose, jusqu'à ce que le paquet atteigne votre ordinateur, où le paquet et alors déchiffré au niveau local et envoyé à l'application (le Tor Browser). Formulé autrement, lorsque les données sont envoyées à vous, la chaîne est inversée le noeud de sortie devient le premier noeud et votre ordinateur devient alors le noeud de sortie.

Point à valider - vérifier
Pour le chemin inverse, le dernier noeud chiffre avec sa clé de session, le passe au noeud d'avant qui chiffre aussi avec sa clé de session, jusqu'à remonter au client qui déchiffre les couches avec les clés qu'il a reçu lors de la construction du circuit.

Il est important de comprendre que le chiffrement se fait par trois fois : chaque noeud du chemin de retour chiffre avec la clef de session symétrique qu'il a en commun avec le client Tor. Le paquet qui arrive au niveau du client au retour est donc chiffré 3 fois. (3 fois ou une seule fois avec seulement la clef du noeud de sortie, la question demeure et je cherche "encore" la réponse exacte)

Dit autrement, à l'aller, on pèle les couches de l'oignon. Au retour, on reconstruit un oignon en ajoutant des couches. C'est ce que l'on voit bien sur ce type de schéma : on a bien trois couche de chiffrement au niveau de l'aller et du retour côté client.

(Trois couches ou une seule, selon que l'on rechiffre trois ou une fois, ce n'est pas clair).

Etude du flux de paquets

Les nœuds intermédiaires n'attendent pas que toutes les données soient disponibles avant de les envoyer à la prochaine étape, sinon télécharger des fichiers de plusieurs Mo serait une corvée. Au lieu de cela, ils ont un espace de mémoire tampon limité, et chaque fois que la mémoire tampon se remplit (ou un délai d'attente se produit), ils chiffrent et envoient au noeud suivant.

L'application croit que le serveur distant est le client Tor, elle a seulement besoin de savoir faire le transfert de paquet jusqu'au premier noeud. Le serveur Web de destination pense quant à lui que le noeud de sortie est le client. Tous les nœuds intermédiaires vont reconnaître leurs paquets, comme s'il y avait une connexion point-à-point entre eux.

Rappelez-vous que Tor ne fait pas qu'office de proxy HTTP, il fonctionne également à un niveau inférieur et fait office de proxy pour les connexions TCP, ce qui signifie que le nœud ne peut pas savoir quand il a « toutes les données ».

De plus le protocole HTTP 1.1 permet de faire plusieurs demandes par connexion, et lorsque l'on utilise une connexion HTTPS, la poignée de main TLS impliquent déjà plusieurs allers-retours. De même, il y a des protocoles qui sont conçus pour de multiples commandes et réponses (par exemple, SMTP ou IMAP), et puis il y a des protocoles où les deux parties peuvent envoyer des données à tout moment à l'autre (par exemple, SSH ou IRC)...

Sur LinuxFr, le journal Sexisme ordinaire sur Linuxfr a suscité de très longues discussions et débats sur le sexisme et après avoir lu une centaine de commentaire, j'ai décidé de ne pas participer. Car je n'avais pas le temps de répondre au message que j'aurai laissé et je me serais très vite énervé...

En résumé, il y tout un pseudo débat qui a pour origine l'usage du mot Waf. Si on regarde la définition Wikipedia, il est dit Ce terme dérive du stéréotype machiste que les hommes sont attirés par les gadgets, voitures et la hifi, et les femmes par l'esthétique et le visuel des lieux à vivre. Il désigne la compatibilité entre l'utilité d'un objet qualifié de masculin par stéréotype (typiquement les équipements informatiques, hi-fi ou vidéo) et les contraintes d'aspect, bruit, ou encombrement (câbles, nuisances sonores).

Comme il est dit dans la définition, c'est un stéréotype machiste. L'utiliser, est, pour moi, contribuer au maintien de ce stéréotype et le renforcer. Qu'importe les argumentations en faveur du type "dans mon entourage les technophiles sont tous des hommes" qui se contentent de regarder les faits, pas de les comprendre. Posez-vous juste la question : Pourquoi les technophiles ne sont pas des femmes : elles sont exclues des communautés technophiles, dès l'enfance on leur fait comprendre que c'est un truc de garçon...

Surtout, ce qui m'a le plus gêné dans ce débat : il est tenu par une majorité d'homme. Longtemps que les femmes ne sont plus sur ce site, parce que ce lieu n'est pas safe et que le niveau des débats ne fait que renforcer l'ambiance malsaine. Chacun ramène à lui le débat : oui mais les hommes aussi sont victimes de sexisme, c'est de l'humour etc. et autres argumentations lu et relue que les sites féministes de qualité démontent très bien point par point.

Le débat est faussé dès le départ car tant qu'on n'a pas compris qu'en tant qu'homme blanc on avait des privilèges, on ne peut pas participer au débat. En tant qu'homme, je ne SAIS pas ce qu'est le sexisme. Oui il y a du sexisme envers les hommes, mais il est infime et bien plus supportable que celui que vive au quotidien des milliards de femmes. Allez relire mon billet Ce dont je ne peux pas parler... mais ce sur quoi j'ai un avis, où j'évoque le fait je suis un privilégié, que je le sais. Et faites de même sur vos vies personnelles : regardez ce que vous avez comme chance. Regardez l'image que la société renvoie de vous, vous impose... Et essayez de comprendre pourquoi j'exècre le terme de WAF : dans mon foyer, c'est Ryo-Oki aka MmeGenma qui est la plus technophile, et nous décidons EN COMMUN des objets technologiques que nous achetons/nous procurons. Elle a eu la chance d'avoir des parents ouverts d'esprits et non enfermés dans les stéréotypes....

Si vous intéressez au sujet du féminisme ou que vous souhaitez découvrir ce domaine, écoutez le dernier numéro du podcast Bazingcast #42 « De la fin, de l'humour grâce à ces dames ». J'ai adoré l'intervention de Myroie et son débat avec Krilin. Le débat dérive de l'humour pour parler de féminisme, il faut comprendre le vocabulaire associé (oppresseur, privilèges etc.) et si vous n'êtes pas famillié avec ça, ne vous inquiétez pas. Car je reparlerais de ce sujet qui me tient à coeur, en le vulgarisant comme je sais si bien le faire pour les sujets qui me tiennent à coeur !

Les bases de données NoSQL et le Big Data par Rudi Bruchez aux Editions Eyrolles

Présentation de l'éditeur

En quelques années, le volume des données brassées par les entreprises a considérablement augmenté. Émanant de sources diverses (transactions, comportements, réseaux sociaux, géolocalisation...), elles sont souvent structurées autour d'un seul point d'entrée, la clé, et susceptibles de croître très rapidement. Autant de caractéristiques qui les rendent très difficiles à traiter avec des outils classiques de gestion de données. Par ailleurs, certains cas d'utilisation exigeant des temps d'accès très courts défient également les capacités des moteurs transactionnels. C'est pour répondre à ces différentes problématiques que sont nées les bases de données NoSQL (Not Only SQL), sous l'impulsion de grands acteurs du Web comme Facebook ou Google, qui les avaient développées à l'origine pour leurs besoins propres. Grâce à leur flexibilité et leur souplesse, ces bases non relationnelles permettent en effet de gérer de gros volumes de données hétérogènes sur un ensemble de serveurs de stockage distribués, avec une capacité de montée en charge très élevée. Elles peuvent aussi fournir des accès de paires clé-valeur en mémoire avec une très grande célérité. Réservées jusqu'à peu à une minorité, elles tendent aujourd'hui à se poser en complément du modèle relationnel qui dominait le marché depuis plus de 30 ans.

Cet ouvrage d'une grande clarté dresse un panorama complet des bases de données NoSQL, en analysant en toute objectivité leurs avantages et inconvénients. Dans une première partie, il présente les grands principes de ces bases non relationnelles : interface avec le code client, architecture distribuée, paradigme MapReduce, etc. Il détaille ensuite dans une deuxième partie les principales solutions existantes (Hadoop, MongoDB, Cassandra, CouchDB...), en précisant spécificités, forces et faiblesses de chacune. Complétée par une étude de cas réel, la dernière partie du livre est consacrée au déploiement concret de ces bases : dans quel cas passer au NoSQL ? quelle base adopter selon ses besoins ? quelles données basculer en NoSQL ? comment mettre en place une telle base ? comment la maintenir et superviser ses performances ?

Les bases de données NoSQL et le Big Data par Rudi Bruchez aux Editions Eyrolles sur le site de l'éditeur Eyrolles.

La critique du Genma

D'après la description sur le site de l'éditeur, cet ouvrage s'adresse aux experts en bases de données, architectes logiciels, développeurs... ainsi qu'aux chefs de projet qui s'interrogent sur le passage au NoSQL. Effectivement, pour une personne qui comme moi chercherait à faire de la veille technologique et s'intéresserait au concept de NoSQL, ce livre est une bonne entrée en matière. Les premiers chapitres seront intéressants et permettent de répondre aux questions que l'on peut se poser et aider à comprendre ce qu'est-ce qu'une base NoSQL , NoSQL versus SQL : quelles différences... La deuxième partie présente un panorama des principales bases de données NoSQL (Hadoop, CouchDB, MongoDB, Riak, Redis, Cassandra) Enfin la troisième partie se consacre à la mise en oeuvre d'une base de données NoSQL, avec des conseils quand aux choix de la base, la mise en place de la solution, maintenance et supervision d'une base NoSQL, pour finir par une étude de cas.

Pour faciliter la lecture, la connaissance du moins la compréhension des langages JSON, Python et des commandes shell peut être un prérequis si l'on souhaite comprendre les exemples sous forme de code source, script et autres exemples de configuration et paramétrage ou d'analyse des fichiers journaux/logs (par exemple).

Ce livre est assez complet et permettra donc d'avoir un bon aperçu de ce que sont les bases de données SQL et le Big Data. Pour approfondir le sujet, restera alors à se lancer dans un projet, de choisir la base de données et on se tournera alors vers un ouvrage spécialisé sur cette base de données (pour avoir des tutoriels, des exemples précis de fichier de configurations etc).