lalahop
Categorie: Divers

Mon shaarli : 2 ans plus tard

Cela fait un peu plus de 2 ans que j'utilise l'application web shaarli (« The personal, minimalist, super-fast, no-database delicious clone », un gestionnaire de favoris en ligne et plus que ça). Il est temps de faire un point.

D'abord, il faut remarquer que mon shaarli est devenu mon principal support d'expression sur le web, loin devant ce blog. Ainsi, je vous conseille d'aller y faire un tour, voire de suivre le flux RSS. Je shaarli systématiquement mes billets de blog donc il est inutile de suivre les deux flux RSS : suivez shaarli. 😀

Ensuite, voyons si shaarli m'a aidé à remplir les objectifs que je m'étais fixés et qui sont exposés dans le billet suivant : Mon Shaarli :

  • Partager beaucoup plus de documentation, d'avis et de retours d'expérience : 949 shaarlis en un peu plus de 2 ans, je pense que cet objectif est atteint même si des shaarlis pointent vers du divertissement. Je suis au maximum en ce qui concerne la documentation et les retours d'expérience : je partage toutes les technos/techniques/bonnes_documentations que je découvre/manipule/mets_en_production. De plus, j'ai entraîné (à minima 😀 ) Johndescs et b4n qui, tout comme moi, documentent/font_circuler plus de choses qu'avant.
  • Réactions à l'actualité et aux déclarations de ceux qui ont le droit au chapitre par copinage et tradition : objectif beaucoup moins bien atteint. Je m'interroge toujours autant sur la pertinence de réagir à des effets d'annonce et/ou à des projets futurs encore flous de type "machin a dit que ceci ou cela sera peut-être fait", "tel texte de loi pourrait émerger",… Pour moi c'est entre nécessité de réagir pour ne pas les laisser faire n'importe quoi sous couvert de notre accord tacite et contribution inutile à un bruit ambiant totalement stupide et contre-productif…

Enfin, la seule ombre au tableau est que mon shaarli reste 4 fois moins fréquenté que ce blog. Je ne sais pas si c'est la structure d'un shaarli qui ne plaît pas aux moteurs de recherche ou si c'est le fait d'avoir utilisé un domaine différent (qui fait que la réputation attribuée par les algorithmes repart de zéro). Non pas que j'ai envie d'être une vedette du web ou que sais-je mais juste que je me demande comment diffuser toujours plus les infos/contenus/savoirs à toujours plus de personnes : ai-je fait le maximum pour que mon contenu atteigne toutes les personnes qui pourraient être intéressées ?

En conclusion : viendez sur mon shaarli car ce blog, même s'il est loin de disparaître, est secondaire dans mes supports d'expression sur Internet. Je vous encourage vivement à installer votre propre instance de shaarli et à contribuer à diffuser savoir/avis/retour_d'expérience/bonne_humeur/que_sais-je. C'est juste vital. Un gros GG à Sebsauvage, l'auteur de ce logiciel. GG pour une application totalement fonctionnelle qui juste marche sans prendre la tête et GG pour un support d'expression qui libère, en tout cas, qui me correspond et me libère. \o/

Ma première (vraie) clé PGP

Je me suis sérieusement mis à OpenPGP. C'était dans ma TODO depuis trop longtemps. Ce billet regroupe juste mes réflexions, ma manière de faire et les différentes lignes de commandes extraites du man qui pourront m'être utiles un jour. Rien d'innovant en soi.

Ce billet devait être un shaarli à l'origine mais vu sa longueur, il a atterri ici.

Attention : ce billet n'est ni de la vulgarisation ni une source d'information 100 % fiable. Il s'agit juste d'un retour d'expérience et de quelques notes d'un n00b qui s'est penché sur le sujet.

Voici la documentation que j'ai utilisée :

Table des matières

Introduction

D'abord, il faut faire la différence entre OpenPGP (la norme, RFC 4880) et les différentes implémentations disponibles (PGP, GnuPG, GPG4Win, ...).

ÉDIT du 30/05/2016 à 16h00 : Dans ce billet de blog, je vais traiter exclusivement de GnuPG (+ Enigmail comme frontend) c'est-à-dire l'implémentation disponible sous GNU/Linux. Pour les utilisateurs-trices de Windows, je vous renvoie vers le tuto de Zythom (partie 1, partie 2 et partie 3) d'une part et vers les explications de Numérama d'autre part. Je vous rappelle néanmoins qu'il ne peut pas y avoir de sécurité sur un système fermé, c'est-à-dire un système dont personne (sauf Microsoft) n'a le code source et ne sait donc comment il fonctionne. Le logiciel libre apporte des garanties supplémentaires nécessaires (mais pas suffisantes, mais c'est toujours mieux). Fin de l'édit.

Ensuite, il faut assimiler qu'on ne désigne pas une clé par son ID (identifiant) qu'il soit court ou long mais par son empreinte (fingerprint), pour des raisons de sécurité : « Short OpenPGP Key IDs, for example 0×2861A790, are 32 bits long. They have been shown to be easily spoofed by another key with the same Key ID. Long OpenPGP Key IDs (for example 0xA1E6148633874A3D) are 64 bits long. They are trivially collidable, which is also a potentially serious problem. If you want to deal with a cryptographically-strong identifier for a key, you should use the full fingerprint. You should never rely on the short, or even long, Key ID. ». Source : OpenPGP Best Practices.

Générer une paire de clés

ÉDIT du 30/05/2016 à 19h00 :

Configurer GnuPG

Avant de générer une paire de clés, la première étape est d'avoir un bon fichier gpg.conf avec les paramètres recommandés (utilisation des ID longs, affichage des fingerprint, utilisation d'un cluster de serveurs de clés interrogés avec le protocole sécurisé hkps, priorité aux algos forts, ...) car les paramètres par défaut de GPG sont… insuffisants.

Même si vous utilisez Enigmail pour générer votre paire de clés, cette étape de configuration est nécessaire !

GPG version 1.X ou GPG version 2.X ?

Pour l'usage quotidien, peu importe. gpg ou gpg2 fonctionnent de la même manière, avec les mêmes commandes, respectent la même norme. Parmi les différences, citons : la version 1 est monolithique (un seul binaire qui fait tout) alors que la version 2 délègue du taff : dirmngr pour l'accès aux serveurs de clés, libgcrypt pour les opérateurs cryptographiques,… D'après le manuel, la version 2 est plus adaptée pour les environnements graphiques alors que la version 1 est plus adaptée pour les utilisations en ligne de commande et les utilisations automatiques. Les versions 2.X récentes apportent le support de S/MIME et la gestion des courbes élliptiques.

Sous Debian GNU/Linux, gpg et gpg2 sont deux binaires différents qui co-habitent. Sous ArchLinux, gpp pointe sur gpg2.

En revanche, ce qui va différer, c'est le bout de configuration concernant les serveurs de clés : si l'on utilise gpg2, il faut créer un fichier ~/.gnupg/dirmngr.conf (si le dossier caché .gnupg n'existe pas, on le crée) avec le contenu suivant en plus du fichier gpg.conf qu'on va créer plus loin :

hkp-cacert /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem

Il faudra également vérifier que le logiciel dirmngr est bien installé, avec apt-get, par exemple :

apt-get install dirmngr
Configuration commune à GPG version 1.X et GPG version 2.X

Ensuite, il faut créer un fichier texte ~/.gnupg/gpg.conf (si le dossier caché .gnupg n'existe pas, on le crée) avec le contenu suivant :

# Options for GnuPG
 
## Générales (https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf)
# Uncomment the following option to get rid of the copyright notice
no-greeting
 
# Disable inclusion of the version string in ASCII armored output
no-emit-version
 
# Disable comment string in clear text signatures and ASCII armored messages
no-comments
 
 
## Crypto preferences (http://www.bortzmeyer.org/nouvelle-cle-pgp.html et https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf)
# list of personal digest preferences. When multiple digests are supported by
# all recipients, choose the strongest one
personal-cipher-preferences AES256 AES192 AES
 
# list of personal digest preferences. When multiple ciphers are supported by
# all recipients, choose the strongest one
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
 
# For the keys we create / message digest algorithm used when signing a key
cert-digest-algo SHA512
 
# For the signatures and other things we generate
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES ZLIB BZIP2 ZIP Uncompressed
 
 
## Serveur de clés (https://help.riseup.net/en/security/message-security/openpgp/best-practices#selecting-a-keyserver-and-configuring-your-machine-to-refresh-your-keyring)
# sks-keyservers.net mieux car checks de bon fonctionnement réguliers et hkps > *
keyserver hkps://hkps.pool.sks-keyservers.net
 
# https://sks-keyservers.net/sks-keyservers.netCA.pem
keyserver-options ca-cert-file=/etc/ssl/certs/hkps.pool.sks-keyservers.net.pem
 
# When creating a key, individuals may designate a specific keyserver to use to pull their keys from. 
# It is recommended that you use the following option to ~/.gnupg/gpg.conf, which will ignore such designations :
keyserver-options no-honor-keyserver-url
 
 
## Affichage des clés (https://help.riseup.net/en/security/message-security/openpgp/best-practices#selecting-a-keyserver-and-configuring-your-machine-to-refresh-your-keyring)
# Format long. Short OpenPGP Key IDs, for example 0×2861A790, are 32 bits long. They have been shown to be easily spoofed by another key with the same Key ID.
keyid-format 0xlong
 
# Long OpenPGP Key IDs (for example 0xA1E6148633874A3D) are 64 bits long. They are trivially collidable. If you want to deal with a cryptographically-strong identifier for a key, you should use the full fingerprint. You should never rely on the short, or even long, Key ID.
with-fingerprint

Attention : pour pouvoir utiliser le protocole sécurisé d'échange de clés hkps, et si vous utilisez GPG 1.X, il faut installer le package « gnupg-curl ».

Attention : dans tous les cas (gpg 1.X ou 2.X), il faut récupérer le certificat x509 de sks-keyservers.net dispo en https://sks-keyservers.net/sks-keyservers.netCA.pem pour le stocker en /etc/ssl/certs/hkps.pool.sks-keyservers.net.pem .

Fin de l'édit du 30/05/2016 à 19h00.

Réellement générer votre paire de clés

À partir d'ici, vous pouvez utilisez Enigmail à la place des commandes barbares que je propose ci-desous à condition d'utiliser une version d'Enigmail >= 1.8 ! Les versions inférieures générent des clés insufissantes pour 2016..

  • Générer une paire de clés :
    gpg --gen-key

    ÉDIT du 02/11/2014 à 16h00 : Choisir : RSA et RSA, une taille de 4096 octets. ÉDIT du 30/05/2016 à 14h30 : 4096 est une bonne taille encore aujourd'hui puisque l'ANSSI, via son référentiel général de sécurité (RGS) (document B1) indique que 2048 bits sont le minimum aujourd'hui pour des clés RSA et que 3072 bits sont recommandés. La NSA indique 3072 bits minimum. Donc 4096 bits, c'est tout bon. Fin de l'édit du 30/05/2016.

    Ensuite, il faut préciser une date d'expiration d'un maximum de 2 ans. Cette date d'expiration, qui peut être vu comme étant facultative (si un certificat de révocation a été généré et stocké en lieu sûr, voir ci-dessous), ajoute pourtant une sécurité supplémentaire : si vous avez toujours votre clé privée, vous pourrez reporter la date d'expiration même après l'expiration (sans vous refaire une nouvelle paire de clés). Si vous n'avez plus votre clé privée (vol (copie + suppression quoi), compromission) et que vous n'avez pas généré le certificat de révocation (ou que vous l'avez perdu), alors vos correspondances et vos correspondants sont potentiellement menacés et la date d'expiration permet de réduire la durée d'exposition au danger de vos correspondants. L'expiration est aussi un moyen de résoudre les nombreux dysfonctionnements "par design" de la révocation dont le fait qu'il faut que tous vos contacts mettent à jour leur trousseau de clés pour que la révocation devienne effective. Retenez donc que l'expiration n'a rien en commun avec la révocation : la première est une sécurité (qui peut être contournée si elle s'active), la deuxième est définitive (une clé révoquée ne revient pas à la vie, en gros). Fin de l'édit du 02/11/2014.

    ÉDIT du 30/05/2016 à 20h15 : Ne pas indiquer de commentaire, c'est juste stupide / sans intérêt dans la plupart des cas…

    Saisissez une phrase de passe secrète solide car c'est sur elle que reposera la sécurité de vos échanges futurs. Pour qu'elle soit solide et mémorisable, utilisez la méthode Diceware avec un minimum de 5 mots qui n'ont rien à voir entre eux. De manière humoristique (mais tout à fait sérieux dans le fond), voir : https://xkcd.com/936/. Fin de l'édit.

  • Si la clé doit couvrir/fonctionner pour plusieurs "identités", notamment plusieurs adresses mails :
    gpg --edit-key "<fingerprint>"

    puis commande « adduid » pour ajouter toutes les identités/mail puis GnuPG: Selecting A Primary UID pour sélectionner l'identité principale. ÉDIT du 30/05/2016 à 20h05 : Évidemment, toutes les identités/adresses mails que vous joigniez à la même clé GPG marque leur appartenance à une même clé privée donc à une même personne. Donc il ne faut pas utiliser la même clé GPG pour des adresses mails que vous ne voulez pas voir mélangées (perso / pro, par exemple ou perso / identité sur les sites porno). Fin de l'édit.

  • Générer le certificat de révocation en avance et le conserver précieusement à l'abri des regards indiscrets (utile en cas de gros pépin exposant vos contacts à une usurpation de votre identité) :
    gpg -o maclepgp.revoke --gen-revoke "<fingerprint>"

    ÉDIT du 02/11/2014 à 17h05 : Toute personne en possession de ce certificat pourra révoquer votre paire de clés sans aucun contrôle (pas de demande de passphrase, par exemple) donc faites très attention ! Une révocation est définitive et elle empêchera tout ordinateur la connaissant de chiffrer des mails à votre intention ! Voir la section « Révoquer une paire de clés avec un certificat de révocation » à la fin de ce billet pour plus d'informations. Fin de l'édit.

  • Exporter la clé publique (pour un test avec une clé de test, par exemple) :
    gpg -a -o maclepgp.pub --export "<fingerprint>"

    Pour info : « -a | --armor : Create ASCII armored output. The default is to create the binary OpenPGP format. »

  • Publier la clé publique sur un serveur de clés (pour la vraie clé de production, c'est LA méthode à utiliser) :
    gpg --send-key "<fingerprint>"
  • Vous pouvez générer des sous-clés mais ce n'est pas aussi trivial que le sous-entendent les tutoriels. Pour un début, je m'en passerai. Pour la sécurité, mieux vaut des outils cryptos compris que des fonctionnalités supplémentaires incomprises. Par défaut, GPG génère une sous-clé de chiffrement en plus de la clé de signature.
  • Pensez à sauvegarder un maximum de chose : tout le dossier .gnupgp ainsi qu'un export de la clé privée :
    gpg --export-secret-keys -a -o maclepgp.private "<fingerprint>"

    et à stocker tout ça à l'abri des regards indiscrets ! Pensez à sauvegarder à chaque signature d'une clé (la votre ou celle d'autrui).

Chiffrer/déchiffrer/signer/vérifier la signature (d')un fichier

  • Chiffrer un fichier :
    gpg -ae <fichier>

    Le champ « choisir le destinataire » est un champ de recherche (accepte la fingerprint, une partie de l'identité, ...).

  • Déchiffrer un fichier :
    gpg -ad <fichier>

    Ajouter « -o » pour avoir la sortie dans un fichier au lieu de stdout.

  • Chiffrer et signer un message en même temps :
    gpg -ase <fichier>
  • Déchiffrer en vérifiant la signature : pareil qu'un déchiffrement sans signature. GPG indiquera simplement en plus s'il a réussi à vérifier la signature ou non.
  • Signer uniquement un fichier (« --clearsign » peut aussi être utile s'il faut garder le texte clair et signer à côté) :
    gpg -as <fichier>
  • Vérifier la signature (il faut bien évidemment avoir d'abord importé la clé publique correspondant à la clé privée qui a générée la signature, ce qui est le cas ici ; On voit souvent ce mécanisme avec les sources des logiciels libres sérieux) :
    gpg --verify <fichier>.(sig|asc)

Des personnes utilisent OpenPGP pour chiffrer certains de leurs fichiers qu'ils ne vont pourtant transmettre à personne (exemple : fichier de mots de passe). Est-il mieux d'utiliser OpenSSL ou GPG pour réaliser cette opération ? Je n'ai aucune réponse définitive. Pour moi, les deux outils sont équivalents. Et sur cet aspect-là, la CLI GPG est plus conviviale que la CLI OpenSSL.

ÉDIT du 30/05/2016 à 17h15 :

Stocker vos mots de passe

Hé oui, GPG vous permet de constituer un gestionnaire de mots de passe à la KeePassX : stockez vos mots de passe dedans, sous forme chiffrée. Pour accéder à votre trousseau de mots de passe, il faut votre clé privée OpenPGP et sa phrase de passe.

Le gestionnaire de mots de passe utilisant GPG que j'apprécie et que je recommande se nomme pass. Voir sur mon shaarli pour un avis détaillé : Pass: The Standard Unix Password Manager - GuiGui's Show - Liens.

Fin de l'édit.

Trouver la clé publique d'un correspondant, la vérifier et l'ajouter à votre trousseau

Méthodes pour obtenir la clé publique d'un correspondant :

  • Chercher une clé sur un serveur de clés :
    gpg --search-keys "<ID ou une partie de l'identité>"

    L'import est proposé si la recherche réussit. Il faudra vérifier la fingerprint (vérifier le lien entre une clé et son titulaire supposé) de cette clé via, au pire, l'utilisation d'un un canal alternatif (téléphone, XMPP,...) ou en se reposant sur le graphe de relations (une connaissance commune en qui vous avez confiance tous les deux qui aurait signé vos clés au préalable), au mieux : une rencontre de visu (AFK). À ce titre, je rappelle qu'une identité, en droit français, ça ne se vérifie pas nécessairement par des documents d'état civil mais aussi par au moins 2 témoignages. 😉

  • À partir d'une fingerprint :
    gpg --recv-key "<fingerprint>"

    Là aussi, il faut forcément vérifier la fingerprint.

  • À partir d'un fichier :
    gpg --import <cleducorrespondant>.asc

    Il faut vérifier la fingerprint.

Commandes utiles :

  • Voir le trousseau :
    gpg --list-keys 
    gpg --list-sigs
  • Voir la fingerprint d'une clé :
    gpg --fingerprint <keyID>
  • Supprimer une clé de votre trousseau :
    gpg --delete-key "<fingerprint>"
  • Signer une clé et lui accorder un niveau de confiance :
    gpg --edit-key "<fingerprint>"

    puis commande « sign » puis choisir un degré de confiance, normalement 3 ou 4, puis « quit ».

  • Publier le graphe des relations (les clés que vous avez signées) :
    gpg --send-key "<fingerprint>"

    Ici « fingerprint » désigne l'empreinte de chaque clé que vous avez signé puisque votre signature apparaît sur leur clé (--list-sig). Ne pas indiquer de fingerprint pousse toutes les clés sur le serveur de clés (sauf celles signées localement, voir ci-dessous). Source : Distributing keys - The GNU Privacy Handbook. Corollaire : vous devez "--refresh-keys <votre_fingerprint>" pour avoir, dans votre trousseau local, les signatures que d'autres personnes ont apposé à votre clé.

  • Il est possible de signer localement une clé, c'est-à-dire, de la signer sans que la signature soit exportée sur un serveur de clés. Cela permet de masquer une partie de votre graphe de relations. Lors d'un échange de clés, il est important de demander à votre interlocuteur s'il souhaite que vous apparaissisez dans son graphe de relations et inversement. Ça permet aussi ne pas conduire autrui (si autrui utilise le modèle de la toile de confiance) si vous souhaitez importer une clé sans faire les vérifications qui s'imposent normalement. Tout ça en évitant les demandes de confirmation (voire d'erreur) de votre MUA. Pour se faire :
    gpg --edit-key "<fingerprint>"

    puis juste les commandes « lsign » et « quit ».

  • Grâce à la toile de confiance, il est possible pour deux interlocuteurs ayant une (ou plusieurs) relations en commun (qui ont signées leurs clés) de vérifier leurs identités respectives sans pour autant avoir communiqué sur un canal sécurisé. On notera qu'utiliser ce mécanisme nous rend vulnérables aux vérifications effectuées par les relations communes : comment ont-elles signé les clés ? Selon quels critères ? Peut-on vraiment avoir confiance en leur process ? Il est donc de l'appréciation de chacun de recourir ou non à la toile de confiance.
  • ÉDIT DU 10/06/2016 À 19H40 : Visualiser votre graphe de relations / votre toile de confiance en utilisant sig2dot . FIN DE L'ÉDIT.

Chiffrer/déchiffrer/signer/vérifier la signature (d')un mail

Comme j'utilise principalement Icedove, j'ai pris la bien connue extension enigmail. Installée via apt-get puis chargée automatiquement après un redémarrage d'Icedove. L'assistant est convivial, rien à détailler. ÉDIT du 30/05/2016 à 15h30 : Ce n'est pas une bonne idée : sous Debian Wheezy, on avait Enigmail 1.7.X alors que la version 1.8 apportait d'énormes changements (rsa 4096 par défaut, expiration = maintenant + 5 ans, proposition appuyée pour faire générer le certificat de révocation, etc.). Il vaut donc mieux installer l'extension comme toute extension, depuis addons.mozilla.org. Fin de l'édit.

ÉDIT du 30/05/2016 à 15h30 : Attention, le couple Thunderbird+Enigmail n'est pas forcément le plus sécurisé.

D'une part, Enigmail est une extension de Thunderbird, ce qui signifie que les fonctionnalités qu'elle apporte n'ont pas été prévues par les développeurs-euses de Thunderbird, ce qui signifie qu'Enigmail est un contournement crade du cheminement normal de l'envoi d'un mail avec Thunderbird : Enigmail intercepte l'envoi d'un mail, fait sa tambouille, ré-injecte le mail à envoyer. Même si ça fonctionne, ce comportement n'est pas sain.

D'autre part, le format d'un mail, le format MIME, est démoniaque. Un mail est toujours composé d'une partie entêtes et d'une partie corps mais le corps peut être subdivisé. C'est le cas quand il y a un message + une pièce jointe ou quand le mail est envoyé dans une version texte ET dans une version HTML pour plaire à tout le monde. C'est aussi le cas quand un mail est chiffré ou signé avec PGP et qu'on utilise PGP/MIME : la signature / le texte chiffré est dans un compartiment séparé logé dans le corps du mail. Là où ça se complique, c'est que l'enchaînement et l'imbrication de parties MIME peuvent aller assez loin. L'ennui, c'est qu'Enigmail informe très mal de quelles parties du mail sont chiffrées / signées. Exemple bateau : rédiger un mail au format plain/text, coller un blob PGP au milieu, Engimail avertira que TOUT le mail est signé alors que seul le blob PGP l'est. Ça peut amener à des tromperies des utilisateurs-trices du genre le corps du mail, celui qui s'affiche, que l'utilisateur lit, est nullement signé, seule un autre compartiment dans le mail l'est donc l'utilisateur-trice n'a aucune garantie sur l'authenticité et l'intégrité du corps du mail qu'il-elle lit ! Exemple concret ici : KMail indique clairement les parties qu'il n'a pas traité alors qu'Enigmail affiche le bandeau vert "toutVaBien".

Bref, notons que chaque logiciel mail dispose de son propre frontend à PGP et que tous ne se valent pas.
Fin de l'édit.

Enigmail fait le travail de déchiffrement et/ou vérification des signatures automatiquement à la réception d'un mail :

  • Si vous obtenez le message « Message déchiffré; Signature non vérifiée; cliquez sur l'icône « stylo » », ne cherchez pas l'icône stylo mais cliquez sur « détails » à droite de ce bandeau d'information. Vous n'avez pas la clé publique de votre correspondant dans votre trousseau.
  • Si vous obtenez le message « [...] Signature non certifiée [...] », alors vous n'avez pas signé la clé publique de votre correspondant.
  • « Message déchiffré; Signature correcte de [...] ». Tout est ok \o/ .
  • Je n'ai pas encore rencontré les autres messages (déchiffrement impossible, par exemple).

ÉDIT du 30/05/2016 à 19h45 : Attention : Enigmail permet également de générer facilement une paire de clés de manière conviviale mais il est impératif de configurer GPG au préalable car les paramètres par défaut sont insuffisants. Voir la première partie de ce billet. Fin de l'édit.

Pour envoyer un mail avec du contenu chiffré et/ou signé, on peut aussi utiliser les méthodes précédentes sur les fichiers puis

mail -s "" <adresse_mail_destinataire> < <fichier>.asc

Mais ce n'est pas vraiment sérieux. 😀

Quelques précautions à prendre lors de l'envoi d'un mail signé/chiffré

  • PGP/inline ou PGP/MIME ? Voir : Choisir PGP/MIME ou PGP/Inline chez Vigdis et Choisir PGP/MIME ou PGP/Inline chez le Hollandais Volant pour un exposé des différents arguments. Je retiens que pour la signature, on se pose aucune question : PGP/MIME. Pour un mail chiffré, il faut se décider à prendre en compte les MUA en carton (au détriment de la sécurité) ou pas. Pensez à configurer votre MUA. Pour Icedove/Enigmail, voir : Enigmail Configuration Manual - Per Account Settings. Sous Debian GNU/Linux Wheezy, je remarque que PGP/MIME est utilisé par défaut.
  • Dans tous les cas, le sujet du mail n'est pas chiffré (comme le reste des en-têtes), il faut donc éviter de mettre l'information confidentielle dedans. Évidemment, cela rend plus difficile l'estimation de la priorité (du point de vue du destinataire donc exit le header posé par l'expéditeur) d'un mail et la recherche. Compromis entre simplicité et sécurité, as usual.

    J'en profite pour rappeler que les métadonnées (adresse d'expédition, adresses destinataires (même CCi), heure, poids, fréquence des échanges) sont vues par tous les intermédiaires entre vous et votre correspondant. OpenPGP ne change pas ça !

    • PGP = contenu chiffré/signé de bout en bout ;
    • TLS = chiffrement point à point entre deux serveurs SMTP. Les métadonnées ne circulent donc plus en clair, seuls les MTA sur le chemin voient les métadonnées ;
    • Autohébergé + TLS + PGP = le top : métadonnées connues exclusivement des serveurs SMTP de l'expéditeur et du destinataire, métadonnées (+ contenu, of course) chiffrées entre les serveurs et contenu protégé de bout en bout par PGP. Notons qu'il suffit de tcpdump, au niveau 3, en amont d'un serveur mail personnel, autohébergé ou non, pour savoir qui écrit à qui, quand à quelle heure, à quelle fréquence : pas besoin de virer TLS ni de pirater les serveurs de mails. Bah oui, on sait que le serveur A avec l'IP A est à GuiGui... Forcément, tout mail qui en sort est émis par GuiGui, tout mail qui entre est à destination de GuiGui.
  • Les pièces jointes non incluses dans le corps du mail laissent leur nom apparaître même avec PGP donc, pareil que pour le sujet : ne pas y mettre la fameuse information confidentielle. Cf : Parce que vous vous foutez de vos libertés, ce sont les miennes qui disparaissent. Apparemment, ce comportement dépend du MUA : Mutt ne fait pas fuiter le nom des pièces jointes, par exemple.
  • Si vous perdez votre clé privée, c'est mort pour déchiffrer les mails, même les mails échangés dans le passé ! Faites attention avec votre trousseau et sauvegardez-le bien !

ÉDIT du 30/05/2016 à 16h30 :

Quid des webmails ?

Utiliser un webmail avec OpenPGP est une mauvaise idée.

Déjà, ça suppose que, même si le webmail ne rapatrie pas vos mails sur la machine que vous utilisez, il vous faut quand même votre clé privée sur la machine que vous utilisez afin de déchiffrer les mails entrants et de signer les mails sortants. Si vous êtes au taff et que votre disque dur n'est pas chiffré OU que votre boss (ou une équipe de votre société) est root sur votre machine, il est hors de question de stocker votre clé privée sur cette machine, de base. Donc usage webmail ou pas, ce n'est pas la question. En revanche, si vous avez un moyen de stockage externe de votre clé privée (pas sur une clé USB, hein, root peut toujours vous voler votre clé privée :- ) duquel la clé ne sort jamais comme une Yubikey 4 (les versions d'avant gèrent uniquement des clés de 2048 bits max, ce qui est pourri de nos jours) alors vous n'êtes pas concerné-e par ce premier point mais…

Ensuite, ça suppose que le webmail, qui n'est autre qu'une page web distante, puisse exécuter du code sur votre machine. Cela se fait avec JavaScript. Peut-on avoir confiance en un langage exécuté sur votre machine mais réellement piloté par le webmail distant, c'est-à-dire par une machine hors de chez vous, hors de votre contrôle ? Même quand il s'agit de manipuler votre clé privée (qui doit rester privée, je le rappelle) ? Même quand il s'agit de chiffrer/déchiffrer ?

Un cas concret met en évidence quelques problèmes qui peuvent survenir : Tails - FireGPG susceptible to devastating attacks :

Webmail interfaces commonly use text boxes for email composition, so FireGPG is a natural fit for this use case: the user writes his or her email plaintext in the text box, selects the plaintext and uses one of the "Encrypt" or "Sign and encrypt" actions available from the FireGPG menu to transform the selection to its encrypted counterpart.

The FireGPG design incorrectly assumes that this is safe, but it is not, since JavaScript running on the page can still control and observe much of what is happening on the page. For instance, a simple script can set up a timer that silently submits the contents of the text box back to the server every second, thereby leaking the plaintext as it is written, effectively bypassing any subsequent encryption. In fact, many non-malicious webmail services do just that at longer intervals, to save a draft of a message in case the user's browser crashes.

[...]

FireGPG also has three commands to sign (but not encrypt) messages: "Sign", "Wrapped sign" and "Clearsign". Simple JavaScript can replace the contents of the text box when the user selects it, so if the user does not re-read the text after selecting one of the 'sign' commands, the attacker will be able to obtain the user's signature on an arbitrary message.

Quant à Mailvelope, c'est totalement basé sur un framework JavaScript, OpenPGP.js… Pour ma part : problème de confiance envers JavaScript.

Enfin, même si vous chiffrez/signez votre prose en local avant de copier le blob GPG dans un webmail (ce que fait l'applet GPG de Tails), un webmail utilise forcément PGP/Inline et on a vu ci-dessus que ce n'était ni le plus sécurisé ni le top visuellement parlant. Ça concerne tous les webmails : Roundcube, Mailpile,…

Pour qu'un webmail puisse gérer PGP/MIME, il n'y a que deux méthodes possibles : soit votre clé privée est stockée sur le serveur de mails, soit il faut implémenter un parseur MIME en Javascript qui s'exécutera uniquement côté client. Dans le premier cas, ça pourrait convenir uniquement aux serveurs de mails qui ne sont pas mutualisés entre plusieurs utilisateurs. Et encore : il existe un risque de se faire voler sa clé privée OpenPGP via un logiciel pas à jour et/ou une faille dans un site web présent sur le même serveur, par exemple. Dans le deuxième cas, quitte à ré-implémenter un parseur MIME, autant avoir un client mail lourd. Surtout que recoder un parseur MIME n'est pas simple, il y aura des bugs, des failles, etc.

OpenPGP et confidentialité persistante (PFS - Perfect Forward Secrecy)

Contrairement à OTR ou à TLS ou SSH, OpenPGP ne peut pas apporter la confidentialité persistante : si votre clé privée est volée, le voleur peut, une fois qu'il a la passphrase : 1) déchiffrer tout contenu chiffré ultérieurement avec la clé publique, 2) signer du contenu, 3) déchiffrer tout contenu produit antérieurement au vol qui tomberait sous sa main. Ainsi, si vos mails et votre clé privée sont volés, c'est la fin : tous vos échanges passés sont connus par le voleur. Avec la PFS, le 3) est évité.

OpenPGP ne peut pas apporter cette propriété de confidentialité persistante car elle suppose un échange synchrone pour se transmettre une clé de chiffrement temporaire. Or, le mail n'est pas prévu pour être synchrone.

FIN DE L'ÉDIT du 30/05/2016 à 16h30

ÉDIT DU 05/07/2016 À 17h00

Changer la date d'expiration d'une clé

Votre clé arrive bientôt à expiration voire elle a expiré ? Voici comment repousser la date d'expiration.

En ligne de commande

gpg --edit-key "<fingerprint_de_votre_clé"

Pour changer la date d'expiration de votre clé principale :

expire

Je recommande de repousser la date d'un an, surtout si vous êtes un-e novice : à ce stade, on perd souvent sa clé privée et cert' de révocation donc ce n'est pas la peine d'avoir une date d'expiration de 2 ou 5 ans… Donc, on indique « 1y » à GPG. Puis on confirme notre choix et on saisit notre phrase de passe pour que la modification prenne effet.

Ensuite, il faut s'occuper de chacune de vos sous-clés. Pour les voir, il faut utiliser la commande « list ». Par défaut, GPG crée une sous-clé de chiffrement. Il faut donc la renouveller elle-aussi.

D'abord, on la sélectionne (clé qui porte l'index, le numéro 1):

key 1

Ensuite, on recommence le topo : expire , 1y, on confirme.

Il faut faire cela pour chaque sous-clé.

Une fois que cela est fait, on sauvegarde nos changements :

save

Avant-dernière étape, mettre à jour notre clé sur les serveurs de clés pour que nos contacts puissent prendre connaissance que notre clé ne va pas expirer cette fois-ci et qu'ils peuvent continuer à l'utiliser :

gpg --send-key "<fingerprint_de_votre_clé>

Dernière étape : comme toujours, il faut penser à sauvegarder l'intégralité de votre trousseau (tout le dossier .gnupg, en gros) + une copie de votre clé privée modifiée. Voir la fin de la partie « Générer une paire de clés » pour avoir la commande d'export qui fait ce job.

Avec Enigmail

Il faut aller dans l'item « Gestion de clés » du menu « Enigmail » puis cliquer droit sur votre clé (facile de la reconnaître, elle est en gras) et choisir « Changer la date d'expiration » dans le menu. Par défaut, Enigmail sélectionne votre clé principale + sa sous-clé de chiffrement et propose de reporter la date d'expiration d'une année, c'est un bon choix donc on se contente de valider.

FIN DE L'ÉDIT du 05/07/2016 À 17h00

ÉDIT du 02/11/2014 à 17h15 :

Révocation

Je parle ici d'une révocation voulue : nous changeons de clés car l'ancienne clé à fait son temps (exemple : taille de clé devenue trop faible avec le temps, avancées cryptanalyse, ...) ou n'a pas été générée avec les paramètres recommandés permettant d'assurer un minimum de sécurité. Évidemment, les fichiers et mails chiffrés avec votre ancienne clé doivent rester lisibles.

Évidemment, je vous recommande très fortement de sauvegarder votre trousseau (tout le dossier ~/.gnupg quoi) avant de commencer. Tant que vous n'avez pas propagé vos modifications sur un serveur de clés (commande « gpg --send-key »), vous pouvez toujours restaurer votre ancien dossier .gnupg pour revenir en arrière. Une fois les modifications poussées sur un serveur de clés, c'est trop tard, notamment pour la révocation donc vérifiez bien vos manipulations avant de procéder à cet envoi.

Cette section est inspirée de : Révoquer une clé GnuPG - Sima78.

Générer une nouvelle paire de clés

La première étape est de générer une nouvelle paire de clés. Je vous recommande de lire la section « Générer une paire de clés » en haut de ce billet à propos de la conf recommandée pour GnuPG et de comment on génère/sauvegarde une paire de clés et le certificat de révocation associé. Ci-dessous, je fais le strict minimum concernant la génération d'une nouvelle paire de clés.

On génère une nouvelle paire de clés :

gpg --gen-key

On signe notre nouvelle clé avec notre ancienne clé :

gpg --default-key <fingerprint_ancienne_clé> --sign-key <fingerprint_nouvelle_cle>

Cela permet d'indiquer à tout le monde que c'est bien votre nouvelle clé à vous (vous l'avez signée). Cela est purement indicatif : en effet, en cas de compromission totale (récupération de votre clé privée et de sa passphrase), la personne mal-intentionnée peut très bien générer une nouvelle paire de clés et la signer avec votre ancienne paire de clés histoire de tromper vos correspondants avant que vous vous rendiez compte de la compromission et que vous les préveniez. L'avantage de procéder ainsi pour l'attaquant est qu'il commence une nouvelle chaîne de confiance sous son contrôle.

On publie la partie publique sur un serveur de clés :

gpg --send-key <fingerprint_nouvelle_cle>

Tester la nouvelle paire de clés

Avant d'aller plus loin, il faut tester notre nouvelle paire de clés.

Pour que GnuPG utilise votre nouvelle paire de clés par défaut (sans qu'on ai besoin de lui indiquer « --default-key » à chaque commande), il faut modifier le fichier gpg.conf pour ajouter la ligne suivante :

default-key "fingerprint_nouvelle_clé"

Ce morceau de configuration ne sera plus utile une fois l'ancienne clé révoquée : GnuPG ignorera l'ancienne clé sauf pour déchiffrer / vérifier la signature d'anciens fichiers/mails.

Pour que Thunderbird/Enigmail utilisent votre nouvelle paire de clés : menu « Édition », « Paramètres des comptes », choisir le compte mail dans la liste à gauche, « Sécurité OpenPGP ». Cocher « Utiliser un identifiant de clé particulier », cliquer sur le bouton « Choisir une clef ... » et choisir la nouvelle clé.

À ce stade, vos anciens fichiers et mails chiffrés/signés sont encore parfaitement lisibles et vérifiables. Votre nouvelle clé vous permet de chiffrer/signer des fichiers et des mails. Chez vos correspondants, Enigmail affiche « Signature non vérifiée » : c'est normal, ils doivent importer et signer votre nouvelle partie publique.

Révoquer l'ancienne clé

gpg --edit-key "<fingerprint_ancienne_clé>"
[...]
gpg> revkey

Confirmez que vous voulez vraiment révoquer cette clé, choisissez la raison « 2 = La clé a été remplacée », vous pouvez indiquer une raison comme « taille de clé insuffisante » puis confirmez que vous êtes d'accord avec la touche « o » puis tapez la commande « save » puis « quit ».

Vous pouvez vérifier que votre clé a bien été révoquée avec les commandes habituelles comme « --list-keys ».

Si tout est OK, vous pouvez pousser votre clé révoquée sur les serveurs de clés. Attention, la révocation devient définitive à partir d'ici !

gpg --send-key <fingerprint_ancienne_clé>

Quand je vous ai dit que la révocation est devenue effective à ce stade, je vous ai un peu menti : elle sera effective quand tous vos contacts auront mis à jour leur trousseau. En attendant qu'ils le fassent, ils peuvent toujours utiliser votre ancienne clé publique pour vous envoyer des mails/fichiers chiffrés alors qu'elle a pourtant été révoquée. D'où l'importance de mettre à jour régulièrement son trousseau de clés : « gpg --refresh-keys » ou, mieux pour la confidentialité de votre graphe de relations, parcimonie.

Voilà, on a terminé. \o/

À ce stade, vous pouvez toujours déchiffrer/vérifier vos anciens mails/fichiers. L'ancienne clé n'est plus utilisable, ni dans GnuPG directement ni dans Enigmail pour chiffrer/signer de nouveaux fichiers/mails. Si vous tentez quand même de signer un mail avec votre ancienne clé privée, Enigmail vous hurle dessus : « L'adresse de courriel ou ID de clé '<lala>' ne correspond pas à une clé OpenPGP valide et non-expirée. ». \o/

Évidemment, tous vos correspondants doivent signer votre nouvelle clé publique. 🙂

Évidemment, ne vous amusez pas à supprimer l'ancienne clé de votre trousseau ! Si vous le faîtes, vos anciens mails et fichiers chiffrés sont perdus (illisibles) ! À titre d'information, les commandes dangereuses à ne pas faire (mais GnuPG crache plein d'avertissements pour vous convaincre de faire marche arrière) sont : « --delete-secret-keys <fingerprint> » puis « --delete-key <fingerprint> ».

Révoquer une paire de clés avec un certificat de révocation

Ci-dessus, nous avons vu comment révoquer une paire de clés avec la commande « revkey ». Voyons maintenant comment faire dans la pire hypothèse : vous n'avez plus votre clé privée, vous avez une machine vierge et vous avez votre certificat de révocation.

D'abord, il faut importer la clé publique à partir d'un fichier ou d'un serveur de clés :

gpg --import <ma_cle_pgp_pwned>.asc
OU
gpg --search-keys "<ID_ou_une_partie_de_l'identité>"

Ensuite, il faut importer le certificat de révocation :

gpg --import maclepgp.revoke

On vérifie que tout est OK avec les commandes habituelles comme « --list-keys ».

Si tout est OK, vous pouvez pousser votre clé révoquée sur les serveurs de clés. Attention, la révocation devient définitive à partir d'ici !

gpg --send-key <fingerprint_ancienne_cle>

Fin de l'édit.

Conclusion

OpenPGP et ses implémentations, ce n'est pas encore accessible à tous, comme tout ce qui tourne autour de la sécurité.

Je déconseille le tutoriel La cryptographie facile avec PGP sur le SdZ notamment à cause du paragraphe suivant (vers la fin) : « Normalement, toutes les clés devraient être signées par d'autres, elles-mêmes signées par d'autres, et ainsi de suite jusqu'à arriver à quelques personnes fiables comme Phil Z (l'inventeur de PGP), Linus Torvalds (le créateur de Linux) ou Richard Stallman (le fondateur de GNU) : ce réseau reliant les clés entre elles est appelé réseau de confiance (web of trust). ». Le modèle de la toile de confiance n'a rien en commun avec le modèle hiérarchique des AC x509 bien connues !

Tout ça pour dire d'être prudent lorsque l'on parle de crypto. 🙂

Découvrons la RIPE database

Le RIPE, comme tout RIR, dispose d'une base de données publique qui regroupe toutes (un maximum on va dire) les informations "technico-administratives" (à qui a été alloué telle ressource numérique unique ? qui est le responsable technique de ce réseau, quel AS doit annoncer tel préfixe IP ?, ...) concernant les réseaux informatiques publics en Europe (version large) et au Moyen-Orient.

Habituellement, on accède à cette base de données lorsque l'on fait une requête avec le protocole whois sur une ressource (plage d'IP, numéro d'AS, ...) allouée/assignée par le RIPE. Aujourd'hui, on va plutôt regarder de quoi est constituée cette base de données et comment les LIR et les opérateurs réseaux la mettent à jour (ou non, d'ailleurs).

Si tous les RIR ont une base de données, pourquoi je me focalise sur celle du RIPE ? Simplement car le RIPE est bien de chez nous et comme le format de la base (RPSL ou non, objets/attributs différents, ...) change entre RIR, autant étudier ce qui nous concerne. De plus, la RIPE DB est la mieux documentée, à mon humble avis.

Attention : ce billet n'est ni de la vulgarisation ni une source d'information fiable. Il s'agit juste d'un retour d'expérience et de quelques notes d'un n00b qui s'est penché sur le sujet.

Table des matières

De la documentation générale

Documentation spécifique

Quelques paramètres whois bien utiles

Ce que je retiens principalement des lectures précédentes, c'est des paramètres de la commande whois, qui sont spécifiques à certaines bases comme celle du RIPE mais qui n'en sont pas moins très utiles :

  • whois -t <type_objet> : afficher les attributs d'un type d'objet
  • whois -B : afficher toutes les infos (mail ...) de l'objet demandé (sans ça : « source: RIPE # Filtered »)
  • whois -L : remonter toute l'arborescence d'une allocation. Exemple pour un inetnum : organisation - LIR - RIR - IANA
  • whois -l : pareil que précédemment mais remonte uniquement d'un étage/d'une étape/d'un cran
  • whois -r -i org <id_organisation> : afficher toutes les ressources/objets assignés/alloués à une organisation (objet de type « organisation »)
  • whois -i origin <ASN> : afficher tous les préfixes déclarés comme étant annoncés par l'AS donné. En vrai, ça remonte les objets route(6) et la fioriture qui va avec. On peut également remonter tous les objets dont le tech ou l'admin sont un objet person passé en argument : whois -i person . On ne peut pas itérer sur tous les attributs. Les attributs possibles sont indiqués dans « RIPE Database Queries Reference Card » (https://www.ripe.net/manage-ips-and-asns/db/support/documentation )

RIPE TEST Database

Le RIPE met à disposition une base de données de test en libre-service pour que chacun puisse découvrir/s'entraîner à l'arrache. Je pense que c'est un excellent moyen de voir comment ça se passe de l'autre côté du whois. C'est vraiment intéressant et formateur.

Ci-dessous, je ne vais pas être exhaustif, juste donner des pistes et énoncer quelques "pièges" que j'ai rencontrés pour vous éviter de tomber dedans.

Dans mes exemples, je serai Jean-Kevin Boulay de l'association TESTASSO.

person/mntner

La première étape est de créer un objet de type « person ». Voyons les différents attributs disponibles :

whois -t person
person:         [mandatory]  [single]     [lookup key]
address:        [mandatory]  [multiple]   [ ]
phone:          [mandatory]  [multiple]   [ ]
fax-no:         [optional]   [multiple]   [ ]
e-mail:         [optional]   [multiple]   [lookup key]
org:            [optional]   [multiple]   [inverse key]
nic-hdl:        [mandatory]  [single]     [primary/lookup key]
remarks:        [optional]   [multiple]   [ ]
notify:         [optional]   [multiple]   [inverse key]
abuse-mailbox:  [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Hum ... mnt-by doit pointer un objet de type « mntner » (maintainer) ... Quels sont ses attributs ?

whois -t mntner
mntner:         [mandatory]  [single]     [primary/lookup key]
descr:          [mandatory]  [multiple]   [ ]
org:            [optional]   [multiple]   [inverse key]
admin-c:        [mandatory]  [multiple]   [inverse key]
tech-c:         [optional]   [multiple]   [inverse key]
upd-to:         [mandatory]  [multiple]   [inverse key]
mnt-nfy:        [optional]   [multiple]   [inverse key]
auth:           [mandatory]  [multiple]   [inverse key]
remarks:        [optional]   [multiple]   [ ]
notify:         [optional]   [multiple]   [inverse key]
abuse-mailbox:  [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
referral-by:    [mandatory]  [single]     [ ]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Il y a une référence circulaire : un objet person dépend d'un objet de type maintainer mais un objet maintainer dépend aussi d'un objet de type person (attribut « admin-c »).

La solution ? Utiliser le formulaire pour les nouveaux arrivants dans la RIPE Database.

Mode d'emploi rapide :

  • Source : bien choisir la TEST Database
  • Person : prénom nom. Exemple : J-K Boulay
  • NIC hdl : ne peut pas être vide contrairement à ce qui est indiqué. Il s'agit de la clé primaire de l'objet. Elle doit être unique dans la base donc la base l'attribue elle-même. Vous pouvez mettre :
    • Soit une suite de caractères qui respecte le formalisme (« From 2 to 4 characters optionally followed by up to 6 digits optionally followed by a source specification. The first digit must not be "0". Source specification starts with "-" followed by source name up to 9-character length. »). Exemple : JKB1-TEST. Attention : un nic-hdl déjà pris générera une erreur « The nic-hdl "JKB1-TEST" is not available ».
    • Soit la valeur « AUTO-1 » pour laisser complètement le choix à la base ou « AUTO-1<abréviation> ». Abréviation est composée de 1 à 4 lettres. Exemple : AUTO-1JKB pour obtenir le nic-hdl : « JKB1-TEST ». Il est inutile d'essayer de mettre AUTO-42JKB pour tenter d'obtenir un nic-hdl « JKB42-TEST » : ça ne marche pas. Je n'ai pas trouvé comment forcer le nombre et c'est à mon avis bien normal : ID, on prend le suivant, même si un objet avec un ID inférieur a été supprimé depuis, tout ça.
  • Address : FR suffit, par exemple
  • Phone : +33123456789 suffit, par exemple
  • Email : ripedb@example.com suffit, par exemple
  • Pour le mntner, le nom est une clé et on reprend souvent le nom de l'organisation à laquelle la personne qui s'inscrit est rattachée. Exemple : Maintainer name : TESTASSO-MNT

Normalement, vous obtenez le message suivant :

We have created two RIPE Database objects for you, please make a note of the primary keys (shown in bold letters) for these two objects for future reference:
 
person nic-hdl: JKB1-TEST
 
person:         J-K Boulay
address:        FR
phone:          +33123456789
e-mail:         ripedb@example.com
nic-hdl:        JKB1-TEST
mnt-by:         TESTASSO-MNT
changed:        ripedb@example.com 20140418
source:         TEST
 
maintainer name: TESTASSO-MNT
 
mntner:         TESTASSO-MNT
descr:          Startup maintainer
admin-c:        JKB1-TEST
upd-to:         ripedb@example.com
auth:           MD5-PW blabla
mnt-by:         TESTASSO-MNT
referral-by:    TESTASSO-MNT
changed:        ripedb@example.com
source:         TEST

Petite note : un objet de type maintainer est un verrou qui empêche la modification et la suppression inopinée de vos enregistrements présents dans la base. Il recense également les moyens qui permettent d'authentifier le requérant d'une modification/suppression. Actuellement, la base supporte une auth par mot de passe (stocké sous forme de hash MD5 dans la base) ou par signature PGP des objets (uniquement par mail, pas par l'interface web. Oui, on peut créer/modifier des objets par mail.). Pour l'instant, nous n'avons qu'une auth par mot de passe.

Vous pouvez effectuer une recherche pour vérifier que vos objets ont bien été créés : https://apps.db.ripe.net/search/query.html.

Si vous souhaitez modifier vos objets, c'est par là : https://apps.db.ripe.net/webupdates/search.html. Cependant, lors de la soumission de vos modifications, vous allez recevoir l'erreur : « No authorisation has been supplied ». En effet, vous n'avez pas prouvé votre identité selon l'un des mécanismes prévus dans l'objet maintainer qui verrouille l'objet que vous souhaitez modifier. Pour vous authentifier, il suffit de saisir votre mot de passe de maintainer dans la zone « Session Passwords » dans le menu de droite.

À partir de maintenant, vous pouvez créer vos objets à l'adresse suivante : https://apps.db.ripe.net/webupdates/select-type.html. Deux méthodes de saisies sont disponibles : format brut (que du texte) ou formulaire avec uniquement les attributs obligatoires.

organisation

Un objet de type « organisation » permet de lier toutes les ressources associées/allouées à une organisation donnée. Très pratique mais pas obligatoire. Les autres objets peuvent pointer dessus avec un attribut « org ». L'attribut organisation fonctionne comme le NIC-hdl d'une person donc « AUTO-1<abréviation> ».

Exemple :

organisation: 	ORG-TSTA1-TEST
org-name: 	Association TESTASSO
org-type: 	OTHER
address: 	FR
e-mail: 	ripedb@example.com
mnt-ref: 	TESTASSO-MNT
mnt-by: 	TESTASSO-MNT
changed: 	ripedb@example.com 20140418
source: 	TEST

inetnum/inet6num

Passons au plus intéressant : une plage d'adresses IPv4 : un inetnum (ou v6 avec inet6num, ça fonctionne pareil).

En situation réelle, vous n'aurez pas besoin de créer cet objet : c'est le boulot de votre LIR qui vous mettra en mnt-* si vous le souhaitez pour que vous ayez des droits sur vos allocations. De plus, en situation réelle, le processus d'allocation de ressources ne se passe pas aussi facilement en mode "ho, cette plage est disponible, je la prends". Néanmoins, ici, je choisis 192.0.2.0/24 qui est une plage réservée à la documentation.

Ici, il faudra l'accord de la hiérarchie, c'est à dire de l'organisation (RIR ou LIR) a qui a été attribuée la plage d'adresses IP qui englobe celle que cette organisation vous a attribuée. Pour trouver quel est le maintainer responsable, il suffit de faire une recherche.

Via l'interface web :

  • Search term : 192.0.2.0 - 192.0.2.255
  • Sources : TEST Database
  • Hierarchy Flags : l (l comme lapin)

Ou via whois : whois -h whois-test.ripe.net -l 192.0.2.0 - 192.0.2.255

Voilà un extrait de la réponse :

inetnum:         0.0.0.0 - 255.255.255.255
netname:         IANA-BLK
descr:           The whole IPv4 address space
country:         EU # Country is really world wide
org:             ORG-TT1-TEST
admin-c:         AA1-TEST
tech-c:          AA2-TEST
status:          ALLOCATED UNSPECIFIED
remarks:         The country is really worldwide.
mnt-by:          TEST-ROOT-MNT
mnt-lower:       TEST-DBM-MNT
mnt-routes:      TEST-DBM-MNT
remarks:         This is an automatically created object.
source:          TEST # Filtered

On regarde l'attribut « mnt-lower: ». Le maintainer est « TEST-DBM-MNT ». Dans cette base de test, le mot de passe est donné dans un attribut « remark » de cet objet mntner. Je vous laisse le retrouver et l'ajouter à vos « Session Passwords » (menu de droite, tout ça ...).

Maintenant, vous pouvez enregistrer un inetnum. Exemple :

inetnum: 	192.0.2.0 - 192.0.2.255
netname: 	TESTASSO-MAIN
descr:		IPv4 TESTASSO allocation
country: 	FR
admin-c: 	JKB1-TEST
tech-c: 	JKB1-TEST
status: 	ASSIGNED PA
mnt-by: 	TESTASSO-MNT
changed: 	ripedb@example.com 20140418
source: 	TEST

Remarquez que le statut est fantaisiste et ne correspond pas à la réalité : l'IANA n'alloue pas directement des ressources. Le RIPE le faisait (PI + allocation directe). Mais c'est fini (famine IPv4, tout ça et il me semble que c'est pareil en IPv6). Donc, au minimum, il faudrait un RIR et un LIR entre TESTASSO et l'IANA avec autant d'objets. Si ça vous tente de faire une maquette plus réaliste ... Ce n'est pas difficile, juste répétitif.

ÉDIT du 26/04/2014 à 22h00 : Remarquez que le mnt-by est lui aussi fantaisiste : un LIR ne vous mettra pas en mnt-by car il s'agit de ses allocations à lui en tant que LIR tout comme le RIPE n'a pas défini le LIR comme mnt-by sur le(s) inet(6)num qu'il a attribué au LIR. C'est le rôle de ces organismes (RIR et LIR) de délimiter les allocations. Sur les inet(6)num, votre LIR vous mettra en mnt-lower pour gérer des découpages dans vos allocations (exemple : fourre-tout v6), en mnt-domain pour gérer les objets domain associés et en mnt-routes pour créer/modifier les objets de type route, ... Fin de l'édit

ASN

Pour un numéro de système autonome (ASN), le type d'objet est « aut-num ». Sa création ne pose pas de problèmes si vous êtes arrivé jusque-là.

Délégation zone reverse

Pour la délégation d'une zone reverse v4/v6, c'est un objet de type « domain » qu'il vous faut. Mais dans la base de test, sa création échouera car le niveau supérieur (0/0 en v4) n'a pas configuré les serveurs de noms qui font autorité sur cette zone reverse (et pour cause ...).

Politiques de routage inter-AS

Pour ce qui est des politiques de routage, on a les objets de type route/route6 qui permettent de dire : « tel préfixe IPv4 ou IPv6 est annoncé par tel AS » ou des choses plus marrantes comme « quelle est l'adresse IP de la machine que ce réseau met à disposition du public pour servir d'amer ? » (attribut « pingable » d'un route/route6.

Pour les politiques de routage, on a aussi d'autres objets (filter-set, par exemple) et des attributs dans l'objet « aut-num » : import, export et les types liés (as-set, route-set). Tout cela constitue l'Internet Routing Registry (IRR). Exemple :

aut-num: AS197422
as-name: TETANEUTRAL-NET-AS
[...]
from AS31576 accept ANY
from AS6777 accept ANY
from AS6939 accept ANY
[...]
to AS31576 announce AS197422
to AS6939 announce AS197422
to AS6777 announce AS197422
[...]

Ici, ce FAI toulousain annonce que ses pairs sont GIXE (transitaire), l'AMS-IX (point d'échange néerlandais) et Hurricane Electric (gros opérateur). Tetaneutral.net récupère toutes les routes auprès d'eux sans prioriser un pair vis-à-vis d'un autre. Enfin, Tetaneutral annonce ses préfixes à ses pairs.

ÉDIT du 05/05/2016 à 13h20 : Un jour, vous fournirez peut-être du transit IP à d'autres réseaux/organisations. Il faudra alors mettre à jour l'IRR pour dire : « à mes upstreams/pairs, j'annonce non seulement mon AS mais aussi celui de mes downstreams ». Si l'on procède comme on vient de voir, il faudrait une ligne « export: to AS64500 announce AS6500 » (AS64500 = upstream et AS6500 = downstream) pour chaque couple downstream+upstreams ainsi qu'une ligne « import: from AS6500 accept AS6500 » pour chaque downstream ainsi qu'une ligne « export: to AS65000 announce ANY » pour chaque downstream. Ces deux dernières lignes sont inévitables. En revanche, on peut factoriser les premières.

Pour se faire, on utilise un objet de type as-set qui regroupera les objets de type aut-num de vos downstreams + votre aut-num. Ensuite, pour chaque upstream, on aura une ligne : « export: to AS64500 announce <votre_as-set> ». Lors de l'ajout d'un nouveau downstream, il suffit de rajouter son aut-num à l'as-set et les lignes « import: from <son_aut-num> accept <son_aut-num> » et « export: to <son_aut-num> announce ANY » à votre aut-num et c'est fini. Évidemment, le downstream devra mettre à jour son IRR pour indiquer que votre organisation est l'un de ses upstreams/pairs.

Exemple :

aut-num:        AS60630
as-name:        ARN
[...]
import:         from AS174 accept ANY
export:         to AS174 announce AS-ARN
import:         from AS8928 accept ANY
export:         to AS8928 announce AS-ARN
import:         from AS204092 accept AS204092
export:         to AS204092 announce ANY
[...]

as-set:         AS-ARN
descr:          ARN and downstreams
members:        AS60630
members:        AS204092
[...]

aut-num:        AS204092
as-name:        GRIFON
[...]
import:         from AS60630 accept ANY
export:         to AS60630 announce AS204092
[...]

Ici, ce FAI alsacien annonce lui (AS60630) + Grifon (AS204092) à ses upstreams (Cogent - AS174 et Interoute - AS8928), récupère les routes de Grifon et lui annonce la full view.

Il y a deux intérêts à faire ça. Premièrement, avoir une base de données à jour ce qui, en plus d'être du bon sens civique, permet de ne pas se faire filtrer ses préfixes par des opérateurs qui construisent leurs filtres automatiquement à partir de la RIPE DB. Deuxièmement, certains transitaires (comme Interoute) vérifient ces informations avant de vous autoriser à relayer les annonces de vos downstreams lors de votre appel à leur NOC. Tous les transitaires ne vérifient pas : Cogent, par exemple, croit ses clients sur parole. Fin de l'édit

ÉDIT du 17/10/2017 à 9h25 : Comme la politique de routage IPv4 peut être différente de la politique de routage IPv6 (pairs différents, priorité différente, etc.), le RIPE recommande, dans ses formations, de publier les deux politiques de routage dans l'IRR. Cela se fait avec les attributs « mp-import » et « mp-export ». Exemple :

aut-num:        AS60630
[…]
import:         from AS174 accept ANY
export:         to AS174 announce AS-ARN
[…]
mp-import:      afi ipv6.unicast from AS174 accept ANY
mp-export:      afi ipv6.unicast to AS174 announce AS-ARN

Dans cet exemple, l'opérateur déclare être relié à Cogent (AS174) en IPv4 et en IPv6, qu'il lui annonce son réseau et celui de ses clients (AS-ARN) et que Cogent lui envoie la full view (ANY), c'est-à-dire toutes les routes qu'il connait.

Note : on peut remplacer « import » et « export » par « mp-import: afi ipv4.unicast » et par « mp-export: afi ipv4.unicast ». Les deux syntaxes sont équivalentes, la deuxième est plus moderne et plus lisible. Fin de l'édit du 17/10/2017 à 9h25

ÉDIT du 17/10/2017 à 9h40 : Il est possible de se connecter à des collecteurs (ring nlnog, route views, ripe stat, etc.) c'est-à-dire, à des projets qui sont des vigies d'observation d'Internet depuis lesquelles on voit battre le cœur d'Internet, on voit la topologie générale du réseau varier, on peut diagnostiquer et comprendre les pannes techniques, etc. Généralement, on envoie toutes nos routes à ces projets-là, mais lui ne nous envoie rien. Comment explicite-t-on cela dans la politique de routage ? Comme ceci :

aut-num:        AS60630
[…]
import:         from AS199036 accept NOT ANY
export:         to AS199036 announce ANY
[…]
mp-import:      afi ipv6.unicast from AS199036 accept NOT ANY
mp-export:      afi ipv6.unicast to AS199036 announce ANY

Dans cet exemple, l'opérateur déclare être connecté au looking glass du nlnog (AS199036), en IPv4 et en IPv6. Il déclare lui envoyer toutes les routes qu'il connaît (« export: […] ANY ») et que le nlnog ne lui envoie rien (« import: […] NOT ANY »). Oui, cette syntaxe « NOT ANY » n'est pas la plus intuitive qui soit… Fin de l'édit du 17/10/2017 à 9h40

Cogestion

Et pour faire de la cession de droits ou, à minima, de la cogestion sur des objets ? Il suffit de leur associer de nouveaux objets de type mntner dans leurs attributs « mnt-by » ou « mnt-* » pour des droits plus fins. Exemples : mnt-routes pointe sur un objet maintainer qui aura le droit d'ajouter des objets de type route/route6 en rapport avec l'objet courant ; mnt-domain = même principe mais pour les reverse v4/v6. L'authentification fonctionne selon un OU logique : toute personne qui aura un des mécanismes d'authentification d'un des maintainers pourra modifier l'objet.

ÉDIT du 26/04/2014 à 23h55 :

Modifier la base par mail avec signature PGP

Documentations : PGP Authentication in the RIPE Database — RIPE Network Coordination Centre ainsi que le tutoriel « Maintenance whois de Lulu » que j'ai linké en début de billet.

Notez qu'il n'est pas nécessaire d'utiliser PGP : vous pouvez envoyer vos modifications par mail en y ajoutant un attribut « password » contenant le mot de passe de votre objet maintainer en clair. Mais c'est mal, très mal. La réciproque n'est pas vraie : l'interface web ne supporte pas les signatures PGP.

Les robots à contacter (source) :

  • auto-dbm(at)ripe(dot)net pour la vraie DB
  • test-dbm(at)ripe(dot)net pour la DB de test (un greylisting est en place sur cette adresse)

La première étape pour soumettre vos modifications signées avec PGP par mail est de créer un objet de type « key-cert ». Il semble que le formulaire « individual fields » est cassé (il retourne toujours l'erreur « certif value is required ») donc utilisez le formulaire « single text area ».

KEY-CERT : PGPKEY-<ID_de_votre_cle>

CERTIF : votre clé publique au format ASCII obtenu avec gpg --armor --export <ID_de_votre_cle>. Il faut autant de lignes « certif » que de lignes dans la sortie gpg. Il faut conserver les lignes vides et les marqueurs de début et de fin de la clé.

Les autres attributs sont soit générés automatiquement (« method », « owner », « fingerpr ») soit facultatifs. On supprime les premiers. On complète ou non les seconds.

Exemple :

KEY-CERT:        PGPKEY-698DB1DD
CERTIF:          -----BEGIN PGP PUBLIC KEY BLOCK-----
CERTIF:          Version: GnuPG v1.4.12 (GNU/Linux)
CERTIF:          
CERTIF:          mQINBEvXHzcBEACwopvTtQLlh+vfqwolOHaplhV8x1zFjd1lT1E0CLwpsC5qpmQb
CERTIF:          o5bNlSoDDqlMG6IHP98TUWM24mZU626MuWHte/vMOE5X1Q7tk0TRREeYjXxBftaa
CERTIF:          9pGhynrjdk4FSDSZjZ5N0CgCDeX61j1TgCH0LT1EPB0/hJ+Tv2jDHc0vfCq6tnCg
CERTIF:          a3GoKrAlPOWff/nNFpXQwpLbeFDizurGXNDpGa5yBPfn0k8bKzhPa+h9geYIx+4e
CERTIF:          NbtG0J/g+GJuLhmlZyMVQ5+VYgeggbwLw8CvvcsH82v5PG5XIyceMqEXOvji5BOL
CERTIF:          jzuYFYF/XinPbWgz5q2+5hV3HsJz8jMHlkPZnj1hbHa9mT1A+xSFUQ95gbvRXgF2
CERTIF:          iOmewYUVPKoOfIhGis1cq1f4SlhrgO0vS32bBb/6hPp8EVeblGzMUhAyfc+RNbof
CERTIF:          IvUUlbp6CDy2qrCV4C0UHlyFMC4/11p2mZ63J0o88qL5sIAzwi7wuYfep+xjaYFv
CERTIF:          W8for8VZPtu9Fui6LyRvgv9OvUy5R+1wW2F1IChM9G4AbxdaYrtjtXuCuTVkfgdC
CERTIF:          CYabxcEQeh4uhjNqhP3hxAag7CI3KUud26w4Q/9kQ2BWxXMheZpDGkapfzJypbbe
CERTIF:          jLC7OHhqV6r+GoD8VmNMlKNQ/Jzvrf23Z2QLCuzSuIGwVIyKJG5y5ifecwARAQAB
CERTIF:          tCdKb25hdGhhbiBNaWNoYWxvbiA8am9obmRlc2NzQGdtYWlsLmmvbT6JAjcEEwEI
CERTIF:          ACEFAkvXHzcCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQqS0qaGeNoc1Z
CERTIF:          EA//YQ13Sl5rxBQuXZcxWvsBlON4ZjqfZB6HnOdeeIdEnR7hEVgICDD/3AEZKXs5
CERTIF:          38uwTO1h++2T47KsbBaKFK+bCJfzivSVHj6SWWlvhJZo5WUcNZ6NxX5iBfM+IZ9r
CERTIF:          /2z8LS+t/iv6jy0tNeziVCxIDf3KJ9FIUl0QOrKRMIaj9q66rkVk9qZuNQRfx+3B
CERTIF:          9g1eKyhLj/CFjzz1yANIK7Ga74bgYhXTxHEGK+JKOf+tq4RymYpdRu87YauwL3ZY
CERTIF:          KbQbG4JzNWsqnJint7pueiEOrCcTHecUgkpQpPXrk/J2Xt07XudvteUcArOoRNP4
CERTIF:          qdb9ku1kkbtlsc74DQwE9sysbZbYoIT1YD1y0x2S9IqYsW/NpsOCek+8viRUSTHK
CERTIF:          mHnYcR2RDB/6EkkU2Rwjjt3c1idnrl2u40jTtU6ZZ/3Cbqjs/HEvf5EFacxx1JVA
CERTIF:          RQI0pTja56qn3sk85avJfM1I4P0swG9Ga+wnb/K1nyuIBQJZO3W+SfpJFOgzmXBu
CERTIF:          M1IiXIjdCbzhHTcrbc9xnvaqXCf5L13ZQy+CpEyvVpAWOTd4s6Ia9PldlPaRWwIG
CERTIF:          faZKVjCKLaDKle75vrP48pinCFu5JJ+6BrTVR0LxJRsd/XF8fbcOwk4TH1z2/bOt
CERTIF:          N1N1dqHMx3RD/NZW+5nMae/MugVWZZUXJEremM3WpopvdciIRgQQEQgABgUCTL75
CERTIF:          gQAKCRD41bgH8Cma2QcnAKCWEllqpyiJn0Usj9iJa0xxsUKv2wCdFr7Buq1Ib+iu
CERTIF:          ufv5awslcQYCaNW0MEpvbmF0aGFuIE1pY2hhbG9uIChQZXJzbykgPGpvbmF0aGFu
CERTIF:          QG1pY2hhbG9uLmV1PokCNwQTAQgAIQUCUcNc4wIbAwULCQgHAwUVCgkICwUWAgMB
CERTIF:          AAIeAQIXgAAKCRCpLSpoZ42hzYaHEACqIwSOGZBPK6oT1S5PEweHC4MxgeaQQl/0
CERTIF:          uF3u4G/hEo20zVzrv4PSBuRwdBfCjnZE3NakRfJGx5Y4T2dkYrZXNrB2DG+kqyqw
CERTIF:          KMa06gC4ZGK+DyVusU5+qCLDeTXvtY6W5z7GQo1SV6iHE0iFKqoqjuaXXG8Wuh3t
CERTIF:          C12VoQOxWUi6VE6Z8Ys+E76YpLztOhy4nFeEBL8w1NIq8KDKlydjbLnBkhUes0IP
CERTIF:          tIdLynxqm+tkRUA9WaPSIY/KQoFAbTLP3WAjnNM7wCqShAwgTBhH8v66pYKt/qpk
CERTIF:          jvVCEx3C48TTDgmHXlhrZTYR5jA4wpnrJwP+FhyBdA+fKPmJHzmsNwT321fH1Z40
CERTIF:          x+xfTZSVjfkgoW9cl95Sy3JGeD1omHjmR5cURz7Iwyg02z+k86Ve44/TKMXgXa2F
CERTIF:          H7D8Zjv9AYP4xKzDF+QnPrl55KzotMX9r501AaYB913jJ14xRMFjqWphB2hijrhQ
CERTIF:          hebW5a/HI+aKLyWkdNOA7N0AYhJ5MAjaKjsG7LfOo69X7HUtWtLeOATjJFT8CgFB
CERTIF:          FfVJBrK5GQ1v6l7dgUKMgUsKCAhKE7TbU6sqWTT+ohFTHcHhlziwWA+3jEfhhR2y
CERTIF:          JFUBhZ/nFo2v69Okav29LKTooHKaFpHzXLbvUb4P/G/wX15LffHHYb9JvU+PXP1r
CERTIF:          ddSIxmwKRw==
CERTIF:          =zj2g
CERTIF:          -----END PGP PUBLIC KEY BLOCK-----
org:             ORG-TSTA1-TEST
admin-c:         JKB1-TEST
tech-c:          JKB1-TEST
MNT-BY:          TESTASSO-MNT
CHANGED:         ripedb@example.com 20140426
SOURCE:          TEST

Ce qui nous donne l'objet suivant une fois le formulaire validé :

whois -h whois-test.ripe.net -B -r PGPKEY-698DB1DD
% Information related to 'PGPKEY-698DB1DD'
 
key-cert:       PGPKEY-698DB1DD
method:         PGP
owner:          Jean-Kevin Boulay <jkb@example.net>
fingerpr:       E99E BD56 AA68 C0CD FEC2  EB25 A92D 2A68 698D B1DD
certif:         -----BEGIN PGP PUBLIC KEY BLOCK-----
certif:         Version: GnuPG v1.4.12 (GNU/Linux)
certif:          
certif:         mQINBEvXHzcBEACwopvTtQLlh+vfqwolOHaplhV8x1zFjd1lT1E0CLwpsC5qpmQb
certif:         o5bNlSoDDqlMG6IHP98TUWM24mZU626MuWHte/vMOE5X1Q7tk0TRREeYjXxBftaa
certif:         9pGhynrjdk4FSDSZjZ5N0CgCDeX61j1TgCH0LT1EPB0/hJ+Tv2jDHc0vfCq6tnCg
certif:         a3GoKrAlPOWff/nNFpXQwpLbeFDizurGXNDpGa5yBPfn0k8bKzhPa+h9geYIx+4e
certif:         NbtG0J/g+GJuLhmlZyMVQ5+VYgeggbwLw8CvvcsH82v5PG5XIyceMqEXOvji5BOL
certif:         jzuYFYF/XinPbWgz5q2+5hV3HsJz8jMHlkPZnj1hbHa9mT1A+xSFUQ95gbvRXgF2
certif:         iOmewYUVPKoOfIhGis1cq1f4SlhrgO0vS32bBb/6hPp8EVeblGzMUhAyfc+RNbof
certif:         IvUUlbp6CDy2qrCV4C0UHlyFMC4/11p2mZ63J0o88qL5sIAzwi7wuYfep+xjaYFv
certif:         W8for8VZPtu9Fui6LyRvgv9OvUy5R+1wW2F1IChM9G4AbxdaYrtjtXuCuTVkfgdC
certif:         CYabxcEQeh4uhjNqhP3hxAag7CI3KUud26w4Q/9kQ2BWxXMheZpDGkapfzJypbbe
certif:         jLC7OHhqV6r+GoD8VmNMlKNQ/Jzvrf23Z2QLCuzSuIGwVIyKJG5y5ifecwARAQAB
certif:         tCdKb25hdGhhbiBNaWNoYWxvbiA8am9obmRlc2NzQGdtYWlsLmmvbT6JAjcEEwEI
certif:         ACEFAkvXHzcCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQqS0qaGeNoc1Z
certif:         EA//YQ13Sl5rxBQuXZcxWvsBlON4ZjqfZB6HnOdeeIdEnR7hEVgICDD/3AEZKXs5
certif:         38uwTO1h++2T47KsbBaKFK+bCJfzivSVHj6SWWlvhJZo5WUcNZ6NxX5iBfM+IZ9r
certif:         /2z8LS+t/iv6jy0tNeziVCxIDf3KJ9FIUl0QOrKRMIaj9q66rkVk9qZuNQRfx+3B
certif:         9g1eKyhLj/CFjzz1yANIK7Ga74bgYhXTxHEGK+JKOf+tq4RymYpdRu87YauwL3ZY
certif:         KbQbG4JzNWsqnJint7pueiEOrCcTHecUgkpQpPXrk/J2Xt07XudvteUcArOoRNP4
certif:         qdb9ku1kkbtlsc74DQwE9sysbZbYoIT1YD1y0x2S9IqYsW/NpsOCek+8viRUSTHK
certif:         mHnYcR2RDB/6EkkU2Rwjjt3c1idnrl2u40jTtU6ZZ/3Cbqjs/HEvf5EFacxx1JVA
certif:         RQI0pTja56qn3sk85avJfM1I4P0swG9Ga+wnb/K1nyuIBQJZO3W+SfpJFOgzmXBu
certif:         M1IiXIjdCbzhHTcrbc9xnvaqXCf5L13ZQy+CpEyvVpAWOTd4s6Ia9PldlPaRWwIG
certif:         faZKVjCKLaDKle75vrP48pinCFu5JJ+6BrTVR0LxJRsd/XF8fbcOwk4TH1z2/bOt
certif:         N1N1dqHMx3RD/NZW+5nMae/MugVWZZUXJEremM3WpopvdciIRgQQEQgABgUCTL75
certif:         gQAKCRD41bgH8Cma2QcnAKCWEllqpyiJn0Usj9iJa0xxsUKv2wCdFr7Buq1Ib+iu
certif:         ufv5awslcQYCaNW0MEpvbmF0aGFuIE1pY2hhbG9uIChQZXJzbykgPGpvbmF0aGFu
certif:         QG1pY2hhbG9uLmV1PokCNwQTAQgAIQUCUcNc4wIbAwULCQgHAwUVCgkICwUWAgMB
certif:         AAIeAQIXgAAKCRCpLSpoZ42hzYaHEACqIwSOGZBPK6oT1S5PEweHC4MxgeaQQl/0
certif:         uF3u4G/hEo20zVzrv4PSBuRwdBfCjnZE3NakRfJGx5Y4T2dkYrZXNrB2DG+kqyqw
certif:         KMa06gC4ZGK+DyVusU5+qCLDeTXvtY6W5z7GQo1SV6iHE0iFKqoqjuaXXG8Wuh3t
certif:         C12VoQOxWUi6VE6Z8Ys+E76YpLztOhy4nFeEBL8w1NIq8KDKlydjbLnBkhUes0IP
certif:         tIdLynxqm+tkRUA9WaPSIY/KQoFAbTLP3WAjnNM7wCqShAwgTBhH8v66pYKt/qpk
certif:         jvVCEx3C48TTDgmHXlhrZTYR5jA4wpnrJwP+FhyBdA+fKPmJHzmsNwT321fH1Z40
certif:         x+xfTZSVjfkgoW9cl95Sy3JGeD1omHjmR5cURz7Iwyg02z+k86Ve44/TKMXgXa2F
certif:         H7D8Zjv9AYP4xKzDF+QnPrl55KzotMX9r501AaYB913jJ14xRMFjqWphB2hijrhQ
certif:         hebW5a/HI+aKLyWkdNOA7N0AYhJ5MAjaKjsG7LfOo69X7HUtWtLeOATjJFT8CgFB
certif:         FfVJBrK5GQ1v6l7dgUKMgUsKCAhKE7TbU6sqWTT+ohFTHcHhlziwWA+3jEfhhR2y
certif:         JFUBhZ/nFo2v69Okav29LKTooHKaFpHzXLbvUb4P/G/wX15LffHHYb9JvU+PXP1r
certif:         ddSIxmwKRw==
certif:         =zj2g
certif:         -----END PGP PUBLIC KEY BLOCK-----
org:            ORG-TSTA1-TEST
admin-c:        JKB1-TEST
tech-c:         JKB1-TEST
mnt-by:         TESTASSO-MNT
changed:        ripedb@example.com 20140426
source:         TEST

La deuxième étape est de lier votre nouvel objet key-cert à votre objet de type mntner. Cela se fait avec un attribut « auth » dans l'objet mntner. Exemple : « auth: PGPKEY-698DB1DD ».

Vous pouvez désormais soumettre des objets signés par mail au robot du RIPE :

  1. Il faut obtenir une copie complète (-B) de l'objet que vous souhaitez modifier. Exemple :
    whois -h whois-test.ripe.net -B -r JKB1-TEST > jkb1
  2. On modifie avec notre éditeur de texte favori. Dans mon cas, j'ajoute un attribut « remarks » et un attribut « changed ».
  3. On signe en gardant le texte en clair (on ajoute la signature à la fin, voir : Gnu Privacy Guard (GnuPG) Mini Howto (Français)) :
    gpg -u <id_de_votre_cle> --armor --clearsign jkb1

    On obtient un fichier jkb1.asc qui contient quelque chose dans ce genre :

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256
     
    Avertissement : des options RIPE ont été utilisées avec un serveur classique.
    % This is the RIPE Database query service.
    % The objects are in RPSL format.
    %
    % The RIPE Database is subject to Terms and Conditions.
    % See http://www.ripe.net/db/support/db-terms-conditions.pdf
     
    % Information related to 'JKB1-TEST'
     
    person:         J-K Boulay
    address:        FR
    phone:          +33123456789
    e-mail:         ripedb@example.com
    nic-hdl:        JKB1-TEST
    mnt-by:         TESTASSO-MNT
    remarks:        Ceci est un test
    changed:        ripedb@example.com 20140418
    changed:        jkb@example.net 20140426
    source:         TEST
     
    % This query was served by the RIPE Database Query Service version 1.72 (DBC-WHOIS4)
     
     
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.12 (GNU/Linux)
     
    iQIcBAEBCAAGBQJTXBLSAAoJEKktKmhnjaHNb4MP/0aF2GABfKvilKSrGiCn7RUH
    yQ9k4D8SN7nJi6jJK9skvcELTp7eTEuCQmvNTuO2RFg5362bm1UNOcjKZep5++8h
    i79wcjolfyxjkFrlOJaLVDmF1fVR+aqo5+ZoWNfbnba5pP8HyVY+n7027OvDO2yL
    mwcGSKD7h/Za2dYl0wnWF9dlmcIGcYk+m5ruKb3bqjpTF79n4S3/ua+WzACkX9UH
    Mg2B60xJoVIAO0A/o7y6UvxCO7+8mI/E3Y2B4AVYOvRaJ1QnJpU/Ty1csx9pDbJg
    dicChmOaZ+EbXYHLi0axc8ixucpo0mFIXQ4nIV1lear3E5EaVv7wx/wr1r7d5BYi
    g8BpLGB60hYBISpoEUlWF/V8hxf7pM3QNUagm+MjLzvMFLLcx9s58P0urVzijPPX
    b1H4Tzorx6Lcm512Gcu2IfHGVVxO0JTfCXPgubDTV2QcSS4RL5vF7C8J0nrGr59m
    Nw5hUBW+J0nV1418yVB4oXIC+Q0LFN5rfFRRlahhTZ5aGR/ieU+Ftk6MPE+Nt43o
    bfO64IfCkrb4XKSFzwbpCcFlAkImFuun74L+dOfVstzEMYc0p5XetN1IEhPeppiv
    j0S/p1tmCDHEkUZUkl51xAeRiQdqqVwx4P20tW7P9Dt7H4yqABgas6Yyia5DVjLj
    MZYvC/9Fm4s1ysKQctwP
    =74PE
    -----END PGP SIGNATURE-----
  4. On envoie notre objet signé avec notre MUA préféré. Exemple :
    mail -s "" test-dbm@ripe.net < jkb1.asc

On reçoit un mail récapitulatif : réussite ou échec, ce qui ne s'est pas bien passé, ... Exemple :

SUMMARY OF UPDATE:
 
Number of objects found:                   1
Number of objects processed successfully:  1
  Create:         0
  Modify:         1
  Delete:         0
  No Operation:   0
Number of objects processed with errors:   0
  Create:         0
  Modify:         0
  Delete:         0
 
DETAILED EXPLANATION:
 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following object(s) were processed SUCCESSFULLY:
 
---
Modify SUCCEEDED: [person] JKB1-TEST   JK Boulay
 
 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following paragraph(s) do not look like objects
and were NOT PROCESSED:
 
Avertissement : des options RIPE ont été utilisées avec un serveur classique.
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
 
% Information related to 'JKB1-TEST'
 
% This query was served by the RIPE Database Query Service version 1.72 (DBC-WHOIS4)
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
The RIPE Database is subject to Terms and Conditions:
http://www.ripe.net/db/support/db-terms-conditions.pdf
 
For assistance or clarification please contact:
RIPE Database Administration <ripe-dbm@ripe.net>
 
Generated by RIPE WHOIS Update version 1.72 on DBC-WHOIS2
Handled email update (TEST, 2014-04-26 23:42:04)

Il est possible de soumettre plusieurs objets en même temps, signés (avec la même clé ou non) ou non-signés (il faudra alors un mot de passe dans un attribut « password ») ce qui est très pratique pour une modification de masse. Un maintainer peut avoir plusieurs clés PGP. L'authentification se fait "en OU LOGIQUE" sur tous les moyens d'authentification (clé PGP ou non) associés à un des objets maintainer qui sont associés à l'objet à modifier.

Merci à Johndescs pour ces tests.
Fin de l'édit

Faire le ménage dans la base de test

Pour supprimer tous les objets que vous avez créés dans la base de test, il faut les rechercher et choisir l'option « delete ». À cause de la référence circulaire entre vos objets de types mntner et person, vous ne pourrez pas les supprimer directement. Néanmoins, sur cette base de test, on peut ruser : casser la référence circulaire en définissant « TEST-DBM-MNT » comme mntner de l'objet personn et « AA1-TEST » comme admin-c de l'objet mntner. Ça fonctionne uniquement car nous avons le mot de passe de « TEST-DBM-MNT ». J'imagine qu'il existe une méthode plus pragmatique voire un bête formulaire web mais je ne l'ai pas trouvé. Notons quand même que cette base de données est purgée tous les jours à 0h.

Dernières remarques

On notera que les attributs « tech-c » et « admin-c » de tous les objets peuvent pointer sur un seul et même objet de type person.

Enfin, si l'on souhaite visualiser les objets de la base du RIPE sous un format graphique conviviale, l'onglet « Database » de l'outil Ripestat est là pour ça.

ÉDIT du 26/04/2014 à 22h00 :
L'attribut « changed » doit dire qui a modifié/créé un objet et quand. Qui est une adresse email. Quand est une date au format AAAAMMJJ. Il n'est pas nécessaire de remplir la date, elle est auto-complétée. L'attribut changed ne se met pas à jour tout seul lors d'une modification. 😉 Il peut y avoir plusieurs attributs changed pour un même objet, ce qui permet d'avoir un historique des modifications de cet objet.

Ne pas créer/modifier deux objets en parallèle dans deux onglets différents du même navigateur si les deux objets ne sont pas dans la même source (RIPE/TEST) sinon l'application web se prend les pieds dans le tapis et vous hurle dessus : « Unrecognized source: TEST ». Dans cet exemple, ça parle de TEST alors que je voulais soumettre un objet dans RIPE mais comme j'avais ouvert ce formulaire puis ouvert un autre onglet dans TEST pour faire un test ...

Ce formulaire permet d'avoir rapidement l'adresse mail à contacter en cas d'abus. Il suffit de saisir une adresse IP, un ASN ou un inet(6)num. Cela retourne la valeur de l'attribut « abuse-mailbox » d'un objet de type « role » (qui représente une personne/un groupe de personnes dédié à la même tâche (administratif, adminsys, ...) au sein d'une organisation) lui même associé à un objet de type « organisation » (avec un attribut « abuse-c ») lui même associé à la ressource recherchée (aut-num ou inet(6)num). Si cette recherche est infructueuse (car pas d'objet organisation, car pas d'attribut « abuse-c », ...), elle se poursuit récursivement sur les ressources englobantes (as-block englobant, inet(6)num englobant). Merci à Lulu pour la découverte de ce formulaire.
Fin de l'édit

Un sac à dos pour un ordinateur portable 17 pouces

Aujourd'hui, je vous propose un billet futile : un feedback sur un sac à dos pour ordinateur portable.

Il y a un peu plus d'un an et demi, je me rendais compte que la petite sacoche pour transporter un ordinateur portable à la main ce n'était pas le top : fatigue des bras (alors qu'ils doivent rester opérationnels pour le porn 😛 ), peu de capacité (à part l'ordinateur, tu transportes quasiment rien). Et puis surtout, avec le Clevo 17 pouces monstrueux (il y a moyen de tuer des gens rien qu'avec le transfo-brique, pour situer un peu) que je venais de m'acheter, ça n'allais plus être possible de porter ça à bout de bras.

Je me suis donc mis à la recherche d'un sac à dos pour un ordinateur portable 17 pouces. Il me fallait un sac à dos avec de la capacité et qui soit résistant (CNR approved, vous voyez ... pardon). Je n'ai pas sélectionné le sac de manière rationnelle, à comparer les marques puis les gammes puis ... Vu mon extrême satisfaction à l'encontre d'Eastpak, j'ai décidé de me tourner uniquement vers cette marque.

Au final, j'ai choisi un Eastpak Core Series K202 Hutson Black. Comme d'habitude avec Eastpak, le coût d'acquisition est élevé (on parle de 90€ tout de même) mais se rentabilise avec l'âge (habituel débat : vaut-il mieux un sac cher à l'acquisition mais qui résiste au temps ou un sac peu cher qu'il faut renouveler tous les 2 ans ?) .

Pendant un an et demi, je pense avoir fait le tour de ce sac donc voici mon feedback :

  • Capacité : ce sac est juste un monstre ... Sans faire de casse, on peut y loger, en même temps : un ordinateur portable 17 pouces monstrueux de chez Clevo, un portable 15 pouces plus traditionnel de chez Compaq, un trieur de documents, les deux tranfos, des câbles réseaux, un switch à usage personnel de 8 ports, une souris, une trousse (stylos, marqueurs, ...) bien remplie, les nécessaires clés USB/WiFi, un disque dur externe 3,5 pouces, une rallonge électrique de 5 mètres, une multiprises bloc de 5 prises, un assortiment de câbles (rallonge USB, câbles USB dans toutes les déclinaison (mini/micro), tournevis ... Et j'en oublie très certainement, monstrueux je vois dis. Je ne dis pas que je transporte tout ça, tous les jours (quel intérêt ? quoi que ... pour la boîte à outils d'un expert judiciaire en informatique ...) mais c'est pratique quand j'ai besoin de transporter tout ça. Et le reste du temps, ça laisse de la place pour des imprévus.
  • Résistant à la pluie et je ne parle pas de brume ou de gouttelettes mais bien de douches. On n'a pas toujours le choix dans l'heure de nos déplacements.
  • Résistant aux chocs : je ne suis pas apte à juger, je n'ai pas pour habitude de cogner mes affaires personnelles partout. Mais pas de casse à déplorer en un an et demi.
  • Agréable : malgré le poids potentiel, les bretelles ne font pas mal aux épaules (bretelles matelassés + sangle avant pour soulager), l'ordinateur ne cogne pas dans le dos quand on marche (arrière matelassé).

Bref, un excellent sac à dos pour un ordinateur portable de 17 pouces et toutes les babioles que se trimballe un geek. Je le recommande.

Le mot de la fin : non, ce billet n'est pas un billet payé, venez pas me faire chier avec ça !

Mon Shaarli

Depuis longtemps déjà, je me pose la question de mes supports personnels d'expression sur Internet. J'ai plaqué mon premier site web statique (sauf inclusion dynamique des menu/header/footer, pas fou non plus :P) car il ne me semblait pas correspondre à mes besoins. J'ai pris un blog dynamique et je me suis rend de plus en plus compte qu'il ne correspond pas à l'outil qu'il me faut dans toutes les situations.

J'ai parfois envie d'écrire de courtes réactions sur des sujets ou des documents que je découvre. J'ai parfois envie de m'indigner devant certaines actualités et devant certaines déclarations de ceux qui ont le droit au chapitre par copinage et tradition.

J'ai envie de partager la connaissance et le lulz. L'humanité s'est doté de son plus puissant outil d'expression (Internet, quoi d'autre !) mais ne se l'est pas encore approprié. Beaucoup de choses, de la documentation, des avis, des retours d'expérience ne sont pas partagés ou insuffisamment. Il y a encore des données à faire tourner, c'est une certitude. Moi aussi, je suis fautif. Je vais tenter d'évoluer.

Quand j'arrive dans la console WordPress, que je vois ce vaste formulaire blanc qui ne demande qu'à être rempli. Je me sens obligé de remplir, même pour présenter un simple lien (ou un simple outil que je vais utiliser :P). Je ne suis pas écrivain, je n'ai pas le plaisir de l'écriture qu'ils ressentent mais je pense que le lecteur est intelligent et qu'il a le droit de savoir tout ce que je sais sur un sujet donné. Tu dis tout ou tu te tais ! Tous mes billets sont basés sur cette idée. Libre à lui de lire mes pavés, ce n'est plus mon problème : j'ai partagé, chacun accepte, ou non, de recevoir.

Je partage déjà, avec un léger retard certes, toutes mes manipulations. Mais les ressources que je trouve, documentation, avis ou futilité, et qui sont déjà "complètes", ne méritent-elles pas d'être partagés elles aussi ? Il y a encore des données à faire tourner, c'est une certitude (bis ;)).

Un billet de blog ne me semble clairement pas adapté au partage de liens. C'est pour ça que j'attendais parfois d'avoir plusieurs avis à formuler pour les regrouper dans un billet : voir exemple 1 ou bien encore exemple 2. Mais l'actualité se fane et du coup j'ai manqué des occasions de m'exprimer. Mauvais raisonnement, changer raisonnement.

Il me faut un nouvel outil d'expression.

En gros je cherchais un outil pour :

  • Partager des liens, que ça pointe sur des futilités ou de la documentation, que ce soit des trucs vieux ou des trucs récents ;
  • Partager mon avis sur l'actualité, sur une humeur du moment, sur une méthodologie, sur une documentation ("non, le plus simple serait de faire comme ça pour telle raison"), ... ;
  • Annoter ou pas un lien ;
  • Répondre rapidement et simplement à une déclaration ;
  • Faire évoluer ma façon de m'exprimer, tout simplement.

Je voulais qu'il :

  • Me permette d''écrire un roman (pour donner des infos en plus dont j'ai connaissance ou pour placer un contexte) ou juste un mot ou une courte phrase concernant le document que je partage. En gros je veux pouvoir écrire moins de 140 caractères mais aussi plus de 140 caractères quand ça me chante. Ce n'est pas à l'outil de décider comment je m'exprime ;
  • Soit sans un raccourcisseur d'URL à la con ;
  • Soit conviviale, simple, qui juste marche et pas codé avec les pieds. Tout le contraire de WordPress quoi.

L'outil Shaarli de SebSauvage me semble être ce que je recherche. Au pire j'essaye, ça n'engage à rien.

Du coup, c'est accessible à cette adresse, mon Shaarli, en HTTP et en HTTPS et il y a un lien dans le menu horizontal. Le flux RSS associé est disponible à cette adresse.

Shaarli sera complémentaire à ce blog.

J'ai commencé à le remplir.

Tout ce pavé pour dire ça ... Il y a encore des progrès à faire ... #autoTroll 😛