Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.


APIdays et mon exposé sur Internet et les droits humains

Première rédaction de cet article le 13 décembre 2018


Les 11 et 12 décembre 2018, à Paris (enfin, à Montrouge), s'est tenue une édition des API Days, conférence consacrée aux API. J'y ai parlé (en anglais) d'Internet et de ses rapports avec les droits humains.

Globalement, API days verse un peu trop dans le techno-optimisme et la cyber-béatitude : les API vont sauver le monde, la société va devenir « programmable », l'Estonie est le modèle (comme l'était l'URSS pour les communistes, l'Estonie est toujours présentée comme modèle par les startupeurs et les partisans du E-nimportequoi). Les orateurs sont heureux, actifs, ont des titres rigolos (API evangelist…), ont un sourire de publicité pour dentifrice, et répètent en boucle que tout est amazing.

Heureusement, il y a quelques séances moins consensuelles. J'ai particulièrement apprécié la keynote de fin par Jean-Marc Jancovici, sur l'énergie et le climat. Jancovici est un remarquable conférencier, très amateur de petites phrases qui claquent, et illustre son exposé de nombreux chiffres et diagrammes. Il a démoli l'idée qu'on pourrait éviter ou limiter le changement climatique avec juste quelques mesurettes, comme aiment annoncer certaines entreprises du secteur de l'informatique. Notre dépendance aux énergies fossiles, et à des matériaux rares comme l'indium est profondément enracinée et changer les choses va nécessiter des sacrifices douloureux (l'alternative étant une crise climatique grave, avec guerres, on voit que le conférencier était un optimiste). Les machines sont tellement utiles et tellement puissantes, qu'à part des mesures brutales et immorales, comme de rétablir l'esclavage (et encore : les esclaves sont beaucoup moins productifs que les machines), la limitation du réchauffement planétaire va être difficile. (L'orateur ne croit pas aux énergies renouvelables, très insuffisantes par rapport à la demande. Elles sont réalistes - après tout, l'humanité a vécu pendant la plus grande partie de l'histoire en ne consommant que des ressources renouvelables - mais pas adaptées à notre mode de vie.)

Jancovici a aussi démoli la théorie cyber-optimiste comme quoi l'informatique pourrait aider à lutter contre le changement climatique, par exemple par une meilleure allocation des ressources. C'est le contraire qui est vrai : l'informatique, outre sa consommation propre, qui n'est pas nulle, permet une plus grande consommation de ressources non-renouvelables. Ainsi, en permettant un trafic aérien intense, elle contribue à un secteur, le transport, qui est un des plus gros responsables de l'émission de gaz à effet de serre. Jancovici a estimé qu'au contraire, il allait falloir réduire les usages, changer moins souvent d'ordiphone, et ne pas déployer certaines technologies gaspilleuses comme la 5G.

Mon exposé était nettement plus banal, il portait sur les rapports entre l'Internet et les droits humains. Les supports sont en anglais. Voici la version PDF, et le source en LaTeX. Normalement, tout a été filmé et devrait être disponible sur le site Web d'API days bientôt.


L'article seul

Détails techniques sur l'écriture de mon livre « Cyberstructure »

Première rédaction de cet article le 12 décembre 2018


Comme vous avez pu le voir dans un autre article, j'ai écrit un livre nommé « Cyberstructure » et qui parle des relations entre l'architecture technique de l'Internet et les questions politiques. Ce nouvel article est destiné uniquement aux détails techniques de l'écriture, pour ceux et celles qui se demandent « tu as utilisé quel logiciel pour faire ce livre ? ». Je ne parlerai donc pas ici du contenu du livre.

D'abord, pour les outils utilisés, il faut bien voir que l'auteur n'a pas une liberté complète puisqu'un livre est un travail collectif. Il faut donc une discussion avec l'éditeur, du moins si, comme moi, on a un éditeur qui se penche sur le texte, au lieu de demander à l'auteur des images qu'on imprimera telles quelles. D'autre part, dans mon cas, la mise en page était faite par l'éditeur (avec InDesign), donc je n'avais pas à me soucier du rendu, je pouvais me concentrer sur le texte. Enfin, certains choix ne concernaient que moi, puisqu'ils ne changeaient rien à ce qui était échangé avec l'éditeur.

Les choix importants, après cette discussion, étaient :

Pourquoi ces choix ? Commençons par le format XML. C'est un format simple pour l'auteur, bien adapté au texte (contrairement à JSON) grâce notamment à la possibilité de mélanger élements structurés et texte, comme par exemple :


  <p>L'ARJEL, l'autorité de régulation des jeux en ligne, a
  été, sauf erreur, la première autorité ayant ce droit de censurer,
  sur la base du décret <cite url="https://www.legifrance.gouv.fr/eli/decret/2011/12/30/BCRB1120950D/jo/texte">n° 2011-2122 du 30 décembre 2011 relatif aux
  modalités d'arrêt de l'accès à une activité d'offre de paris ou de
  jeux d'argent et de hasard en ligne non autorisée</cite>. [...]
  C'est ainsi que des sites distribuant des fichiers
  « torrent » <ref target="bittorrent">pour une explication</ref>
  comme The Pirate Bay ou T411 ont fait l'objet de décisions de justice
  imposant leur blocage.</p>
	     

Et, contrairement à JSON, on peut y mettre des commentaires, ce qui aide beaucoup l'auteur au long des mois de réécriture et de modifications. La discussion avec l'éditeur a permis de s'assurer qu'InDesign pouvait importer du XML sans mal, et le choix de XML a donc été en partie guidé par l'éditeur. (Par exemple, il n'y avait pas de moyen simple d'importer du LaTeX. LaTeX repose sur un langage de programmation complet, qui est donc difficile à importer, sauf à utiliser le moteur TeX. XML, au contraire, ce ne sont que des données, sans programme.)

La mise en page étant faite par l'éditeur, il était important que je me limite au marquage sémantique. Par exemple <p>Le RFC 7962, <work xml:lang="en" url="https://www.rfc-editor.org/info/rfc7962">Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures</work>, sans préjuger de comment serait rendu le titre du document cité : on indique que c'est un titre, on indique la langue, et la personne qui fera la mise en page pourra suivre les bonnes pratiques de la mise en page, indépendamment du contenu. Les éléments XML possibles et leurs relations sont mises dans un schéma, écrit en Relax NG. Ce schéma est conçu uniquement pour ce livre, et je n'ai pas cherché à le faire beau ou propre ou général. Si vous voulez le voir, il est dans le fichier livre.rnc. Je teste la conformité du texte au schéma avec rnv :

% rnv livre.rnc livre-noent.xml
%
      

Un autre avantage de XML par rapport à LaTeX, dans ce contexte, est qu'il est facile de développer des outils traitant le XML et effectuant certaines opérations. Par exemple, j'ai fait un programme XSLT pour n'extraire que le texte du livre, afin de compter caractères et mots. En revanche, LaTeX est certainement imbattable quand il faut faire une jolie sortie PDF ou papier sans trop y passer de temps. Et la plupart des relecteurs, à commencer par moi, ont préféré travailler sur cette sortie que sur le source XML. Pas de difficulté, encore un autre programme XSLT, pour convertir le XML en LaTeX, qui était ensuite traité. Voici ce programme : tolatex.xsl, mais rappelez-vous que ce n'est pas lui qui a été utilisé pour le rendu final du livre. (Pour faire tourner ce programme XSLT, j'ai utilisé xsltproc, dans la libxslt. Au passage, certains des outils étaient d'usage compliqué donc j'ai utilisé le classique make pour orchestrer leur exécution.)

Notez que les techniques utilisée pour le livre étaient assez proches, voire identiques, à celles de mon blog ce qui n'est évidemment pas un hasard. Les techniques du blog sont déjà documentées.

Apparemment, la plupart des auteurs de livres utilisent plutôt un gros cliquodrome comme Word ou LibreOffice. Mais je n'aime pas ces logiciels (j'avais déjà critiqué leur approche afterword il y a plus de dix-sept ans.)

Le XML a l'avantage, comme JSON ou LaTeX, d'être un format texte, donc qui peut être traité avec tous les outils existants. C'est par exemple le cas du choix de l'éditeur (l'éditeur de textes, pas l'éditeur du livre). Pas besoin de concertation, cette fois, ce choix de l'éditeur de textes est purement local et n'affecte pas ce qui est envoyé à l'éditeur du livre. J'ai donc utilisé mon éditeur préféré, emacs. On peut écrire du XML avec le mode de base d'Emacs mais ce n'est pas très amusant (taper le début de l'élement XML, sa fin, penser à bien fermer tout ce qui a été ouvert), il vaut donc mieux utiliser un mode Emacs adapté au XML. J'ai utilisé nxml-mode. À part le fait qu'il économise du temps de frappe, et qu'il affiche le source XML proprement coloré (les noms des éléments en bleu, les commentaires en rouge, pour les distinguer du texte), le gros avantage de nxml-mode est qu'il connait Relax NG, et qu'une fois configuré pour utiliser mon schéma, il peut guider l'écriture, indiquant quels sont les éléments XML acceptables à l'endroit où se trouve le curseur, et validant le résultat au fur et à mesure. Grâce à cela, la validation XML complète, faite avec rnv, était quasiment inutile.

Le schéma XML que j'avais fait me semblait raisonnable, avec un usage intelligent des éléments et des attributs XML (un sujet toujours passionnel dans le monde XML). Mais lors de l'importation dans InDesign, un problème est apparu : sauf exception, InDesign ne permet pas de mettre du contenu dans les attributs. Il a donc fallu transformer plusieurs attributs en éléments, avec le programme XSL toindesign.xsl.

Contrairement à mon blog, où certains articles ont été écrits d'une seule traite, ce livre a fait l'objet de retours, de révisions, de critiques et de remords. Il a donc fallu le modifier plusieurs fois, et parfois remettre en place des paragraphes que j'avais effacé quelques jours plus tôt. L'outil idéal pour cela est évidemment le VCS. Comme VCS, j'ai choisi darcs. Il est moins connu que git mais bien plus facile à utiliser. Il ne fournit pas de mécanisme de coopération pratique, mais ce n'est pas grave ici, puisque j'étais seul à travailler sur le texte. Le reproche que j'ai le plus entendu sur darcs est qu'il n'a pas le concept de branches. Cela me parait plutôt un avantage : d'abord, les branches sont très compliquées à utiliser, et ensuite un VCS décentralisé, comme git ou darcs, n'a pas vraiment besoin de branches : il suffit de faire des dépôts différents.

Comme tous les VCS, darcs permet de voir l'historique d'un travail :

patch f1c1609a11c27b0a125057f3afe0e91d537f1fdb
Author: stephane@sources.org
Date:   Sun Dec 10 17:54:48 CET 2017
  * Traduction en XML de plan, avant-propos et middleboxes, rédaction de utilisateurs

patch 28b1ff5fef2d627f662d41cabda249bb585fec69
Author: stephane@sources.org
Date:   Sun Dec 10 12:20:17 CET 2017
  * Début de la version XML

patch 7e38de35163eccb6365502ec0ad189dcd3af5446
Author: stephane@sources.org
Date:   Wed Nov 29 10:16:05 CET 2017
  * Questions à l'éditeur

patch 67e7a11537ccc3d5d0b02d4bf83a3ae051bca25d
Author: stephane@sources.org
Date:   Wed Nov 22 16:20:17 CET 2017
  * Article middleboxes

patch 3e71659b7b880f5cad02a441368a0e753b36de15
Author: stephane@sources.org
Date:   Sun Nov  5 17:13:40 CET 2017
  * Début du travail sur le livre     
   

Cela permet aussi de voir combien de commits sont faits :

%  darcs    changes . --count
Changes to Livre:
485
   

(Oui, on aurait pu faire darcs changes . | grep Date | wc -l .) Comme toutes les métriques quantitatives d'un travail humain, ce chiffre n'a guère de signification ; il dépend de si on commite souvent ou seulement à la fin de la journée, par exemple. C'est juste amusant.

Un avantage important d'un VCS réparti (comme darcs ou git) est que chaque copie locale est un historique complet du travail. Tout est donc automatiquement réparti sur chaque machine (le PC fixe à la maison, le portable en déplacement, plus une ou deux machines hébergées à l'extérieur, et une clé USB…), ce qui est une forme efficace de sauvegarde. J'ai vu plus d'une fois un étudiant perdre toute sa thèse parce que les fichiers se trouvaient sur une seule machine, en panne, perdue ou volée, pour ne pas avoir envie de faire comme eux. Et l'utilisation du VCS réparti pour cela est moins pénible que la plupart des systèmes de sauvegarde.

J'ai dit plus haut que les métriques quantitatives n'avaient guère de sens ; l'avancement du travail ne se mesure pas au nombre de caractères tapés ! Si ces métriques sont assez ridicules quand des chefs de projet prétendent les utiliser pour suivre le travail de leurs subordonnés, elles sont quand même utiles à l'auteur qui :

  • Sait quelle confiance limitée il faut leur accorder,
  • A envie de suivre un peu ce qu'il fait.

J'ai donc écrit quelques scripts très simples pour compter quelques trucs que je trouve utiles. Pour compter le nombre de caractères, je me sers d'un programme XSLT, totext.xsl, qui garde uniquement le texte avant de passer à wc (utiliser wc sur le fichier XML compterait en trop toutes les balises XML) :

% make count
xsltproc totext.xsl livre-noent.xml > livre.txt	
wc -c livre.txt
577930 livre.txt
   

Je marque les choses à faire dans le texte avec la chaîne de caractères « TODO » (à faire). Il y a donc aussi des scripts pour compter ces TODO. Par exemple, make count comptait aussi les TODO :

% make count
xsltproc totext.xsl livre-noent.xml > livre.txt	
wc -c livre.txt
432717 livre.txt
Encore 59 TODO

Le source du livre était découpé en plusieurs fichiers, donc il était utile pour moi de savoir quels fichiers avaient le plus de TODO, avec grep et sort :

  
% make todo
grep -c TODO *xml | grep -v ':0$' | sort -r -n -t: -k 2
neutralite.xml:8
censure.xml:7
technique.xml:6
gouvernance.xml:5
blockchain.xml:5
droitshumains.xml:4
securite.xml:3
plateformes.xml:3
adresse-ip-exposee.xml:3
acces.xml:3
...

Il était également utile pour moi de compter la proportion de TODO par fichier (certains sont plus gros que d'autres) :

% ./todo-pct.sh 
protocoles.xml:3
gouvernance.xml:2
finances.xml:0
...

(Oui, le script est disponible ici.)

Le livre bénéficie d'un site Web d'accompagnement, https://cyberstructure.fr/. C'est un site Web statique, utilisant le générateur de sites statique Pelican.

Je n'ai pas utilisé de correcteur orthographique. Il en existe en logiciel libre comme aspell mais je les trouve peu utiles : je fais relativement peu de fautes d'orthographe, j'ai d'excellents correcteurs humains, et il y a beaucoup de termes techniques dans le livre que le correcteur informatique ne connait pas, ce qui aurait rendu son utilisation pénible. (Il faut ajouter plein de mots à la première utilisation.)

    
% aspell check -l FR livre.txt

(Il faut avoir installé le paquetage aspell-fr pour avoir les mots français.)

Je ne suis pas bon pour les dessins (disons même que je suis franchement nul). Les schémas ont donc été faits de manière sommaire avec Asymptote, puis refaits proprement par un graphiste professionnel.


L'article seul

RFC 8427: Representing DNS Messages in JSON

Date de publication du RFC : Juillet 2018
Auteur(s) du RFC : P. Hoffman (ICANN)
Pour information
Première rédaction de cet article le 11 décembre 2018


Le format des messages DNS circulant sur le réseau est un format binaire, pas forcément évident à analyser. Pour beaucoup d'applications, il serait sans doute préférable d'utiliser un format normalisé et plus agréable, par exemple JSON, dont ce nouveau RFC décrit l'utilisation pour le DNS.

Non seulement le format des messages DNS est du binaire (RFC 1035, section 4) et non pas du texte comme par exemple pour SMTP, XMPP ou HTTP, mais en plus il y a des pièges. Par exemple, la longueur des sections du message est indiquée dans un champ séparé de la section, et peut ne pas correspondre à la vraie longueur. La compression des noms n'arrange rien. Écrire un analyseur de messages DNS est donc difficile.

Il y a un million de formats pour des données structurées mais, aujourd'hui, le format texte le plus populaire pour ces données est certainement JSON, normalisé dans le RFC 8259. L'utilisation de JSON pour représenter les messages DNS (requêtes ou réponses) suit les principes suivants (section 1.1 du RFC) :

  • Tout est optionnel, on peut donc ne représenter qu'une partie d'un message. (Des profils ultérieurs de cette spécification pourraient être plus rigoureux, par exemple une base de passive DNS peut imposer que QNAME, le nom de domaine demandé, soit présent, cf. section 6 du RFC.)
  • Si l'information est présente, on peut recréer le format binaire utilisé par le protocole DNS à partir du JSON (pas forcément bit pour bit, surtout s'il y avait de la compression).
  • Tous les noms sont représentés dans le sous-ensemble ASCII d'UTF-8, obligeant les IDN à être en Punycode (alors que JSON permet l'UTF-8).
  • Les données binaires peuvent être stockées, à condition d'être encodées en Base16 (RFC 4648).
  • Il n'y a pas de forme canonique : le même message DNS peut être représenté par plusieurs objets JSON différents.
  • Certains membres des objets JSON sont redondants et il peut donc y avoir des incohérences (par exemple entre la longueur indiquée d'une section ou d'un message, et sa longueur réelle, cf. la section 8 sur les conséquences que cela a pour la sécurité). Cela est nécessaire pour reconstituer certains messages DNS malformés. Autrement, le format serait limité aux messages corrects.
  • Le format représente des messages, pas des fichiers de zone (RFC 1035, section 5).

La section 2 du RFC donne la liste des membres (au sens JSON de « champs d'un objet ») d'un objet DNS. Voici un exemple d'un tel objet, une requête DNS demandant l'adresse IPv4 (code 1, souvent noté A) d'example.com :

{ "ID": 19678, "QR": 0, "Opcode": 0,
     "AA": 0, "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0, "RCODE": 0,
     "QDCOUNT": 1, "ANCOUNT": 0, "NSCOUNT": 0, "ARCOUNT": 0,
     "QNAME": "example.com", "QTYPE": 1, "QCLASS": 1
   }
    

Les noms des membres sont ceux utilisés dans les RFC DNS, même s'ils ne sont pas très parlants (RCODE au lieu ReturnCode).

On note que les différents membres qui sont dans le DNS représentés par des entiers le sont également ici, au lieu d'utiliser les abréviations courantes. Ainsi, Opcode est marqué 0 et pas Q (query), et QTYPE (query type) est marqué 1 et pas A (adresse IPv4). Cela permet de représenter des valeurs inconnues, qui n'ont pas d'abréviation textuelle, même si ça rend le résultat peu lisible si on ne connait pas les valeurs des paramètres DNS par coeur.

Les valeurs d'un seul bit (booléens) sont représentés par 0 ou 1, pas par les false ou true de JSON. (J'avoue ne pas bien comprendre ce choix.)

On note également que les longueurs des sections sont indiquées explicitement, ici QDCOUNT (Query Count, et ne me demandez pas à quoi sert le D après le Q, le RFC 1035 ne l'explique pas). En JSON, cela n'est pas obligatoire (la longueur d'un tableau, en JSON, n'est pas spécifiée explicitement) mais, comme expliqué plus haut, cela a été décidé pour permettre de représenter des messages DNS anormaux, par exemple ayant un QDCOUNT de 0 et une question dans la section Question (cf. section 8 du RFC sur les conséquences que cela peut avoir pour la sécurité). De tels messages arrivent assez souvent dans le trafic DNS réel vu par les serveurs connectés à l'Internet ; attaque délibérée ou bien logiciel écrit avec les pieds ?

Et voici un exemple de réponse (QR = 1) DNS en JSON. La requête a été un succès (RCODE = 0) :

{ "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
  "QDCOUNT": 1, "ANCOUNT": 2, "NSCOUNT": 1,
   ARCOUNT": 0,
   "answerRRs": [ { "NAME": "example.com.",
                                          "TYPE": 1, "CLASS": 1,
                                          "TTL": 3600,
                                          "RDATAHEX": "C0000201" },
                  { "NAME": "example.com.",
                                          "TYPE": 1, "CLASS": 1,
                                          "TTL": 3600,
                                          "RDATAHEX": "C000AA01" } ],
   "authorityRRs": [ { "NAME": "ns.example.com.",
                                              "TYPE": 1, "CLASS": 1,
                                              "TTL": 28800,
                                              "RDATAHEX": "CB007181" } ]
    

La réponse contient un ensemble d'adresses IP (TYPE = 1 identifie une adresse IPv4), 192.0.2.1 et 192.0.170.1. Leur valeur est encodée en hexadécimal. C'est moins joli que si on avait mis l'adresse IP en clair mais c'est plus général : cela permet d'inclure immédiatement de nouveaux types de données, au détriment de la lisibilité pour les anciens types.

Le format de ce RFC permet aussi de décrire l'association entre une requête et une réponse (section 3 du RFC). On les met dans un objet JSON ayant un membre queryMessage et un responseMessage.

Si on représente une suite continue de messages DNS, faire un objet JSON avec son accolade ouvrante et la fermante correspondante peut ne pas être pratique. On utilise alors les séquences du RFC 7464, décrites dans la section 4 de notre RFC.

Notre RFC spécifie également (section 7) un type MIME pour le DNS en JSON, application/dns+json.

Notez qu'il ne s'agit pas de la première description du DNS en JSON. Par exemple, j'avais décrit un format pour cela dans le brouillon draft-bortzmeyer-dns-json. Ce format est mis en œuvre dans le DNS Looking Glass. Mon format était plus joli, car utilisant toujours des noms plus parlants ("Type": "AAAA" au lieu du "QTYPE": 28). Notez toutefois que le RFC 8427 le permet également ("QTYPEname": "AAAA"). Le format plus joli ne peut de toute façon pas être utilisé systématiquement car il ne permet pas de représenter les types inconnus. Et mon format ne permet pas non plus de représenter les messages malformés. (Par exemple, le ANCOUNT est toujours implicite.)

Un autre exemple de représentation des données DNS est donné par les sondes RIPE Atlas. Le fichier des résultats d'une mesure est en JSON (ce qui permet le traitement par les outils JSON habituels comme jq). Voici un exemple (si vous voulez un exemple complet, téléchargez par exemple le résultat de la mesure #18061873) :

       "resultset": [
      {
...
        "result": {
          "ANCOUNT": 1,
          "ARCOUNT": 0,
          "ID": 38357,
          "NSCOUNT": 0,
          "QDCOUNT": 1,
          "abuf": "ldWBgAABAAEAAAAADmN5YmVyc3RydWN0dXJlAmZyAAAcAAHADAAcAAEAAVGAABAgAUuYDcAAQQIWPv/+Jz0/",
          "rt": 103.7,
          "size": 63
        },
      },
  

On note que seule une petite partie des champs de la réponse (ANCOUNT, ID…) est exprimée en JSON, la majorité de la requête étant dans un membre abuf qui est la représentation binaire de la réponse.

Le service de DNS sur HTTPS de Google produit également du JSON (on le passe à jq pour qu'il soit plus joliment affiché) :

% curl -s https://dns.google.com/resolve\?name=laquadrature.net\&type=MX | jq .
{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
    {
      "name": "laquadrature.net.",
      "type": 15
    }
  ],
  "Answer": [
    {
      "name": "laquadrature.net.",
      "type": 15,
      "TTL": 475,
      "data": "5 pi.lqdn.fr."
    }
  ]
}
  

en utilisant un format spécifique à Google. On notera que le protocole DoH, normalisé dans le RFC 8484, n'utilise pas JSON (et le service de Google, contrairement à ce qu'on voit parfois écrit, n'utilise pas DoH) mais le format binaire du DNS, utilisant le type MIME application/dns-message. Le RFC 8484 prévoit toutefois la possibilité de se servir de JSON pour le futur (section 4.2 du RFC 8484).


Téléchargez le RFC 8427


L'article seul

Publication de mon livre « Cyberstructure »

Première rédaction de cet article le 4 décembre 2018


Je viens d'écrire un livre nommé « Cyberstructure / Internet, un espace politique » et qui parle des relations entre l'architecture technique de l'Internet et la politique, notamment les droits humains. Il est publié chez C & F Éditions. Pour les différents moyens de l'acheter, vous pouvez regarder le site web d'accompagnement.

Vous n'y trouverez pas la Nième diatribe sur les méchants GAFA, leurs impôts et leurs pratiques de surveillance. D'abord, cela a déjà été largement décrit ailleurs, et je n'avais pas grand'chose d'original à ajouter sur ce point. Mais, surtout, j'avais envie de parler d'autre chose, des parties moins visibles de l'Internet, de son infrastructure. C'est donc forcément un peu technique mais ce livre n'est normalement pas destiné aux informaticiens. Il comporte une première moitié d'explications sur le fonctionnement de l'Internet (si vous lisez les RFC, vous connaissez probablement déjà le contenu de cette première partie). Et la seconde moitié est composée d'une série d'études de cas sur des sujets politiques que je trouve pas assez traités, perdus dans les débats sur Facebook et Google.

Pourquoi avoir écrit un livre, alors que je pouvais tout mettre sur mon blog ? Un avertissement d'abord : je ne partage pas du tout le point de vue conservateur comme quoi seuls les livres et les articles du Monde sont sérieux, le reste étant du travail d'amateur internaute. (Et les plus conservateurs des conservateurs sont encore pires, considérant que le livre n'a ses propriétés magiques que s'il est imprimé sur papier. Le contenu ne compte pas, pour eux, seule la forme papier est importante.) Il y a des tas de livres ridicules et inutiles, et plein d'articles de blog (ou de fils de discussion sur les réseaux sociaux) remarquables et qui font réfléchir. Par contre je ne pense pas non plus que tout est pareil : un livre a des propriétés différentes de celles d'une série d'articles de blog (pas supérieures ou inférieures, différentes).

Il y avait donc plusieurs raisons pour faire un livre (si vous vous intéressez au contenu du livre et pas aux états d'âme de l'auteur, vous pouvez arrêter cet article ici et aller vous procurer le livre et le lire) :

  • L'argent (vous noterez que le livre n'est pas sous une licence libre, quoique elle soit assez libérale et qu'il n'y ait pas de menottes numériques pour la version EPUB chez l'éditeur). Non, je rigole : écrire un livre et le vendre rapporte certes de l'argent mais ce n'est pas rentable. L'auteur (moi, en l'occurrence) touche une avance fixe, et un pourcentage sur chaque exemplaire vendu (pourcentage qui est une minorité du prix de vente) mais cela ne compense pas le temps que cela prend. Si j'avais passé ce temps à des activités commerciales plus rentables, j'aurais gagné bien plus. (Pour mon blog, l'appel à m'envoyer des bitcoins n'a pas rapporté grand'chose.) Pour un Guillaume Musso ou un Marc Levy, qui ont des revenus conséquents, il y des milliers d'auteurs qui ne gagnent pas d'argent, en tout cas pas en proportion du temps passé et des efforts déployés. Notez au passage que cela invalide la ridicule propagande des ayant-droits « si les créateurs ne sont pas rémunérés, il n'y aura plus de création ». Il suffit de voir le nombre toujours croissant de livres publiés (malgré le méchant Internet qui soi-disant tue les artistes), dont la plupart ne seront pas des best-sellers, ni même des bonnes ventes, pour se rendre compte que la grande majorité des auteurs écrivent parce qu'ils désirent écrire, pas dans l'espoir d'un gain financier.
  • Le prestige. Eh oui, chacun ses faiblesses. C'est flatteur de se voir en librairie, même si on n'est pas invité à une émission à la télévision. C'est particulièrement vrai en France, où l'objet-livre reste relativement sacré.
  • La diffusion des idées. Un livre, diffusé par un éditeur, et ayant une distribution physique, permet de toucher des gens différents. Certes, grâce à l'Internet, tout le monde peut mettre par écrit ses pensées (ou sur une vidéo, pour toucher les gens qui ne savent pas lire) et le monde entier peut alors y accéder. C'est le gros avantage de l'Internet, et la raison pour laquelle les autorités en place veulent à tout prix le « civiliser », c'est-à-dire faire rentrer le torrent dans son lit. Mais le fait que le monde entier puisse y accéder ne signifie pas qu'ils vont le faire effectivement. Pour des raisons très variées, certaines mauvaises et d'autres bonnes, un livre reste encore, en 2018, un moyen plus efficace pour atteindre certains publics.
  • Une nouvelle expérience. Une caractéristique importante de ce livre est que c'est un travail d'équipe. Je peux écrire des articles sur mon blog (comme celui que vous êtes en train de lire) et les publier tout seul, sans rien demander à personne. Cela a des avantages (rapidité, contrôle de tous les détails, cohérence du texte) mais aussi des inconvénients. Avoir des regards extérieurs, discuter du contenu avant publication, est très bénéfique. Un travail qui soit davantage collectif est une expérience que j'avais envie de tenter.
  • La qualité. Un livre permet aussi de déléguer certaines tâches, comme la mise en page, sur lesquelles je n'ai aucune compétence. Non seulement cela donne un meilleur résultat (le livre est plus agréable à lire) mais cela force l'auteur à se concentrer sur le contenu, au lieu de passer des jours à perfectionner ses macros LaTeX.

Notez bien qu'un livre n'est pas forcément sur papier. Les réactionnaires qui déplorent la disparition du livre au profit du méchant numérique font parfois un éloge nostalgique du papier, supposé avoir des propriétés merveilleuses. En fait, les arguments que j'ai donnés plus haut en faveur du livre sont pour la plupart tout aussi vrais pour le livre numérique que pour le livre papier. La forme papier a des tas d'avantages (lecture en plein soleil, dans son bain, pas de dépendance vis-à-vis du courant électrique, probablement une meilleure conservation sur le long terme), mais un livre ce n'est pas juste une forme physique ! C'est avant tout le travail des personnes qui ont écrit, relu, corrigé, discuté, mis en page, et ce travail est ce qui fait la valeur du livre. (Pour une excellente étude sur les usages de l'objet livre, je vous recommande Le livre-échange, chez le même éditeur.)

Après ces considérations générales, comment s'est passée la réalisation de ce livre particulier ? D'abord, un conseil général aux auteurs (personne n'écoute les conseils, et à juste titre) : cela prend toujours plus de temps que prévu. Je croyais que ce serait l'affaire de deux ou trois mois, mais cela a été bien plus long :

  • Plusieurs discussions préparatoires avec l'éditeur en 2017, pour essayer de cerner un peu en quoi consistera ce livre. (Je décris ici le processus de production de mon livre : d'autres ont été faits différemment, par exemple par un auteur apportant à un éditeur un livre déjà fini.)
  • Novembre 2017, j'écris une section du livre (celle sur les « boitiers intermédiaires »), pour tester mon style et discuter avec l'éditeur. J'écris aussi un plan détaillé.
  • Décembre 2017, le format est décidé, le plan fini, l'écriture commence.
  • Les vacances de fin d'année 2017 voient une bonne partie de l'écriture être faite. Les dates des fichiers me rappellent que la section sur le chiffrement a été faite le 31 décembre et finie à 18h30, la section sur les problèmes liés à l'Internet étant commencée le 1 janvier à 12h00. Les programmeu·r·se·s ne seront pas surpris·es d'apprendre que, quand on écrit un livre, on produit parfois plein de contenu en une semaine, qu'on passe ensuite deux mois à corriger, modifier, vérifier. Le nombre de signes n'est donc pas une bonne métrique de l'avancement du travail.
  • Février 2018, le travail n'avance pas assez vite (je suis salarié et je ne peux pas écrire à temps plein). Sur le conseil d'une auteure, je prends une semaine de congés pour une « retraite » d'écriture. Après avoir envisagé d'aller dans un monastère (nombreux sont ceux qui louent des chambres aux cadres surmenés cherchant un moment de concentration tranquille), je loue un petit appartement à Chivres-Val (où il n'y a pas beaucoup de distractions, surtout en hiver, ce qui aide au travail) et une grande partie du livre est alors faite. Je recommande la méthode : une semaine seul, sans sortir, et sans interruptions, c'est fou ce que ça augmente la productivité.
  • Mars 2018, première relecture extérieure. Évidemment, la relectrice trouve plein de problèmes et suggère de nombreuses modifications. Ces relectures sont une des grandes différences avec mes articles sur ce blog. Sur ce blog, personne ne voit les articles avant parution. Parfois, il y a des remarques ensuite, que j'intègre dans certains cas, mais c'est très différent d'une relecture a priori, où il peut être nécessaire de changer des choses importantes, ce que j'ai psychologiquement du mal à faire. Écrire lorsqu'il y a des relecteurices nécessite d'abandonner son attitude défensive (« mais il est très bien, mon livre ») et d'accepter des remarques critiques. Au passage, je remercie mes relecteurices de leur honnêteté et de leur franchise (« ce passage est incompréhensible, il faut le refaire »).
  • Mai 2018, contrat avec l'éditeur signé. Les contrats d'édition sont souvent signés une fois le livre largement rédigé.
  • Juin 2018, beaucoup de relectures extérieures, et donc beaucoup de changements à faire.
  • Juillet 2018, premier envoi à l'éditeur, pour un premier avis. J'ai reçu plein de remarques au stylo rouge sur un exemplaire papier (le papier est un bon support pour les relectures et corrections, surtout l'été quand on est dehors). Vacances en août où je lis les corrections, et apporte des modifications.
  • Septembre 2018, deux relectures particulièrement pointues, qui trouvent de nombreux problèmes, et pas mal de fautes d'orthographe ou de grammaire que je pensais éradiquées depuis longtemps. Puis c'est l'envoi de la version « stable » (à ce stade, on ne peut pas encore dire « définitive ») à l'éditeur.
  • Novembre 2018, réception du projet de couverture du livre (faite par Nicolas Taffin, de C & F Éditions), et du projet de livre mis en page.
  • Même mois, après correction du projet, et réalisation de la couverture, envoi à l'imprimeur.
  • 17 novembre, première mention publique au Capitole du Libre à Toulouse.
  • Premier exemplaire imprimé reçu le 3 décembre 2018.

Le livre, à son arrivée : cyberstructure-arrivee-petit.jpg

À plusieurs reprises, je me suis dit « là, c'est bon, c'est terminé », avant qu'un·e relect·eur·rice ne me fasse des remarques précises dont la prise en compte nécessitait un sérieux travail. Bref, écrire est un marathon, pas un sprint.

Les lect·eurs·crices de mon blog verront que certaines sections du livre ont été recopiées depuis mon blog. C'est le cas par exemple de celle sur la neutralité. De même, la section sur l'internationalisation a été reprise depuis l'ouvrage collectif Net.Lang, avec l'autorisation de l'éditeur. Mais la plus grande partie du contenu est originale.

Si vous vous intéressez à la partie technique du travail (quel logiciel j'ai utilisé, etc), voyez mon autre article.

Et le contrat avec l'éditeur ? C'est un document de sept pages, évidemment à lire soigneusement. Parmi les différent articles du contrat, j'ai noté :

  • L'article 2 dit que la responsabilité juridique revient à l'auteur. Si Vincent Bolloré fait un procès car on a parlé de lui d'une manière qu'il n'approuve pas, c'est à l'auteur de se débrouiller, il ne peut pas se cacher derrière l'éditeur.
  • Les droits d'auteur comprennent un à-valoir fixe, puis un pourcentage de 8 % par exemplaire. (Cf. plus haut sur la rentabilité de l'écriture d'un livre.)
  • J'ai cédé les droits d'adaptation en bande dessinée 🤣 mais pas ceux d'adaptation au cinéma 🤣.
  • J'ai aussi cédé les droits de traduction. Je serais d'ailleurs très heureux que ce livre soit traduit. Ce n'est pas tellement utile pour l'anglais, où il y a déjà beaucoup de textes sur la politique et Internet, mais cela serait très souhaitable dans d'autres langues. Donc, si vous connaissez traducteurs et éditeurs étrangers qui seraient intéressés, n'hésitez pas à me les signaler.

Cet article est l'occasion de remercier une nouvelle fois celles et ceux qui ont contribué à ce livre, à commencer par Hervé le Crosnier, qui s'est beaucoup démené pour que ce livre naisse. Un livre n'est pas fait que par un·e auteur·e. De même que, dans la programmation, les gens qui signalent des bogues et font des rapports de bogue détaillés sont un élément indispensable du succès, de même relecteur·e·s, éditeur·e·s, maquettistes et imprimeur·e·s méritent les chaleureux remerciements que j'envoie ici.

En conclusion ? Malgré le discours à la mode comme quoi les gens n'arrivent plus à lire quoi que ce soit de plus long qu'un tweet, malgré la tendance à ne mettre comme documentation, même technique, que des vidéos, on ne peut pas dire que le livre soit menacé de disparition : il y en a toujours autant d'écrits, et les salons consacrés aux livres ne désemplissent pas. Sont-ils lus ? Je ne sais pas, mais comme dit plus haut, l'auteur de livre n'est pas rationnel : il ou elle écrit car il ou elle veut écrire.


L'article seul

RFC 8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0))

Date de publication du RFC : Octobre 2018
Auteur(s) du RFC : A. Mayrhofer (nic.at GmbH)
Expérimental
Réalisé dans le cadre du groupe de travail IETF dprive
Première rédaction de cet article le 2 décembre 2018


Chiffrer pour assurer la confidentialité, c'est bien. Pour le DNS, c'est ce que permet le RFC 7858 (DNS sur TLS). Mais un problème de TLS et de pas mal d'autres protocoles cryptographiques est qu'il ne dissimule pas les métadonnées, et notamment la taille des messages échangés sur le réseau. Dans un monde public comme celui du DNS, c'est un problème. En effet, l'attaquant peut facilement mesurer la taille des réponses chiffrées (en envoyant lui-même une requête), voir la taille des réponses, et en déduire les questions qui avaient été posées. La solution classique en cryptographie face à ce risque est le remplissage, normalisé, pour le DNS, dans le RFC 7830. Mais le RFC 7830 ne normalisait que le format, pas le mode d'emploi. Il faut remplir jusqu'à telle taille ? Comment concilier un remplissage efficace pour la confidentialité avec le désir de limiter la consommation de ressources réseaux ? Ce RFC décrit plusieurs stratégies possibles, et recommande un remplissage jusqu'à atteindre une taille qui est le multiple suivant de 468 (octets).

Ce nouveau RFC tente de répondre à ces questions, en exposant les différentes politiques possibles de remplissage, leurs avantages et leurs inconvénients. Le RFC 7830 se limitait à la syntaxe, notre nouveau RFC 8467 étudie la sémantique.

D'abord, avant de regarder les politiques possibles, voyons les choses à garder en tête (section 3 du RFC). D'abord, ne pas oublier de mettre l'option EDNS de remplissage (celle du RFC 7830) en dernier dans la liste des options (car elle a besoin de connaitre la taille du reste du message).

Ensuite, il faut être conscient des compromis à faire. Remplir va améliorer la confidentialité mais va réduire la durée de vie de la batterie des engins portables, va augmenter le débit qu'on injecte dans le réseau, voire augmenter le prix si on paie à l'octet transmis. Lors des discussions à l'IETF, certaines personnes ont d'ailleurs demandé si le gain en confidentialité en valait la peine, vu l'augmentation de taille. En tout cas, on ne remplit les messages DNS que si la communication est chiffrée : cela ne servirait à rien sur une communication en clair.

Enfin, petit truc, mais qui montre l'importance des détails quand on veut dissimuler des informations, le remplissage doit se faire sans tenir compte des deux octets qui, avec certains protocoles de transport du DNS, comme TCP, peut faire fuiter des informations. Avec certaines stratégies de remplissage, les deux octets en question peuvent faire passer de l'autre côté d'un seuil et donc laisser fuiter l'information qu'on était proche du seuil.

Ensuite, après ces préliminaires, passons aux stratégies de remplissage, le cœur de ce RFC (section 4). Commençons par celle qui est la meilleure, et recommandée officiellement par notre RFC : remplissage en blocs de taille fixe. Le client DNS remplit la requête jusqu'à atteindre un multiple de 128 octets. Le serveur DNS, si le client avait mis l'option EDNS de remplissage dans la requête, et si la communication est chiffrée, remplit la réponse de façon à ce qu'elle soit un multiple de 468 octets. Ainsi, requête et réponse ne peuvent plus faire qu'un nombre limité de longueurs, la plupart des messages DNS tenant dans le bloc le plus petit. Voici un exemple vu avec le client DNS dig, d'abord sans remplissage :

       
% dig +tcp +padding=0 -p 9053 @127.0.0.1 SOA foobar.example  
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29832
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: dda704b2a06d65b87f0493105c03ca4d2b2c83f2d4e25680 (good)
;; QUESTION SECTION:
;foobar.example.		IN SOA

;; ANSWER SECTION:
foobar.example.		600 IN SOA ns1.foobar.example. root.foobar.example. (
				2015091000 ; serial
				604800     ; refresh (1 week)
				86400      ; retry (1 day)
				2419200    ; expire (4 weeks)
				86400      ; minimum (1 day)
				)
...
;; MSG SIZE  rcvd: 116

     

La réponse fait 116 octets. On demande maintenant du remplissage, jusqu'à 468 octets :


% dig +tcp +padding=468 -p 9053 @127.0.0.1 SOA foobar.example  
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2117
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 854d2f29745a72e5fdd6891d5c03ca4b5d5287daf716e327 (good)
; PAD (348 bytes)
;; QUESTION SECTION:
;foobar.example.		IN SOA

;; ANSWER SECTION:
foobar.example.		600 IN SOA ns1.foobar.example. root.foobar.example. (
				2015091000 ; serial
				604800     ; refresh (1 week)
				86400      ; retry (1 day)
				2419200    ; expire (4 weeks)
				86400      ; minimum (1 day)
				)

;; MSG SIZE  rcvd: 468

     

La réponse fait 468 octets, grâce aux 348 octets de remplissage (notez la ligne PAD (348 bytes)).

Les avantages de cette méthode est qu'elle est facile à mettre en œuvre, assure une confidentialité plutôt bonne, et ne nécessite pas de générateur de nombres aléatoires. Son principal inconvénient est qu'elle permet de distinguer deux requêtes (ou deux réponses) si elles ont le malheur d'être remplies dans des blocs de taille différente. Mais il ne faut pas chercher une méthode idéale : rappelez-vous qu'il faudra faire des compromis. Cette méthode a un faible coût pour le défenseur, et élève les coûts sensiblement pour l'attaquant, c'est ça qui compte.

Notez que les chiffres 128 et 468 ont été obtenus empiriquement, en examinant du trafic DNS réel. Si DNSSEC continue à se répandre, les tailles des réponses moyennes augmenteront, et il faudra peut-être réviser ces chiffres.

Une autre statégie est celle du remplissage maximal. On met autant d'octets qu'on peut. Si un serveur a une taille maximale de réponse de 4 096 octets (la valeur par défaut la plus courante) et que le client accepte cette taille, on remplit la réponse jusqu'à ce qu'elle fasse 4 096 octets. L'avantage évident de cette méthode est qu'elle fournit la meilleure confidentialité : toutes les réponses ont la même taille. L'inconvénient évident est qu'elle est la méthode la plus consommatrice de ressources. En outre, ces grandes réponses vont souvent excéder la MTU, pouvant entrainer davantage de problèmes liés à la fragmentation.

Autre stratégie envisageable : remplissage aléatoire. On tire au sort le nombre d'octets à ajouter. Cela fournit une bonne distribution des tailles (par exemple, une réponse courte peut désormais être plus grande qu'une réponse longue, ce qui n'arrive jamais avec les deux stratégies précédentes). Inconvénient : comme ça ne change pas la limite de taille inférieure, un attaquant qui voit beaucoup de messages pourrait en déduire des informations. Et cela oblige à avoir un générateur de nombres aléatoires, traditionnellement un problème délicat en cryptographie.

Enfin, une dernière méthode raisonnable est de combiner le remplissage dans des blocs et le tirage au sort : on choisit au hasard une longueur de bloc et on remplit jusqu'à atteindre cette longueur. Contrairement à la précédente, elle n'a pas forcément besoin d'une source aléatoire à forte entropie. Mais c'est sans doute la technique la plus compliquée à mettre en œuvre.

La section 7 du RFC ajoute quelques points supplémentaires qui peuvent mettre en péril la confidentialité des requêtes. Par exemple, si le client DNS remplit correctement sa requête, mais que le serveur ne le fait pas, un attaquant pourra déduire la requête de la réponse (c'est d'autant plus facile, avec le DNS, que la question est répétée dans la réponse). Dans une communication de client à résolveur DNS, il faut bien choisir son résolveur.

Et le remplissage ne brouille qu'une seule des métadonnées. Il y en a d'autres comme l'heure de la question, le temps de réponse ou comme la succession des requêtes/réponses, qui restent accessibles à un éventuel attaquant. La protection contre la fuite d'informations via ces métadonnées nécessiterait d'injecter « gratuitement » du trafic de couverture (qui, lui aussi, éleverait la consommation de ressources réseau).

Et pour terminer le RFC, l'annexe A est consacrée aux mauvaises politiques de remplissage, celles qui non seulement ne sont pas recommandées mais sont activement déconseillées. (Mais on les trouve parfois dans du code réel.) Il y a l'évidente stratégie « pas de remplissage du tout ». Son principal intérêt est qu'elle fournit le point de comparaison pour toutes les autres stratégies. Avantages : triviale à implémenter, il suffit de ne rien faire, et aucune consommation de ressources supplémentaires. Inconvénient : la taille des requêtes et des réponses est exposée, et un observateur malveillant peut en déduire beaucoup de choses.

Une autre méthode inefficace pour défendre la vie privée est celle du remplissage par une longueur fixe. Elle est simple à implémenter mais ne protège rien : une simple soustraction suffit pour retrouver la vraie valeur de la longueur.

Ces différentes stratégies ont été analysées empiriquement (il n'y a pas vraiment de bon cadre pour le faire théoriquement) et le travail est décrit dans l'excellente étude de Daniel Kahn Gillmor (ACLU), « Empirical DNS Padding Policy » présentée à NDSS en 2017. Si vous aimez les chiffres et les données, c'est ce qu'il faut regarder !

Testons un peu les mises en œuvres du remplissage des messages DNS (une liste plus complète figure sur le site du projet).

Essayons avec BIND version 9.13.4. Il fournit le client de déboguage dig et son option +padding. Avec un +padding=256, le datagramme va faire 264 octets, incluant les ports source et destination d'UDP). Vu par tshark, cela donne :

       
        <Root>: type OPT
            Name: <Root>
            Type: OPT (41)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x00
            EDNS0 version: 0
            Z: 0x8000
                1... .... .... .... = DO bit: Accepts DNSSEC security RRs
                .000 0000 0000 0000 = Reserved: 0x0000
            Data length: 213
            Option: COOKIE
                Option Code: COOKIE (10)
                Option Length: 8
                Option Data: 722ffe96cd87b40a
                Client Cookie: 722ffe96cd87b40a
                Server Cookie: <MISSING>
            Option: PADDING
                Option Code: PADDING (12)
                Option Length: 197
                Option Data: 000000000000000000000000000000000000000000000000...
                Padding: 000000000000000000000000000000000000000000000000...

     

Cela, c'était la requête du client. Mais cela ne veut pas dire que le serveur va accepter de répondre avec du remplissage. D'abord, il faut qu'il soit configuré pour cela (BIND 9.13.4 ne le fait pas par défaut). Donc, côté serveur, il faut :

options {
	...
	response-padding {any;} block-size 468;
};

(any est pour accepter le remplissage pour tous les clients.) Mais cela ne suffit pas, BIND ne répond avec du remplissage que si l'adresse IP source est raisonnablement sûre (TCP ou biscuit du RFC 7873, pour éviter les attaques par amplification). C'est pour cela qu'il y a une option +tcp dans les appels de dig plus haut. On verra alors dans le résultat de dig le PAD (392 bytes) indiquant qu'il y a eu remplissage. La taille indiquée dans response-padding est une taille de bloc : BIND enverra des réponses qui seront un multiple de cette taille. Par exemple, avec response-padding {any;} block-size 128;, une courte réponse est remplie à 128 octets (notez que la taille de bloc n'est pas la même chez le serveur et chez le client) :

% dig +tcp +padding=468 -p 9053 @127.0.0.1 SOA foobar.example
...
; PAD (8 bytes)
...
;; MSG SIZE  rcvd: 128
     

Alors qu'une réponse plus longue (notez la question ANY au lieu de SOA) va faire passer dans la taille de bloc au dessus (128 octets est clairement une taille de bloc trop petite, une bonne partie des réponses DNS, même sans DNSSEC, peuvent la dépasser) :

% dig +tcp +padding=468 -p 9053 @127.0.0.1 ANY foobar.example
...
; PAD (76 bytes)
...
;; MSG SIZE  rcvd: 256
     

On voit bien ici l'effet de franchissement du seuil : une taille de bloc plus grande doit être utilisée.

BIND n'est pas forcément que serveur DNS, il peut être client, quand il est résolveur et parle aux serveurs faisant autorité. La demande de remplissage dans ce cas se fait dans la configuration par serveur distant, avec padding. (Je n'ai pas testé.)

Le résolveur Knot fait également le remplissage (option net.tls_padding) mais, contrairement à BIND, il ne le fait que lorsque le canal de communication est chiffré (ce qui est logique).

La bibliothèque pour développer des clients DNS getdns a également le remplissage. En revanche, Unbound, dans sa version 1.8.1, ne fait pas encore de remplissage. Et, comme vous avez vu dans l'exemple tshark plus haut, Wireshark sait décoder l'option de remplissage.


Téléchargez le RFC 8467


L'article seul

Journée de la Sécurité Informatique en Normandie ; sécurité(s) et liberté(s)

Première rédaction de cet article le 30 novembre 2018


Des conférences sur la sécurité informatique, il y en a trois par jour en France, parfois dans la même ville. On peut passer sa vie professionnelle à aller à de telles conférences. Mais elles sont plus ou moins intéressantes. La Journée de la Sécurité Informatique en Normandie fait partie de celles qui sont intéressantes. J'y ai présenté une réflexion en cours sur le débat « sécurité et liberté » dans le contexte de la sécurité informatique.

La JSecIN s'est tenue à Rouen le 29 novembre 2018, dans les locaux banlieusards de l'Université Rouen-Normandie (et co-organisée avec l'INSA). Le public était donc très majoritairement composé d'étudiants en informatique (dont une très faible proportion de femmes), avec quelques professionnels. Les exposés étaient tous intéressants. On a commencé avec Renaud Echard (ANSSI). Il a rappelé des bases en sécurité informatique, comme le fait qu'il faut utiliser le chiffrement systématiquement. Des bases vraiment basiques, certes, mais pas encore appliquées partout. L'orateur estime d'ailleurs que « 80 % des attaques seraient évitées avec l'application de quelques mesures simples d'hygiène numérique ». (La formation est donc un point-clé.)

On a vu bien sûr la classique (mais toujours vraie et utile) photo « le triptyque de la sécurité » : une porte blindée, avec un vérin de fermeture (la technique), un mot « cette porte doit rester fermée » (l'organisation) et une canette de Coca écrasée qui la tient ouverte (l'humain). Autre remarque pertinente : « Il vaut mieux une procédure simple qu'une procédure de 40 pages que personne ne lit. » L'orateur a également insisté sur l'importance de techniques simples : si le type qui fait la promotion d'une solution de sécurité ne peut pas vous l'expliquer simplement, c'est que le système est trop compliqué pour être auditable, et est donc peu sûr.

On a eu droit aussi à un peu de bureaucratie de la sécurité comme ce bon résumé de la différence entre OIV (Opérateur d'Importance Vitale, par exemple en Normandie, celui de l'énergie qui est au bord de la mer) et OSE (Opérateur de Service Essentiel) : « Un OSE est un OIV-light ». Et à la difficulté de l'attribution des cyberattaques : « Si vous me demandez d'où vient l'attaque, je vous dirais de me poser la question en privé. Et, là, je vous répondrais que je ne peux pas le dire. » Et une anecdote pour finir : dans les aéroports et gares français, de nombreux engins portables sont volés chaque jour. L'ANSSI recommande officiellement les autocollants sur le portable (pour rendre plus difficile les substitutions discrètes.)

Puis Solenn Brunet (CNIL) a présenté le paysage de la protection des données personnelles à l'heure du RGPD. Un exposé très riche (peut-être trop) car le sujet est complexe et nécessite de nombreuses explications. L'oratrice rappelle que le RGPD reprend l'essentiel de la loi Informatique & Libertés de 1978. Les gens qui se sont angoissés de certaines obligations du RGPD (minimisation des données, par exemple) ont donc 40 ans de retard. Principaux changements du RGPD : sanctions accrues, partage des responsabilités (donneur d'ordres et sous-traitants), recours collectifs… Depuis le RGPD, 6000 plaintes ont été déposées à la CNIL dont trois plaintes collectives, par La Quadrature, NOYB et Privacy International. Conclusion : la CNIL est là pour vous aider (pas seulement pour sanctionner), allez la voir pour conseil/accompagnement/etc.

Ensuite, les gens d'Exodus Privacy (tellement privé que leurs noms de l'état civil n'ont pas été donné) ont présenté leur travail d'analyse des applications sur Android, et notamment des innombrables pisteurs dont elles sont truffées. (Voir par exemple celle de l'Obs alors que ce journal explique régulièrement que les GAFA sont méchants.) Les développeurs ne mettent pas toujours les pisteurs délibérement. Ils utilisent des bibliothèques, et beaucoup incluent les pisteurs [disons franchement : les mouchards]. Vous utilisez le SDK Facebook, il y a un pisteur Facebook dedans. Programmeu·r·se·s : attention donc à ce que vous embarquez dans votre application.

Un excellent mais terrible exemple était celui de l'application « Baby + » (application de suivi de grossesse) qui transmettait des données personnelles à Facebook : le fœtus avait un compte Facebook avant même sa naissance. (Alors que personne n'avait utilisé Facebook sur cet ordiphone.) Pour aider l'excellent travail d'analyse d'Exodus Privacy, c'est par ici.

Puis Gaetan Ferry (Synacktiv) a parlé d'obscurcissement des programmes. Il s'agit de transformer un programme en quelque chose d'illisible (pas mal de développeurs PHP y arrivent très bien sans disposer de ces outils…) Cette technique ne sert qu'au logiciel privateur et aux attaquants qui veulent faire passer un logiciel malveillant à travers les protections du réseau (ce ne sont pas forcément des malhonnêtes, cela peut être des pentesteurs). Ce n'est donc pas forcément utile, mais c'est rigolo techniquement.

Les analyses théoriques de l'obscurcissement de programmes montrent que ça ne marche pas. Mais en pratique, ça marche suffisamment pour les buts souhaités (rendre l'analyse plus difficile, voire impossible en pratique). On obscurcit les noms en remplaçant les noms des classes/variables/fonctions. Cette perte d'informations est irrémédiable. Évidemment, ça ne suffit pas, il faut aussi brouiller la structure du code. (Mais ça peut casser le programme s'il fait de l'introspection.) On utilise par exemple la « chenxification » : remplacer tout le programme par un énorme switch. Et pour obscurcir les données, on les remplace par des résultats de fonctions (par exemple on remplace false par n > n, bon évidemment, en vrai, c'est plus compliqué). À noter que déboguer une bogue dans l'obscurcisseur est difficile puisque le programme produit est obscur…

Enfin, Pierre Blondeau (Université de Caen) a présenté un système de boot sécurisé mais automatique d'une machine Linux dont le disque est chiffré. Le cahier des charges imposait qu'on puisse démarrer la machine même en l'absence de son utilisateur (et donc sans connaitre la phrase de passe). Donc, dans initramfs, il a ajouté un client qui s'authentifie (cryptographie asymétrique) auprès d'un serveur local qui lui donne la clé de déchiffrement du disque. Un méchant qui volerait une des machines ne pourrait pas la démarrer. Le logiciel est disponible en ligne.

Mon exposé à cette conférence portait sur « La sécurité est-elle l'amie ou l'ennemie des droits humains ? ». Les supports de l'exposé sont disponibles ici en PDF, il y a aussi une version pour l'impression sur papier, et, si vous lisez le LaTeX, le source. (Pendant cet exposé, j'ai cité Zittrain donc c'est l'occasion de dire que j'avais parlé de son livre.)

Tout (sauf l'exposé du représentant de l'ANSSI) a été filmé et les vidéos devraient apparaitre dans une semaine sur la plateforme de l'Université.

Merci à Magali Bardet, Romain Hérault, et tous les autres organisateurs (et aux spectacteurs).


L'article seul

RFC 8386: Privacy Considerations for Protocols Relying on IP Broadcast or Multicast

Date de publication du RFC : Mai 2018
Auteur(s) du RFC : R. Winter (University of Applied Sciences Augsburg), M. Faath (Conntac GmbH), F. Weisshaar (University of Applied Sciences Augsburg)
Pour information
Réalisé dans le cadre du groupe de travail IETF intarea
Première rédaction de cet article le 29 novembre 2018


Plusieurs protocoles applicatifs utilisent la diffusion, par exemple pour la découverte d'un service, et envoient donc des messages qui vont toucher toutes les machines du réseau local. Cela a des conséquences pour la vie privée : un observateur, même purement passif, peut apprendre plein de choses en écoutant. Il est donc important lorsqu'on conçoit des protocoles applicatifs de veiller à ne pas être trop bavard.

La diffusion, c'est envoyer à tout le monde. Comme il n'existe pas (heureusement !) de mécanisme fiable pour envoyer à tout l'Internet, en pratique, la diffusion se limite au réseau local. Mais c'est déjà beaucoup ! Connecté dans un café ou dans un autre endroit à WiFi, les messages diffusés arrivent à un groupe inconnu : un nombre potentiellement grand de machines. (L'utilisation d'un commutateur ne protège pas, si c'est de la diffusion.) La diffusion est très importante pour certaines fonctions (auto-configuration lorsqu'on ne connait pas sa propre adresse IP, ou bien résolution locale de noms ou d'adresses). La diffusion est tellement pratique (cf. RFC 919 et RFC 3819) qu'elle est utilisée par beaucoup d'applications.

Mais la diffusion est dangereuse ; à la conférence TRAC 2016, les auteurs du RFC avaient, dans un excellent exposé, publié un premier résultat de leurs travaux sur la question (Faath, M., Weisshaar, F., et R. Winter, How Broadcast Data Reveals Your Identity and Social Graph, 7th International Workshop on TRaffic Analysis and Characterization IEEE TRAC 2016, September 2016). En une journée à écouter le trafic diffusé sur leur université, ils avaient récolté 215 Mo de données. Les protocoles les plus bavards : 1) mDNS 2) SSDP 3) LLMNR 4) NetBIOS 5) Dropbox. Le seul client Dropbox diffuse à la cantonade l'ID du client, et celui des shares où il se connecte. Il est facile de faire un graphe des utilisateurs en mettant ensemble ceux qui se connectent au même share. Les mêmes auteurs avaient mené une expérience à grande échelle en écoutant le trafic diffusé lors de la réunion IETF 93 à Prague, et cela avait suscité bien des débats, notamment juridico-légaux (a-t-on le droit d'écouter du trafic qui est diffusé à tous ?) Comme en médecine, la science ne justifie pas tout et il est nécessaire de se pencher sur les conséquences de ses expériences.

Bien sûr, du moment qu'on envoie des données sur un réseau, elles peuvent être écoutées par des indiscrets. Mais la diffusion aggrave le problème de deux façons :

  • Un éventuel indiscret n'a même pas besoin de techniques particulières pour écouter, il lui suffit d'ouvrir ses oreilles,
  • La solution évidente à l'écoute, le chiffrement, marche mal avec la diffusion : il n'est pas facile de chiffrer lorsqu'on ne connait pas les destinataires.

Il est donc justifié de se préoccuper de près des conséquences de la diffusion sur la confidentialité (RFC 6973).

Pour certains protocoles conçus à l'IETF, il y a déjà eu des réflexions sur les problèmes de vie privée liés à leur usage de la diffusion. C'est évidemment le cas pour DHCP, dont les RFC 7819 et RFC 7824 ont pointé la grande indiscrétion. C'est aussi le cas des mécanismes de génération des adresses IPv6, expliqué dans le RFC 7721. Mais il y a également beaucoup de protocoles non-IETF qui utilisent imprudemment la diffusion, comme celui de Dropbox, présenté à la conférence TRAC. Ces protocoles privés sont en général peu étudiés, et la préservation de la vie privée est située très bas sur l'échelle des préoccupations de leurs auteurs. Et ils sont souvent non documentés, ce qui rend difficile toute analyse.

La section 1.1 de notre RFC résume les différents types de diffusion qui existent dans le monde IP. IPv4 a la diffusion générale (on écrit à 255.255.255.255, cf. section 5.3.5.1 du RFC 1812) et la diffusion dirigée (on écrit à une adresse qui est celle du préfixe du réseau local, avec tous les bits « machine » à 1, cf. section 5.3.5.2 du même RFC). IPv6, officiellement, n'a pas de diffusion mais uniquement du multicast mais c'est jouer avec les mots : il a les mêmes possibilités qu'IPv4 et les mêmes problèmes de confidentialité. Si une machine IPv6 écrit à ff02::1, cela donnera le même résultat que si une machine IPv4 écrit à 255.255.255.255. Parmi les protocoles IETF qui utilisent ces adresses de diffusion, on trouve mDNS (RFC 6762), LLMNR (RFC 4795), DHCP pour IPv4 (RFC 2131), DHCP pour IPv6 (RFC 8415), etc.

La section 2 détaille les problèmes de vie privée que l'envoi de messages en diffusion peut entrainer. D'abord, le seul envoi des messages, même sans analyser ceux-ci, permet de surveiller les activités d'un utilisateur : quand est-ce qu'il est éveillé, par exemple. Plus les messages sont fréquents, meilleure sera la résolution temporelle de la surveillance. Notre RFC conseille donc de ne pas envoyer trop souvent des messages périodiques.

Mais un problème bien plus sérieux est celui des identificateurs stables. Bien des protocoles incluent un tel identificateur dans leurs messages, par exemple un UUID. Même si la machine change de temps en temps d'adresse IP et d'adresse MAC (par exemple avec macchanger), ces identificateurs stables permettront de la suivre à la trace. Et si l'identificateur stable est lié à la machine et pas à une de ses interfaces réseau, même un changement de WiFi à Ethernet ne suffira pas à échapper à la surveillance. C'était le cas par exemple du protocole de Dropbox qui incluait dans les messages diffusés un identificateur unique, choisi à l'installation et jamais changé ensuite. D'une manière générale, les identificateurs stables sont mauvais pour la vie privée, et devraient être utilisés avec prudence, surtout quand ils sont diffusés.

Ces identificateurs stables ne sont pas forcément reliés à l'identité étatique de la personne. Si on ne connait pas la sécurité, et qu'on ne sait pas la différence entre anonymat et pseudonymat, on peut penser que diffuser partout qu'on est 88cb0252-3c97-4bb6-9f74-c4c570809432 n'est pas très révélateur. Mais outre que d'avoir un lien entre différentes activités est déjà un danger, certains protocoles font qu'en plus ce pseudonyme peut être corrélé avec des informations du monde extérieur. Par exemple, les iPhone diffusent fièrement à tout le réseau local « je suis l'iPhone de Jean-Louis » (cf. RFC 8117). Beaucoup d'utilisateurs donnent à leur machine leur nom officiel, ou leur prénom, ou une autre caractéristique personnelle. (C'est parfois fait automatiquement à l'installation, où un programme demande « comment vous appelez-vous ? » et nomme ensuite la machine avec ce nom. L'utilisateur n'est alors pas conscient d'avoir baptisé sa machine.) Et des protocoles diffusent cette information.

En outre, cette information est parfois accompagnés de détails sur le type de la machine, le système d'exploitation utilisé. Ces informations peuvent permettre de monter des attaques ciblées, par exemple si on connait une vulnérabilité visant tel système d'exploitation, on peut sélectionner facilement toutes les machines du réseau local ayant ce système. Bref, le RFC conseille de ne pas diffuser aveuglément des données souvent personnelles.

Comme souvent, il faut aussi se méfier de la corrélation. Si une machine diffuse des messages avec un identificateur stable mais non parlant (qui peut donc être ce 700a2a3e-4cda-46df-ad6e-2f062840d1e3 ?), un seul message donnant une autre information (par exemple nom et prénom) est suffisant pour faire la corrélation et savoir désormais à qui se réfère cet identificateur stable (700a2a3e-4cda-46df-ad6e-2f062840d1e3, c'est Jean-Louis). Lors de l'expérience à Prague citée plus haut, il avait été ainsi possible aux chercheurs de récolter beaucoup d'informations personnelles, et même d'en déduire une partie du graphe social (la machine de Jean-Louis demande souvent en mDNS celle de Marie-Laure, il doit y avoir un lien entre eux).

La plupart des systèmes d'exploitation n'offrent pas la possibilité de faire la différence entre un réseau supposé sûr, où les machines peuvent diffuser sans crainte car diverses mesures de sécurité font que tout le monde n'a pas accès à ce réseau, et un réseau public complètement ouvert, genre le WiFi du McDo, où tout est possible. Il serait intéressant, affirme le RFC, de généraliser ce genre de service et d'être moins bavard sur les réseaux qui n'ont pas été marqués comme sûrs.

La section 3 du RFC note que certains points d'accès WiFi permettent de ne pas passer systématiquement la diffusion d'une machine à l'autre, et de ne le faire que pour des protocoles connus et supposés indispensables. Ainsi, les requêtes DHCP, terriblement indiscrètes, pourraient ne pas être transmises à tous, puisque seul le point d'accès en a besoin. Évidemment, cela ne marche que pour des protocoles connus du point d'accès, et cela pourrait donc casser des protocoles nouveaux (si on bloque par défaut) ou laisser l'utilisateur vulnérable (si, par défaut, on laisse passer).

En résumé (section 4 du RFC), les conseils suivants sont donnés aux concepteurs de protocoles et d'applications :

  • Autant que possible, utiliser des protocoles normalisés, pour lesquelles une analyse de sécurité a été faite, et des mécanismes de limitation des risques développées (comme ceux du RFC 7844 pour DHCP),
  • Essayer de ne pas mettre des informations venant de l'utilisateur (comme son prénom et son nom) dans les messages diffusés,
  • Tâcher de ne pas utiliser d'identificateurs stables, puisqu'ils permettent de surveiller une machine pendant de longues périodes,
  • Ne pas envoyer les messages trop souvent.

Téléchargez le RFC 8386


L'article seul

Passage de ce blog à Let's Encrypt

Première rédaction de cet article le 25 novembre 2018


Bon, comme la Terre entière, je suis passé à Let's Encrypt. Ce blog est désormais systématiquement en HTTPS pour tout le monde.

Il y a plus de quatre ans que ce blog est accessible en HTTPS, à la fois pour assurer la confidentialité (pas des réponses, puisque le contenu est public, mais des requêtes) et protéger contre toute modification en route. J'utilisais une autorité de certification gratuite, contrôlée par ses utilisateurs, et très simple à utiliser, CAcert. J'en suis satisfait mais CAcert n'est pas intégré dans le magasin de certificats de la plupart des systèmes d'exploitation et/ou navigateurs Web. (Alors que des AC gouvernementales ayant déjà émis des faux certificats y sont, mais c'est une autre histoire.)

Cette non-présence dans les magasins d'AC obligeait les utilisateurs à ajouter CAcert manuellement, ce qu'évidemment peu faisaient. Résultat, je ne pouvais pas publier un URL en https:// sans recevoir des messages « c'est mal configuré », et je ne pouvais pas utiliser de bonnes pratiques comme de rediriger automatiquement les visiteurs vers la version sûre. D'où ce passage de CAcert à Let's Encrypt. La sécurité n'y gagne rien, mais ce sera plus pratique pour les utilisateurs. Notez que cela a des conséquences stratégiques pour l'Internet : la quasi-totalité des sites Web non-commerciaux (et beaucoup de commerciaux) utilisent la même AC, dont tout le monde est désormais dépendant.

Bon, il y a quand même un petit progrès technique, CAcert ne permettait pas de signer les certificats utilisant la cryptographie à courbes elliptiques (RFC 8422), alors que Let's Encrypt le permet. Voici ce certificat ECDSA avec la courbe elliptique P256, vu par le journal crt.sh (cf. RFC 6962), ou bien vu par GnuTLS :

% gnutls-cli www.bortzmeyer.org
- Certificate type: X.509
- Certificate[0] info:
 - subject `CN=www.bortzmeyer.org', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x03ae1eb1664c8652d50d7213900d5c935dbe, EC/ECDSA key 256 bits, signed using RSA-SHA256, activated `2018-11-13 19:29:41 UTC', expires `2019-02-11 19:29:41 UTC', key-ID `sha256:74d7df20684d3854233db36258d327dfce956720b836fd1f2c17f7e67ae84db9'
	Public Key ID:
		sha1:45600c1f3141cf85db95f5dac74ec1066bafb5b9
		sha256:74d7df20684d3854233db36258d327dfce956720b836fd1f2c17f7e67ae84db9
	Public key's random art:
		+--[SECP256R1]----+
		|      .+O+.... o.|
		|       o.*..  * .|
		|        . +o + +.|
		|         .. o o+.|
		|        S     .o=|
		|              oo+|
		|             . o.|
		|                .|
		|               E |
		+-----------------+

- Certificate[1] info:
 - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a0141420000015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', key-ID `sha256:60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18'
- Status: The certificate is trusted. 
    

Le certificat a été généré par :

% openssl ecparam -out blog.pem -name prime256v1 -genkey
% openssl req -new -key blog.pem  -nodes -days 1000 -subj '/CN=www.bortzmeyer.org' -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:www.bortzmeyer.org")) -out blog.csr
    

La solution simple pour la deuxième commande (openssl req -new -key blog.pem -nodes -days 1000 -out blog.csr) n'était pas bonne car elle ne met pas de SAN (Subject Alternative Name) dans le CSR, ce qui perturbe le client Let's Encrypt dehydrated.

La plupart des utilisateurs de Let's Encryt ne s'embêtent pas avec ces commandes OpenSSL. Ils utilisent un client Let's Encrypt comme certbot qui fait ce qu'il faut pour générer la CSR et la faire signer par l'AC Let's Encrypt. Je ne l'ai pas fait car je voulais contrôler exactement le certificat. J'ai choisi le client Let's Encrypt dehydrated. Après avoir vérifié la CSR :

% openssl req -text -in blog.csr                        
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: CN = www.bortzmeyer.org
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:34:ce:8a:50:e4:d0:bb:61:12:e6:39:98:cd:24:
                    13:59:47:83:bb:1c:5a:ae:96:be:49:d1:0f:cf:e0:
                    0b:96:b7:e6:fe:51:2c:ee:0f:bf:48:d4:73:5e:e5:
                    e5:79:0d:8e:f7:9b:5d:8d:d3:91:dd:fd:23:96:1f:
                    da:c2:46:03:b0
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: 
                DNS:www.bortzmeyer.org
...
    

J'ai fait signer mon certificat ainsi :

% dehydrated --signcsr ./blog.csr > blog.crt
    

Une des raisons pour lequelles je voulais contrôler de près le certificat était que je veux publier la clé publique dans le DNS (technique DANE, RFC 6698), DANE étant une meilleure technique de sécurisation des certificats. J'ai donc un enregistrement TLSA :

      
% dig TLSA _443._tcp.www.bortzmeyer.org
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62999
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 17
...
;; ANSWER SECTION:
_443._tcp.www.bortzmeyer.org. 86400 IN TLSA 1 1 1 (
				74D7DF20684D3854233DB36258D327DFCE956720B836
				FD1F2C17F7E67AE84DB9 )
_443._tcp.www.bortzmeyer.org. 86400 IN RRSIG TLSA 8 5 86400 (
				20181206024616 20181121161507 50583 bortzmeyer.org.
				w04TM3ZKesaNrFrJMs9w4B8/V+vHDnaUxfO2lWlQTHZH
...

    

Et évidemment je l'ai testé avant de publier cet article :

% tlsa --verify www.bortzmeyer.org 
SUCCESS (Usage 1 [PKIX-EE]): Certificate offered by the server matches the one mentioned in the TLSA record and chains to a valid CA certificate (204.62.14.153)
SUCCESS (Usage 1 [PKIX-EE]): Certificate offered by the server matches the one mentioned in the TLSA record and chains to a valid CA certificate (2001:4b98:dc0:41:216:3eff:fe27:3d3f)
SUCCESS (Usage 1 [PKIX-EE]): Certificate offered by the server matches the one mentioned in the TLSA record and chains to a valid CA certificate (2605:4500:2:245b::42)
    

(On peut aussi tester en ligne.) L'usage de DANE nécessite de ne pas changer la clé publique à chaque renouvellement du certificat (ce que fait dehydrated par défaut). J'ai donc mis dans /etc/dehydrated/config :

PRIVATE_KEY_RENEW="no"
    

Let's Encrypt impose une durée de validité de trois mois pour le certificat. C'est court. Cela veut dire que le renouvellement doit être automatique. Par exemple, on met typiquement dans la configuration de cron un :

dehydrated --cron --hook /etc/dehydrated/hook.sh
    

Et tous les jours (dans mon cas), dehydrated va tourner, regarder les certificats dont l'expiration est dans moins de N jours (cf. paramètre RENEW_DAYS dans la configuration de dehydrated), les renouveller auprès de l'AC et exécuter les commandes situées dans /etc/dehydrated/hook.sh. De nombreux sites Web utilisant Let's Encrypt ont eu la mauvaise surprise de découvrir au bout de trois mois que leur certificat était expiré parce que le renouvellement n'avait pas marché (cron pas configuré, ou bien mal configuré). Le problème est d'autant plus fréquent que le discours « marketing » disant « Let's Encrypt, c'est super, tout est automatique » affaiblissait la vigilance des administrateurs système. Il est donc crucial, en plus de bien configurer son cron, de superviser l'expiration de ces certificats. Par exemple, ma configuration Icinga contient, entre autres :

vars.http_vhosts["blog-cert"] = {
    http_uri = "/"
    http_vhost = "www.bortzmeyer.org"
    http_ssl = true
    http_ssl_force_tlsv1_1_or_higher = true
    http_sni = true
    http_certificate = "7,4"	
}
    

Avec cette règle, Icinga envoie un avertissement s'il reste moins de sept jours, et une alarme critique s'il reste moins de quatre jours de vie au certificat. De même, on doit superviser DANE.

Comme certains visiteurs du site Web essaient d'abord en HTTP (sans TLS), et comme les anciens liens en http:// ne vont pas disparaitre du jour au lendemain, j'ai également mis en place une redirection, utilisant le code de retour HTTP 301 (RFC 7231, section 6.4.2). Dans la configuration d'Apache, cela donne :

      
<VirtualHost *:80>
	ServerName www.bortzmeyer.org
        Redirect permanent / https://www.bortzmeyer.org/
</VirtualHost>

    

La redirection elle-même n'est pas sécurisée puisqu'on se connecte d'abord au serveur sans la protection qu'offre TLS. IL est donc prudent d'utiliser également HSTS (RFC 6797), pour dire « utilisez HTTPS systématiquement, dès le début ; je m'engage à ce qu'il reste actif ». Dans Apache, cela se fait avec :

Header set Strict-Transport-Security "max-age=7776000; includeSubDomains"
    

Comme tout le monde, j'ai testé la configuration TLS avec SSLlabs, CryptCheck et Internet.nl. Un peu de gamification : SSLlabs me donne un A. CryptCheck me donne également un A (et me fait remarquer j'autorise le vieux TLS 1.0). SSLlabs, comme Internet.nl, me reprochent la durée trop courte de HSTS (c'est encore un peu expérimental).

À noter que j'ai conservé CAcert pour les serveurs SMTP (pour lesquels on ne peut pas valider facilement avec Let's Encrypt, et, de toute façon, les serveurs SMTP ont en général des certificats tellement problématiques que DANE - RFC 7672 - est la seule façon de les sécuriser). Même chose pour des sites internes, non accessibles depuis l'Internet et donc non vérifiables par l'AC Let's Encrypt.

Le remplacement automatique du certificat posait un autre problème : ce blog, www.bortzmeyer.org est sur deux serveurs (trois adresses IP en tout). Il fallait donc recopier le nouveau certificat sur tous les serveurs. (Mais pas la clé privée qui, elle, est stable.) D'abord, j'ai choisi quel serveur ferait tourner dehydrated et donc recevrait le nouveau certificat. Ensuite, Let's Encrypt vérifie l'identité du serveur par un système de défi : lorsqu'il est sollicité (via le protocole ACME), Let's Encrypt génère un texte imprévisible qu'il envoie au client. Celui-ci doit alors le déposer à un endroit où Let's Encrypt pourra le récupérer. Donc, si une machine demande à l'AC Let's Encrypt un certificat pour www.bortzmeyer.org, Let's Encrypt va chercher si le texte est bien sur https://www.bortzmeyer.org/.well-known/acme-challenge. Le client prouve ainsi qu'il est légitime, qu'il peut recevoir les requêtes HTTP envoyées au nom. Le problème est que Let's Encrypt risque de se connecter sur un autre serveur que celui où le texte imprévisible a été déposé.

Pour éviter cela, j'ai configuré les autres serveurs pour relayer les requêtes HTTP allant vers .well-known/acme-challenge en direction du serveur qui fait tourner dehydrated. Avec Apache, cela se fait avec le module mod_proxy :

    
ProxyRequests Off
ProxyPass /.well-known/acme-challenge/ https://ACME-MACHINE.bortzmeyer.org/.well-known/acme-challenge/
ProxyPreserveHost On

Cela permet à la machine qui lance dehydrated de toujours recevoir les requêtes de vérification, et donc de récupérer le certificat.

(Notez que la vérification par Let's Encrypt de l'identité du demandeur ne se fait pas forcément en HTTP. On peut aussi utiliser le DNS, ce qui serait une piste intéressante à explorer. Il y a aussi une méthode basée sur ALPN.)

Il reste ensuite à recopier le certificat nouvellement acquis sur tous les serveurs. J'ai utilisé SSH pour cela, avec du scp vers un compte sans mot de passe. Sur les serveurs Web, on crée le compte, et les répertoires où on copiera le certificat :

% sudo adduser copykey
% sudo -u copykey mkdir ~copykey/keys
% sudo -u copykey chmod 700 ~copykey/keys
  

Sur la machine ACME (celle où il y a dehydrated), on crée une clé SSH sans mot de passe (puisque tout doit pouvoir tourner depuis cron, pas d'interactivité) :

% ssh-keygen -t ed25519 -P ""
  

Et sur le serveur Web, on autorise les connexions depuis le détenteur de cette clé (root, a priori), mais seulement avec la commande scp vers le bon répertoire. On met dans ~copykey/.ssh/authorized_keys :

command="/usr/bin/scp -t keys",restrict ssh-ed25519 AAAAC3Nza... root@acme-machine
  

(Notez, et c'est amusant, que l'option -t indiquant le répertoire n'est apparemment pas documentée.)

Il reste alors, dans le fichier /etc/dehydrated/hook.sh, où se trouvent les commandes à exécuter lorsque le certificat est renouvellé, à effectuer la copie vers les serveurs Web :

  
function deploy_cert {
...
   for server in ${WEBSERVERS}; do
      scp /var/lib/dehydrated/certs/www.bortzmeyer.org/* ${REMOTEACCOUNT}@${server}:keys
   done
}

Enfin, dernière étape, les fichiers (notamment le certificat) ont été copiés sur le serveur Web mais il reste à les mettre là où le serveur les attend et à dire au serveur HTTP d'en tenir compte. On aurait pu copier les fichiers directement dans le répertoire final mais il aurait fallu être root pour cela et je n'avais pas envie de mettre PermitRootLogin yes dans le sshd_config, pour des raisons de sécurité. On copie donc vers un compte ordinaire (le copykey vu plus haut) et root sur le serveur Web a une tâche lancée par cron qui récupère les fichiers et relance le serveur HTTP :


% cat /etc/cron.d/copykeys
# Look for and copy TLS keys every 5 minutes
03,08,13,18,23,28,33,38,43,48,53,58 *     * * *     root   /usr/local/sbin/copy-keys.sh

% cat /usr/local/sbin/copy-keys.sh
#!/bin/sh

OLDFILE=/etc/ssl/certs/www.bortzmeyer.org.fullchain.pem
NEWFILE=/home/copykey/keys/fullchain.pem

PATH=/sbin:/usr/sbin:${PATH}

OLDHASH=$(sha256sum ${OLDFILE} | cut -d' ' -f1)
if [ -z "${OLDHASH}" ]; then
    echo "Cannot find ${OLDFILE}" >&2
    exit 1
fi
NEWHASH=$(sha256sum ${NEWFILE} 2> /dev/null | cut -d' ' -f1 )
if [ ! -z "${NEWHASH}" ] && [ "${OLDHASH}" != "${NEWHASH}" ]; then
    cp -v ${NEWFILE} ${OLDFILE}
    apache2ctl graceful
fi


L'article seul

RFC 8404: Effects of Pervasive Encryption on Operators

Date de publication du RFC : Juillet 2018
Auteur(s) du RFC : K. Moriarty (Dell EMC), A. Morton (AT&T Labs)
Pour information
Première rédaction de cet article le 23 novembre 2018


La vie privée sur l'Internet fait aujourd'hui l'objet d'innombrables attaques et l'une des techniques de défense les plus efficaces contre ces attaques est le chiffrement des données. Il protège également contre une autre menace, la modification des données en transit, comme le font certaines FAI (par exemple Orange Tunisie). Il y a de nombreuses campagnes de sensibilisation pour promouvoir le chiffrement (voir par exemple le RFC 7258), avec des bons résultats. Évidemment, ce chiffrement gène ceux qui voudraient espionner et modifier le trafic, et il fallait donc s'attendre à voir une réaction. Ce RFC est l'expression de cette réaction, du côté de certains opérateurs réseau, qui regrettent que le chiffrement empêche leurs mauvaises pratiques.

Dès le début, ce RFC était basé sur une hypocrisie : prétendre être purement descriptif (une liste de pratiques que certains opérateurs réseau utilisent, et qui sont impactées par le chiffrement), sans forcément en conclure que le chiffrement était mauvais. Mais, en réalité, le RFC porte un message souvent répété : le chiffrement gène, et il ne faudrait pas en abuser. On note par exemple que le RFC ne s'indigne pas de certaines des pratiques citées, alors que beaucoup sont scandaleuses. Le discours est « il faut trouver un équilibre entre la protection de la vie privée et la capacité des opérateurs à gérer leurs réseaux ». Une telle référence à l'équilibre m'a toujours énervé : non, il ne faut pas d'équilibre entre le bien et le mal, il faut faire ce qu'on peut pour gêner la surveillance. Certaines des pratiques citées dans le RFC sont mauvaises et tant mieux si le chiffrement les rend difficiles. Certaines autres sont plus neutres, mais devront quand même s'adapter, les révélations de Snowden ont largement montré que la surveillance de masse est un fait, et qu'elle justifie des mesures radicales de protection. (Notez que les premières versions de ce RFC étaient bien pires, et qu'il a été affadi par les discussions successives, et suite à l'opposition rencontrée.)

Hypocritement, les textes sacrés comme le RFC 1958, RFC 1984, RFC 2804, et bien sûr les RFC 7258 et RFC 7624 sont cités, hommage du vice à la vertu. Mais tout en le faisant, ce nouveau RFC 8404 déforme ces textes. Quand le RFC 7258 dit qu'évidemment, il faut que les opérateurs puissent continuer à gérer leurs réseaux, ce RFC 8404 lui fait dire qu'il faut donc limiter le chiffrement, comme si « gérer un réseau » voulait forcément dire « accéder aux communications ». De même, on trouve une référence au principe de bout en bout (RFC 2775, RFC 3724, RFC 7754), alors même que le reste de ce RFC ne fait que citer des pratiques violant ce principe.

Ce RFC 8404 se veut, on l'a dit, une description de pratiques actuelles, et prétend hypocritement « ne pas forcément soutenir toutes les pratiques présentées ici ». En effet, tous les exemples cités par la suite sont réellement utilisées mais pas forcément par tous les opérateurs. C'est une des choses les plus désagréables de ce RFC que de laisser entendre que tous les opérateurs seraient unanimes dans leur désir de lire les communications de leurs clients, voire de les modifier. (Par exemple en utilisant le terme tribal de community pour parler des opérateurs réseau, comme s'ils étaient un clan unique, d'accord sur l'essentiel.)

Il est exact qu'au début de l'Internet, rien ou presque n'était chiffré. Tout circulait en clair, en partie parce que la perte de performances semblait excessive, en partie parce que les États faisaient tout pour décourager le chiffrement et limiter son usage, en partie parce que la menace semblait lointaine (même les plus paranoïaques des experts en sécurité ne se doutaient pas que la surveillance atteignait les proportions révélées par Snowden.) Certains opérateurs ont alors pris de mauvaises habitudes, en examinant en détail les communications, à des fins plus ou moins innocentes. Les choses changent aujourd'hui, avec un déploiement plus important du chiffrement, et ces mauvaises pratiques doivent donc disparaitre, ce que les auteurs du RFC ont du mal à avaler.

Des premiers exemples de ces mauvaises pratiques sont données en section 1.2. Par exemple, le RFC cite un rapport de l'EFF montrant que certains opérateurs inséraient des données dans les flux SMTP, notamment à des fins de suivi des utilisateurs, et, pour empêcher ces flux d'être protégés par TLS, retiraient la commande STARTTLS de la négociation (ce qu'on nomme le SSL stripping, cf. RFC 7525, section 3.2). Le RFC ose même dire que pour certains, c'était « considéré comme une attaque » comme si cela n'était pas évident que c'est une attaque ! Notant que le chiffrement systématique empêcherait cette attaque, le RFC demande qu'on fournisse à ces opérateurs réseau malhonnêtes une alternative à leurs pratiques de piratage des sessions !

Un autre exemple donné est celui des réseaux d'entreprise où il y a, dit le RFC, un « accord » pour que le contenu du trafic des employés soit surveillé par le patron (dans la réalité, il n'y a pas d'accord, cette surveillance est une condition de l'embauche). Ce serait donc un cas radicalement différent de celui des réseaux publics, via le FAI, où il n'y a pas de tel « accord » et, pourtant, déplore le RFC, le chiffrement rend cette surveillance plus difficile. (Ce point particulier a fait l'objet de nombreux débats lors de la mise au point de la version 1.3 du protocole TLS, qui visait en effet à rendre la surveillance plus difficile. Cf. RFC 8446.)

À partir de la section 2, commence le gros du RFC, les études de cas. Le RFC est très détaillé et je ne vais pas tout mentionner ici. Notons que la section 2 commence par du chantage : si on ne donne pas accès aux opérateurs au contenu des communications, ils « vont déployer des méthodes regrettables du point de vue de la sécurité », et il faut donc leur donner les données, pour éviter qu'ils n'utilisent des moyens encore pires.

D'abord, ce sont les chercheurs qui effectuent des mesures sur l'Internet (par exemple CAIDA) qui sont mentionnés pour expliquer que le chiffrement va rendre ces études bien plus difficiles. (Au passage, puisque le RFC ne le dit pas, signalons que la science ne justifie pas tout et que ces études doivent se conformer à l'éthique, comme tout le monde.) Le RFC oublie de dire que beaucoup de ces études n'utilisent que l'en-tête IP, et parfois les en-têtes TCP et UDP, qui ne sont pas affectés par le chiffrement. Comme cette réthorique est souvent présente dans ce RFC, cela vaut la peine de préciser : les techniques de chiffrement les plus déployées aujourd'hui (TLS et, loin derrière, SSH) laissent intacts les en-têtes IP et TCP, que les chercheurs peuvent donc regarder comme avant. IPsec, lui, masque l'en-tête TCP (et, dans certains cas, une partie de l'information venue de l'en-tête IP), mais il est très peu utilisé dans l'Internet public (à part une partie de l'accès au VPN de l'entreprise). QUIC, s'il sera un jour déployé massivement, dissimulera également une partie de l'information de couche 4. Bref, aujourd'hui, la partie en clair du trafic donne déjà plein d'information.

Après les chercheurs, le RFC cite les opérateurs qui regardent en détail un flux réseau pour déboguer des problèmes applicatifs. Là encore, l'exemple est très malhonnête :

  • Comme indiqué ci-dessus, la partie non chiffrée du paquet reste accessible. Si on veut déboguer des problèmes TCP subtils, du genre la fenêtre qui ne s'ouvre pas assez, même si TLS est utilisé, l'information TCP complète reste disponible, avec la taille de la fenêtre, les numéros de séquence et tout le toutim.
  • Mais, surtout, quel opérateur réseau débogue ainsi les problèmes applicatifs de ces clients ? Vous croyez vraiment que M. Michu, client d'un FAI grand public, va pouvoir solliciter l'aide d'un expert qui va lancer Wireshark pour résoudre les problèmes WebRTC de M. Michu ? (C'est l'exemple donné par le RFC : « ma vidéo haute définition est hachée ». S'il existe un FAI dont le support accepte de traiter ce genre de problèmes, je veux bien son nom.)
  • Dans des discussions privées, on m'a parfois dit qu'il ne s'agissait pas de FAI grand public, qui ne passeront en effet jamais du temps sur ces problèmes, mais d'opérateurs ayant une clientèle de grandes entreprises, pour lesquelles ils jouent un rôle de conseil et d'assistance sur les problèmes réseaux. Mais, si le client est volontaire, et veut vraiment qu'on l'aide, rien ne l'empêche de couper le chiffrement ou de demander aux applications d'afficher de l'information de déboguage détaillée.

Le RFC ne mentionne pas assez que le développement du chiffrement est en bonne partie le résultat des pratiques déplorables de certains opérateurs. Si on fait tout passer sur le port 443 (celui de HTTPS), et en chiffré, c'est précisément parce que des opérateurs se permettaient, en violation du principe de neutralité, de traiter différemment les applications, se fiant au port TCP utilisé pour reconnaitre les différentes applications. Refusant de comprendre ce problème, le RFC déplore au contraire que « tout le monde étant sur le port 443, on ne peut plus détecter certains applications afin de les prioriser », et affirme que cela justifie le DPI. Pas un seul questionnement sur la légitimité de ce traitement différencié. (Notez également un truc réthorique très malhonnête : parler de prioriser certaines applications. Comme la capacité du réseau est finie, si on en priorise certaines applications, on en ralentit forcément d'autres. Mais c'est plus vendeur de dire qu'on priorise que d'admettre qu'on discrimine.) Pour éviter de dire ouvertement qu'on viole la neutralité du réseau, le RFC la redéfinit en disant qu'il n'y a pas violation de la neutralité si on différencie entre applications, seulement si on différencie entre utilisateurs.

Il n'y a évidemment pas que les opérateurs réseau qui sont responsables de la surveillance et de l'interférence avec les communications. La section 2.4 du RFC rappelle à juste titre que les opérateurs travaillent dans un certain cadre légal et que l'État les oblige souvent à espionner (ce qui s'appelle en novlangue « interception légale ») et à censurer. Par exemple, en France, les opérateurs sont censés empêcher l'accès aux sites Web présents sur la liste noire (secrète) du ministère de l'intérieur. Le chiffrement rend évidemment plus difficile ces activités (c'est bien son but !) Le RFC note par exemple que le filtrage par DNS menteur, la technique de censure la plus commune en Europe, est plus difficile si on utilise le chiffrement du RFC 7858 pour parler à un résolveur DNS externe, et traite cela comme si c'était un problème, alors que c'est au contraire le résultat attendu (s'il n'y avait pas de surveillance, et pas d'interférence avec le trafic réseau, le chiffrement serait inutile).

Mais le RFC mélange tout par la suite, en citant comme exemple de filtrage légitime le contrôle parental. Il n'y a nul besoin qu'il soit fait par le FAI, puisqu'il est souhaité par le client, il peut être fait sur les machines terminales, ou dans le routeur de la maison. C'est par exemple ce qui est fait par les bloqueurs de publicité, qui ne sont pas une violation de la neutralité du réseau puisqu'ils ne sont pas dans le réseau, mais sur la machine de l'utilisateur, contrôlée par elle ou lui.

Un autre exemple où le RFC déplore que le chiffrement empêche une pratique considérée par l'opérateur comme utile est celui du zero rating, cette pratique où l'accès à certains services fait l'objet d'une tarification réduite ou nulle. Le chiffrement, note le RFC, peut servir à dissimuler les services auxquels on accède. Là encore, on peut se demander si c'est vraiment un problème : le zero rating est également une violation de la neutralité du réseau, et ce n'est pas forcément mauvais qu'il devienne plus difficile à déployer.

Mais l'exemple suivant est bien pire, et beaucoup plus net. La section 2.3.4 du RFC décrit la pratique de modification des flux HTTP, notamment l'insertion d'en-têtes. Plusieurs vendeurs de matériel fournissent des équipements permettant d'« enrichir » les en-têtes, en ajoutant des informations personnelles, comme le numéro de téléphone, permettant un meilleur ciblage par les publicitaires. Et ils n'en ont même pas honte, annonçant cyniquement cette capacité dans leurs brochures. Et le RFC décrit cette pratique en termes neutres, sans préciser qu'elle est mauvaise, devrait être interdite, et que le chiffrement permet heureusement de la rendre plus difficile ! La soi-disant neutralité de la description mène donc à décrire des pratiques scandaleuses au même niveau que l'activité normale d'un opérateur réseaux. Le RFC cite bien le RFC 8165, qui condamne cette pratique, mais n'en tire pas les conséquences, demandant, là encore, qu'on fournisse aux opérateurs malhonnêtes un moyen de continuer ces opérations (par exemple par une insertion des données personnelles directement par le logiciel sur la machine du client, ce qui est possible dans le monde du mobile, beaucoup plus fermé et contrôlé), et ce malgré le chiffrement.

La section 3.1.2 du RFC revient sur les buts de la surveillance, lorsqu'on gère un réseau. Elle mentionne plusieurs de ces buts, par exemple :

  • Détection de logiciel malveillant. À noter que lui, de toute façon, ne va pas se laisser arrêter par une interdiction du chiffrement.
  • Conformité avec des règles imposant la surveillance, qui existent par exemple dans le secteur bancaire. On pourrait garder le chiffrement de bout en bout tout en respectant ces règles, si chaque application enregistrait toutes ses communications. C'est évidemment la bonne solution technique (section 3.2.1 du RFC) mais, à l'heure actuelle, beaucoup de ces applications sont fermées, n'enregistrent pas, et ne permettent pas de traçabilité. (Notons aussi que des normes comme PCI imposent la traçabilité, mais n'imposent pas d'utiliser du logiciel libre, ce qui est assez incohérent. La quadrature du cercle - sécuriser les communications contre l'écoute, tout en permettant l'audit - n'est soluble qu'avec des applications qu'on peut examiner, et qui enregistrent ce qu'elles font.)
  • Opposition à la fuite de données. La « sécurité » souvent mentionnée est en fait un terme vague recouvrant beaucoup de choses. La sécurité de qui et de quoi, faut-il se demander. Ici, il est clair que le patronat et l'État voudraient rendre plus difficile le travail de lanceurs d'alerte, par exemple WikiLeaks. En France, une loi sur « le secret des affaires » fournit aux entreprises qui veulent dissimuler leurs mauvaises actions une défense juridique contre la vérité. La limitation du chiffrement vise à ajouter une défense technique, pour empêcher le ou la lanceur d'alerte d'envoyer des informations discrètement au Canard enchaîné.

La section 3.2 du RFC mentionne d'autres exemples d'usages actuels que le chiffrement massif peut gêner. Par exemple, elle cite la lutte contre le spam en notant que le chiffrement du courrier (par exemple avec PGP ou DarkMail) empêche un intermémdiaire (comme le serveur de messagerie) de lutter contre le spam. (La bonne solution est évidemment de faire l'analyse du spam sur la machine finale, par exemple avec bogofilter.)

Les révélations de Snowden ont montré que l'espionnage des liaisons internes aux organisations était une pratique courante de la NSA. Pendant longtemps, beaucoup d'administrateurs réseau ont considéré que « pas besoin d'utiliser HTTPS, c'est un site Web purement interne ». C'était une grosse erreur technique (l'attaquant est souvent interne, et les attaques contre le DNS ou le routage peuvent donner accès aux communications censées être internes) et elle a donc logiquement été exploitée. Aujourd'hui, les organisations sérieuses chiffrent systématiquement, même en interne.

Mais en même temps, beaucoup d'entreprises ont en interne des règles qui autorisent la surveillance de toutes les communications des employés. (En France, il existe des limites à cette surveillance, mais pas aux États-Unis. Le RFC rappelle juste que certaines politiques définies par le patron autorisent des accès protégés contre la surveillance, par exemple pour se connecter à sa banque. Écrit avec un point de vue très états-unien, le RFC ne mentionne que les politiques de la direction, pas les limites légales.) Techniquement, cela passe, par exemple, par des relais qui terminent la session TLS, examinent le contenu de la communication, puis démarrent une nouvelle session avec le serveur visé. Cela permet par exemple de détecter le logiciel malveillant que la machine Windows télécharge via une page Web piégée. Ou bien une attaque XSS que l'utilisateur n'a pas vue. (Notez que, par une incohérence fréquente en entreprise, la sécurité est présentée comme absolument essentielle, mais les postes de travail tournent sur Windows, certainement la cible la plus fréquente de ces logiciels malveillants.) Mais cela permet aussi de surveiller les communications des employés.

Si le but est de se protéger contre le logiciel malveillant, une solution simple est de faire l'examen des messages suspects sur la machine terminale. Cela peut être plus compliqué à déployer mais, normalement, c'est faisable à la fois juridiquement puisque cette machine appartient à l'entreprise, et techniquement puisqu'elle est a priori gérée à distance.

La section 5 du RFC détaille certaines techniques de surveillance pour des systèmes particuliers. Par exemple, les fournisseurs de messagerie examinent les messages, notamment pour déterminer s'il s'agit de spam. SMTP sur TLS ne gêne pas cette technique puisqu'il est de serveur à serveur, pas de bout en bout. Même PGP ou S/MIME n'empêchent pas l'examen des métadonnées, qui peuvent être suffisante pour détecter le spam.

De même (section 6 du RFC), TLS ne masque pas tout et permet quand même certaines activités de surveillance. Ainsi, le nom du serveur contacté, indiqué dans l'extension TLS SNI (Server Name Indication, section 3 du RFC 6066) n'est pas chiffré et peut donc être vu. (Des efforts sont en cours actuellement à l'IETF pour boucher cette faille dans la protection de la vie privée, et semblent bien avancer.)

En résumé, ce RFC, qui a commencé comme très « anti-chiffrement » a été un peu modifié lors des très vives discussions qu'il a généré à l'IETF, et essaie désormais de ménager la chèvre et le chou. La tonalité demeure quand même hostile au chiffrement sérieux, mais on y trouve suffisamment d'éléments techniques précis pour que tout le monde puisse y trouver une lecture intéressante.


Téléchargez le RFC 8404


L'article seul

« Logiciel libre » et « Open Source », c'est pareil ou pas ?

Première rédaction de cet article le 21 novembre 2018
Dernière mise à jour le 22 novembre 2018


On entend parfois, dans les discussions autour des licences logicielles, des affirmations du genre « tel logiciel n'est pas libre mais il est open source ». Quelle est la différence ? Y en a-t-il une, d'ailleurs ?

Commençons par les textes originaux. Le concept de logiciel libre a été popularisé par Richard Stallman et la Free Software Foundation. Le logiciel libre se définit par quatre libertés :

  • Liberté de faire tourner le logiciel, c'est-à-dire de l'utiliser à des fins quelconques.
  • Liberté d'étudier le programme, ce qui implique notamment l'accès à son code source.
  • Liberté de distribuer des copies du logiciel,
  • y compris des copies modifiées.

On notera que la gratuité n'est pas mentionnée. En anglais, le terme de free software a parfois engendré des malentendus, free pouvant vouloir dire « libre » mais aussi « gratuit ». Comme souvent en politique, ces malentendus étaient parfois de bonne foi, et malhonnêtes dans d'autres, certains faisant semblant de ne pas comprendre que la liberté n'a rien à voir avec la gratuité.

Stallman aime donc répéter que, dans free software, c'est free as in free speech, not free as in free beer. Bonne explication, mais difficile à traduire en français puisque, justement, en français, il y a deux mots différents pour « libre » et « gratuit ».

Et open source ? Notons que ce n'est pas un hasard si le terme en anglais est populaire chez les gens dont le métier est d'embrouiller le langage, les vendeurs ou les politiciens, par exemple. Utiliser un terme en anglais permet de rester dans le flou, et d'essayer de plaire à tout le monde, en n'utilisant pas de termes précis. Le terme a été popularisé par Eric Raymond et quelques autres en 1998. Ils avançaient deux arguments essentiels en faveur de ce nouveau terme : l'ambiguité entre « libre » et « gratuit » (qui, on l'a vu, n'existe pas en français, rendant tout à fait inutile l'utilisation du terme open source), et surtout le fait que la liberté faisait peur, notamment au patronat, et que, si on voulait populariser le logiciel libre auprès des gens qui ont la main sur la carte de crédit de l'entreprise, il fallait changer le nom. (Il y avait bien sûr également des raisons non avouées, comme essayer de remplacer Stallman au poste de symbole du logiciel libre.)

Le terme a clairement été un grand succès, malgré le fait qu'il soit tout aussi ambigu que l'autre (open source ou « source ouverte » désignait déjà tout à fait autre chose). Que mettaient-ils derrière ce terme ? Les promoteurs du terme open source ont produit une définition. Elle est moins percutante que les « quatre libertés », et plus longue, mais elle revient quasiment au même. Notamment, elle précise clairement qu'open source ne veut pas uniquement dire qu'on a accès au code source.

Les deux définitions sont très proches, justifiant que Stallman, paraphrasant Shakespeare, rappelle que « un logiciel libre, sous un autre nom, serait tout aussi libre ». N'est-ce donc qu'une question de terminologie, sans conséquences pratiques ?

Si on regarde la liste des licences libres reconnues par la FSF, et qu'on la compare avec celle des promoteurs du terme open source, on ne voit en effet pas de différence. On cite parfois la question de l'obligation de réciprocité (copyleft en anglais, ou « partage à l'identique » - Share Alike - dans les licences Creative Commons) comme différence entre logiciel libre et open source. Mais cette distinction n'est jamais faite par des gens qui participent au logiciel libre, elle n'arrive que dans des raccourcis médiatiques. L'obligation de réciprocité (un individu ou une entreprise peuvent distribuer le logiciel, même modifié, et même le vendre, mais on a l'obligation de reconnaitre au destinataire les mêmes libertés que celles dont ils ont bénéficié) n'est en effet pas mentionnée dans les quatre libertés qui définissent le logiciel libre. Les personnes qui ne se sont pas renseignées avant et qui disent que le logiciel libre requiert l'obligation de réciprocité sont donc plus stricts sur la définition que Richard Stallman lui-même, alors qu'il est généralement considéré comme un modèle de strictitude.

Bien qu'il existe des cas compliqués de licences qui peuvent être vues comme libres selon une définition et pas selon une autre, ces cas sont très marginaux. L'immense majorité des logiciels libres est sous une licence que les deux définitions classent comme libre. Parmi les exceptions, on note (trouvée par Exagone313) l'amusante licence Foutez ce que vous voulez, apparemment refusée par l'Open Source Initiative mais acceptée par la FSF. Mais elle est peu utilisée. (Si vous avez d'autres références précises d'une exception, d'une licence qui est dans une des listes de licences libres mais pas dans l'autre, je suis preneur. En indiquant des logiciels qui utilisent cette licence, car la plupart des licences candidates pour cet exercice sont peu ou pas utilisées.)

Cette rareté des licences acceptées sous une définition mais pas sous l'autre semble plaider pour une conclusion simple « logiciel libre ou open source, on s'en fiche, c'est pareil ».

À noter que Wikipédia reprend cette définition : « La désignation open source, ou "code source ouvert", s'applique aux logiciels (et s'étend maintenant aux œuvres de l'esprit) dont la licence respecte des critères précisément établis par l'Open Source Initiative, c'est-à-dire les possibilités de libre redistribution, d'accès au code source et de création de travaux dérivés. » Et ajoute « La différence formelle entre open source et logiciel libre (en anglais : free software) n'a quasiment pas de conséquence dans l'évaluation des licences. » (Le bandeau en haut de l'article dit « Ne doit pas être confondu avec Logiciel libre », alors même que l'article explique que c'est pareil...) Le Wiktionnaire dit également que les deux termes sont synonymes.

Mais, évidemment, en matière de langage, les arguments d'autorité et les références aux textes antiques ont leurs limites. Le langage évolue (pas toujours dans le bon sens) et ce qui est important, c'est aussi ce que veulent dire les gens. L'usage compte. Ceux et celles qui utilisent le terme open source veulent-ils dire la même chose que celles et ceux qui disent logiciel libre ? Il est difficile de répondre à cette question. En effet, si on n'utilise pas la définition « officielle », laquelle utilise-t-on ? J'ai la nette impression que les gens qui utilisent open source n'ont pas de définition précise et l'utilisent un peu au petit bonheur la chance. Quand on demande à quelqu'un qui a utilisé le terme open source ce qu'ielle entend par là, on reçoit en général une réponse vague, et souvent fausse (comme par exemple de définir open source par « accès au code source »). Les commerciaux utilisent ce terme pour dire « logiciel libre » mais en moins politique (la liberté, ça fait peur aux clients), les journalistes l'utilisent parce que dans un article sur l'informatique, il faut mettre de l'anglais, beaucoup de gens répètent simplement le terme qu'ils ont entendu dans les médias, sans réfléchir. Si on veut une définition fondée sur l'usage (et non pas sur la définition formelle de l'OSI), on pourrait arriver à quelque chose du genre « quelque chose qui va du logiciel libre [inclus] à diverses formes de logiciels privateurs manifestant un peu d'ouverture ».

En conclusion et résumé :

  • « Logiciel libre » et « Open Source » désignent quasiment exactement les mêmes licences et donc les mêmes logiciels. Il n'y a donc pas de différence pratique.
  • Mais dans l'usage, la plupart des emplois de « Open Source » désignent quelque chose de vague et de pas bien défini.
  • Et les mots sont importants : utiliser « Open Source » n'est pas neutre et veut dire en général qu'on n'est pas spécialement attaché à la liberté.

L'article seul

Capitole du Libre 2018 (et mon exposé sur « Internet et les droits humains »)

Première rédaction de cet article le 19 novembre 2018
Dernière mise à jour le 26 novembre 2018


Les 17 et 18 novembre 2018, c'était Capitole du Libre, grand rassemblement annuel de centaines de libristes à Toulouse, dans les locaux de l'ENSEEIHT. À cette occasion, j'y ai fait un exposé sur le thème « Internet et les droits humains, il y a vraiment un rapport ? ».

Si vous voulez lire les supports de cet exposé, il y a une version PDF pour lire sur écran, et une version PDF pour imprimer. Le tout est évidemment sous une licence libre (celle de ce blog, la GFDL) et vous pouvez diffuser et/ou modifier le tout. Si vous voulez le modifier, le source est en LaTeX/Beamer et cette version est disponible également.

L'exposé a été filmé et la vidéo est disponible via PeerTube, sur l'instance de Jacques. (Également sur YouTube, avec les autres vidéos de Capitole du Libre, si vous préferez donner vos données personnelles à Google.)

Ah, et c'était la première annonce publique de on livre « Cyberstructure ».

Il y avait plein d'autres exposés à Capitole du Libre, dont beaucoup étaient passionnants. Mon préféré était celui de Vincent Privat, sur « André Cros, import Wikimedia d'un fonds d'archive exceptionnel de Toulouse ». André Cros était photographe à Sud Ouest pendant de nombreuses années et a transmis ses photos, avec les droits, à la Mairie de Toulouse, qui est partenaire de Wikimedia. Cela permettait juridiquement de tout mettre sur Wikimedia Commons, avec une licence libre. Les photos étaient déjà numérisées. Il a fallu développer un petit script pour envoyer les photos sur Wikimedia Commons et, surtout, étiqueter et classer chaque photo. On y trouve, entre autre, le premier vol du Concorde, un passage de Sylvie Vartan à Toulouse, la terrible opération de sécurité routière « Une ville rayée de la carte » à Mazamet, les inondations de la Garonne, etc.

Parmi les autres exposés:

Capitole du Libre est remarquablement organisé, avec un gros investissement de la part des bénévoles, donc merci mille fois, c'était extra.


L'article seul

Un service d'hébergement de zones DNS accessible au·à la non-geek ?

Première rédaction de cet article le 3 novembre 2018
Dernière mise à jour le 4 novembre 2018


Dans cet article, je ne vais pas décrire un logiciel ou service existant, ni résumer un RFC. Je voudrais au contraire pointer du doigt un manque dans l'offre existante, à la fois l'offre de services non-commerciaux accessibles au·à la non-geek, et l'offre de logiciel libre. Pourquoi n'y a-t-il pas de système simple pour héberger une zone DNS ? Et, si un·e militant·e de la liberté sur Internet passe par là, ne serait-ce pas une bonne idée d'en créer un ? J'espère que cet article donnera des idées.

Un peu de contexte d'abord. Le DNS est à la base de quasiment toutes les transactions sur l'Internet. Si on se soucie de la liberté et de l'indépendance de l'utilisateur qui veut publier quelque chose, et pas être un·e simple consommat·eur·rice, avoir un nom de domaine à soi est crucial. Acheter/louer un tel nom est simple et peu coûteux (encore qu'il semble qu'il n'existe que très peu, voire pas du tout, de bureaux d'enregistrement non-commerciaux). L'héberger est une autre histoire. L'hébergeur DNS (qui n'est pas forcément le bureau d'enregistrement) joue un rôle crucial. S'il est en panne, plus rien ne marche. S'il enregistre les données, la vie privée est menacée (sur ce risque, voir le RFC 7626). Il faut donc le choisir avec soin.

Or, beaucoup de titulaires de nom de domaine choisissent une entreprise (par exemple Cloudflare) un peu au hasard, sans avoir étudié ses pratiques. Il serait évidemment préférable de faire héberger ses serveurs de noms dans un endroit plus sûr.

Un solution geek existe pour cela, l'auto-hébergement des serveurs de noms. Ce n'est pas très compliqué (un logiciel libre comme nsd fait cela très bien) et cela ne demande que peu de ressources (un serveur DNS ne représente que peu de trafic, un Raspberry Pi connecté en ADSL suffit largement pour la plupart des zones, d'autant plus que le vrai serveur primaire n'a pas forcément besoin d'être accessible de tout l'Internet, il peut être caché, visible uniquement des secondaires). Si on veut améliorer les choses, on peut demander à des cop·ain·ine·s d'héberger un serveur secondaire de sa zone. C'est ainsi qu'est hébergée la zone DNS de ce blog, bortzmeyer.org.

Mais, évidemment, c'est uniquement une solution pour geek. On ne peut pas demander à toute personne qui publie sur Internet de configurer nsd ou Knot même si, je le répète, c'est relativement simple. Et il faudrait en plus éditer son fichier de zone DNS avec un éditeur de texte, ce qui n'enchante pas le non-geek. Or, la liberté d'expression ne doit pas être réservée aux informaticiens !

Il faudrait donc une solution pour ces utilisateurices. Il y a deux moyens de fournir cette solution, via un service ou via un logiciel. Concentrons-nous d'abord sur les services car, même s'il existait un logiciel tout fait, libre et tout, il resterait à gérer l'administration quotidienne du serveur, et un serveur DNS fait parfois face à des problèmes (voir plus loin dans cet article le problème des dDoS). Des services pour M. ou Mme Toutlemonde, libres, éthiques, non-commerciaux et le reste, existent, ce sont par exemple les CHATONS, dont le plus connu est Framasoft. Mais, à l'heure actuelle, à ma connaissance, aucun CHATON ne propose d'hébergement DNS.

Esquissons brièvement le cahier des charges d'un tel service :

  • Utilisable indépendamment d'autres services (comme l'hébergement Web),
  • Permet aux internautes de s'inscrire, puis de donner une liste de domaines qu'ils souhaitent voir gérés par le service,
  • Permet de gérer le contenu de la zone DNS, en indiquant différents enregistrements, de tous les types possibles, avec leurs valeurs. L'interface proposée doit être simple d'usage, sans limiter les possibilités. Tous les hébergeurs DNS ont aujourd'hui une telle interface, typiquement via le Web et parfois via une API en prime.
  • Raisonnablement sécurisé, car il ne faut pas qu'un utilisateur puisse modifier le domaine d'un autre !
  • Ne réinventant pas la roue, donc reposant sur un logiciel de serveur DNS faisant autorité qui soit stable et sérieux comme nsd ou Knot.
  • D'un point de vue de l'utilisateur, il serait bon d'avoir un mode simple, où on donne juste l'adresse IP du serveur Web, avec des modes plus avancés pour les utilisateurs qui ne se contentent pas d'un site Web.
  • D'un point de vue politique, certains peuvent aussi souhaiter pouvoir maîtriser où sont situés les serveurs faisant autorité (on peut vouloir éviter tel ou tel pays, et migrer facilement),
  • D'un point de vue plus technique, il faudrait DNSSEC (passage des enregistrements DS mais, surtout, gestion des clés et signatures par l'hébergeur), les mises à jour dynamiques du RFC 2136 (mais une bonne API peut les remplacer).

Un tel service, à ma connaissance, n'existe pas aujourd'hui dans le monde associatif. Il faut dire qu'il existe quelques risques :

  • Le service pourrait être confronté à des menaces juridiques (la liberté d'expression ne plait pas à tout le monde), venant par exemple d'ayant-trop-de-droits si on héberge une zone DNS comme celle de Sci-Hub, ou bien venant d'adversaires politiques (cf. le cas d'IndyMedia),
  • Tout le monde ne croit pas à l'état de droit et donc les menaces pourraient être suivies, voire précédées d'attaques par déni de service. L'exemple de Dyn ou bien celui du domaine national turc invitent à être prudent. Un hébergement DNS sympa fait par deux-trois potes pourrait ne pas résister à une dDoS un peu sérieuse.
  • L'attaque par déni de service n'est pas la seule menace. Il existe aussi le risque de détournement du nom, comme c'était arrivé à Wikileaks et à beaucoup d'autres. Bien sûr, si le détournement avait exploité une faute de l'utilisateur, le logiciel n'y peut pas grand'chose. Mais certains détournements étaient dûs à une faille de sécurité du logiciel.

On peut citer quelques services possibles qui se rapprochent de ce but :

  • Le plus connu est Xname, dont la documentation est très complète, mais il est apparement abandonné (aucune nouvelle depuis 2013). Je teste et Error: bad zone name example.com. Donc, cela ne semble pas marcher. Le service semble vraiment mort, d'autant plus que leur propre zone est pleine d'erreurs.
  • J'ai essayé de tester NetLibre. Il ne fournit pas d'hébergement sec, il faut utiliser NetLibre pour acquérir son nom (pour lequel on n'a donc pas un choix complet, on est limité aux domaines de NetLibre). C'est donc plutôt l'équivalent de eu.org, avec hébergement en plus. De toute façon, le service semble peu maintenu : Oh ! Une erreur est survenue. scp failed: unable to fork ssh master: Cannot allocate memory at /home/ppittoli/dnsmanager/bin/../lib/copycat.pm line 35 (et la seule adresse de contact est sur IRC).
  • Le service Free DNS est franchement trop compliqué pour moi. Je n'ai tout simplement pas compris ce qu'on pouvait faire avec, et comment s'en servir (mon domaine est marqué comme BROKEN et la FAQ est incompréhensible, et fausse quand elle prétend The central authority for all domains on the Internet is ICANN).
  • On m'a cité nohost.me, mais, si j'ai bien compris, c'est utilisable uniquement depuis YunoHost.

Cela, c'était pour un service en ligne. Et un logiciel ? Je vois deux cas d'usage :

  • Pour ce·ux·elles qui ne font confiance à personne, et/ou ne veulent dépendre de personne. Le logiciel n'a alors pas besoin d'avoir la notion de comptes ou d'utilisateur, puisqu'il n'existe qu'un·e utilisat·eur·rice.
  • Pour ce·ux·elles qui veulent faire essaimer le service. (Dans ce cas, le logiciel pourrait être utilisé par l'éventuel service public, puis par ses spin-offs.)

Ce doit être bien sûr un logiciel libre, qui doit pouvoir être installé relativement facilement, et fournir le service décrit ci-dessus. Pour le premier cas d'usage, le cas individuel, il serait peut-être encore mieux qu'il soit intégré à une plate-forme comme Cozy. Là encore, à ma connaissance, un tel logiciel n'existe pas (il existe plusieurs trucs plus ou moins bricolés, pas évidents à installer sur sa machine, et encore moins à maintenir).

Les logiciels existants qui pourraient servir d'inspiration :

  • DNS zones manager, le logiciel derrière NetLib.re. Je n'ai pas réussi à l'installer (perlbrew install perl-5.18.0 donne « ERROR: Failed to download http://www.cpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.tar.bz2 », il faut manifestement des compétences Perl plus pointues que les miennes.)
  • Il existe des logiciels bien plus génériques que des seuls gestionnaires de zones DNS, qui pourraient servir de point de départ. C'est le cas de ISPConfig ou Webmin, par exemple.

Mais notez bien que le logiciel ne résout qu'une partie du problème : il faut encore les serveurs. C'est pour cela que je pense que la solution « service hébergé » est plus adaptée aux non-geeks.

Notons enfin qu'un service limité, qui ne fournisse que le serveur secondaire, charge à l'utilisateur d'avoir son propre primaire, serait déjà très utile. Là encore, il me semble qu'il n'existe rien de tel. Peut-être :

  • Puck. L'interface est vraiment rude (elle n'indique même pas quelle est l'adresse IP à autoriser, il faut regarder son journal !) mais ça marche bien. (Pensez à mettre ensuite puck.nether.net dans l'ensemble des enregistrements NS.)
  • Au Danemark, il y a GratisDNS, depuis 1999 (documentation uniquement en danois.)
  • EntryDNS faisait un service gratuit, mais il est désormais arrêté et remplacé par un service payant (mais très bon marché).

Je serai ravi d'apprendre que j'ai mal cherché et qu'un tel service ou un tel logiciel existent. N'hésitez pas à me le faire savoir. Et, si je ne me suis pas trompé, si un·e courageu·x·se pouvait le réaliser…


L'article seul

RFC 8484: DNS Queries over HTTPS (DoH)

Date de publication du RFC : Octobre 2018
Auteur(s) du RFC : P. Hoffman (ICANN), P. McManus (Mozilla)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF doh
Première rédaction de cet article le 22 octobre 2018


Voici un nouveau moyen d'envoyer des requêtes DNS, DoH (DNS over HTTPS). Requêtes et réponses, au lieu de voyager directement sur UDP ou TCP sont encapsulées dans HTTP, plus exactement HTTPS. Le but ? Il s'agit essentiellement de contourner la censure, en fournissant un canal sécurisé avec un serveur supposé digne de confiance. Et le chiffrement sert également à préserver la vie privée du client. Toutes ces fonctions pourraient être assurées en mettant le DNS sur TLS (RFC 7858) mais DoH augmente les chances de succès puisque le trafic HTTPS est rarement bloqué par les pare-feux, alors que le port 853 utilisé par DNS-sur-TLS peut être inaccessible, vu le nombre de violations de la neutralité du réseau. DoH marque donc une nouvelle étape dans la transition vers un Internet « port 443 seulement ».

La section 1 du RFC détaille les buts de DoH. Deux buts principaux sont décrits :

  • Le premier, et le plus important, est celui indiqué au paragraphe précédent : échapper aux middleboxes qui bloquent le trafic DNS, ou bien le modifient. De telles violations de la neutralité du réseau sont fréquentes, imposées par les États ou les entreprises à des fins de censure, ou bien décidées par les FAI pour des raisons commerciales. Dans la lutte sans fin entre l'épée et la cuirasse, le DNS est souvent le maillon faible : infrastructure indispensable, il offre une cible tentante aux attaquants. Et il est utilisable pour la surveillance (cf. RFC 7626). DNS-sur-TLS, normalisé dans le RFC 7858, était une première tentative de protéger l'intégrité et la confidentialité du trafic DNS par la cryptographie. Mais il utilise un port dédié, le port 853, qui peut être bloqué par un intermédiaire peu soucieux de neutralité du réseau. Dans de nombreux réseaux, hélas, le seul protocole qui soit à peu près sûr de passer partout est HTTPS sur le port 443. D'où la tendance actuelle à tout mettre sur HTTP.
  • Il y a une deuxième motivation à DoH, moins importante, la possibilité de faire des requêtes DNS complètes (pas seulement des demandes d'adresses IP) depuis des applications JavaScript tournant dans le navigateur, et tout en respectant CORS.

L'annexe A de notre RFC raconte le cahier des charges du protocole DoH de manière plus détaillée :

  • Sémantique habituelle de HTTP (on ne change pas HTTP),
  • Possibilité d'exprimer la totalité des requêtes et réponses DNS actuelles, d'où le choix de l'encodage binaire du DNS et pas d'un nouvel encodage, par exemple en JSON, plus simple mais limité à un sous-ensemble du DNS,
  • Et aussi des « non-considérations » : DoH n'avait pas à traiter le cas des réponses synthétisées, comme DNS64, ni celui des réponses à la tête du client, ni le HTTP tout nu sans TLS.

Passons maintenant à la technique. DoH est un protocole très simple. Au hackathon de l'IETF en mars 2018 à Londres, les sept ou huit personnes travaillant sur DoH avaient très vite réussi à créer clients et serveurs, et à les faire interopérer (même moi, j'y étais arrivé). Vous pouvez lire le compte-rendu du hackathon, et la présentation quelques jours après au groupe de travail DoH.)

DoH peut s'utiliser de plusieurs façons : c'est une technique, pas une politique. Néanmoins, son principal usage sera entre un résolveur simple, situé sur la machine de l'utilisateur ou quelque part dans son réseau local, et un résolveur complet situé plus loin dans le réseau (section 1 du RFC). Ce résolveur simple peut être un démon comme stubby ou systemd, ou bien l'application elle-même (ce qui me semble personnellement une mauvaise idée, car cela empêche de partager configuration et cache). À l'heure actuelle, les serveurs faisant autorité ne parlent pas DoH et il n'est pas prévu qu'ils s'y mettent à brève échéance. Le schéma suivant montre l'utilisation typique de DoH : l'application (le client final) parle à un résolveur simple, en utilisant le protocole DNS (ce qui évite de mettre du DoH dans toutes les applications), le résolveur simple parlera en DoH avec un résolveur de confiance situé quelque part dans l'Internet, et ce résolveur de confiance utilisera le DNS pour parler aux serveurs faisant autorité (soit il sera lui-même un résolveur complet, soit il parlera à un résolveur classique proche de lui, et le serveur DoH sera alors un proxy comme décrit dans le RFC 5625) : doh.png

Les requêtes et réponses DNS (RFC 1034 et RFC 1035) ont leur encodage habituel (le DNS est un protocole binaire, donc je ne peux pas faire de copier/coller pour montrer cet encodage), la requête est mise dans le chemin dans l'URL ou dans le corps d'une requête HTTP (RFC 7540), la réponse se trouvera dans le corps de la réponse HTTP. Toute la sécurité (intégrité et confidentialité) est assurée par TLS (RFC 8446), via HTTPS (RFC 2818). Un principe essentiel de DoH est d'utiliser HTTP tel quel, avec ses avantages et ses inconvénients. Cela permet de récupérer des services HTTP comme la négociation de contenu, la mise en cache, l'authentification, les redirections, etc.

La requête HTTP elle-même se fait avec les méthodes GET ou POST (section 4 du RFC), les deux devant être acceptées (ce qui fut le sujet d'une assez longue discussion à l'IETF.) Quand la méthode utilisée est GET, la variable nommée dns est le contenu de la requête DNS, suivant l'encodage habituel du DNS, surencodée en Base64, plus exactement la variante base64url normalisée dans le RFC 4648. Et, avec GET, le corps de la requête est vide (RFC 7231, section 4.3.1). Quand on utilise POST, la requête DNS est dans le corps de la requête HTTP et n'a pas ce surencodage. Ainsi, la requête avec POST sera sans doute plus petite, mais par contre GET est certainement plus apprécié par les caches.

On l'a dit, DoH utilise le HTTP habituel. L'utilisation de HTTP/2, la version 2 de HTTP (celle du RFC 7540) est très recommandée, et clients et serveurs DoH peuvent utiliser la compression et le remplissage que fournit HTTP/2 (le remplissage étant très souhaitable pour la vie privée). HTTP/2 a également l'avantage de multiplexer plusieurs ruisseaux (streams) sur la même connexion HTTP, ce qui évite aux requêtes DoH rapides de devoir attendre le résultat d'une requête lente qui aurait été émise avant. (HTTP 1, lui, impose le respect de l'ordre des requêtes.) HTTP/2 n'est pas formellement imposé, car on ne peut pas forcément être sûr du comportement des bibliothèques utilisées, ni de celui des différents relais sur le trajet.

Requêtes et réponses ont actuellement le type MIME application/dns-message, mais d'autres types pourront apparaitre dans le futur (par exemple fondés sur JSON et non plus sur l'encodage binaire du DNS, qui n'est pas amusant à analyser en JavaScript). Le client DoH doit donc inclure un en-tête HTTP Accept: pour indiquer quels types MIME il accepte. En utilisant HTTP, DoH bénéfice également de la négociation de contenu HTTP (RFC 7231, section 3.4).

Petit détail DNS : le champ ID (identification de la requête) doit être mis à zéro. Avec UDP, il sert à faire correspondre une requête et sa réponse mais c'est inutile avec HTTP, et cela risquerait d'empêcher la mise en cache de deux réponses identiques mais avec des ID différents.

En suivant la présentation des requêtes HTTP du RFC 7540 (rappelez-vous que HTTP/2, contrairement à la première version de HTTP, a un encodage binaire), cela donnerait, par exemple :

:method = GET
:scheme = https
:authority = dns.example.net
:path = /?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message
    

(Si vous vous le demandez, AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB est une requête DNS pour l'adresse IPv4 de www.example.com.)

Et la réponse HTTP ? Aujourd'hui, elle est forcément de type MIME application/dns-message, mais d'autres types pourront apparaitre. En attendant, le corps de la réponse HTTP est une réponse DNS avec son encodage binaire habituel normalisé dans le RFC 1035, section 4.1 (tel qu'utilisé pour UDP ; notez que HTTP permettant d'indiquer la longueur du message, les deux octets de longueur utilisés par le DNS au-dessus de TCP ne sont pas nécessaires et sont donc absents).

Le serveur DoH doit mettre un code de retour HTTP (RFC 7231). 200 signifie que la requête HTTP a bien été traitée. Mais cela ne veut pas dire que la requête DNS, elle, ait connu un succès. Si elle a obtenu une erreur DNS NXDOMAIN (nom non trouvé) ou SERVFAIL (échec de la requête), le code de retour HTTP sera quand même 200, indiquant qu'il y a une réponse DNS, même négative. Le client DoH, en recevant ce 200, devra donc analyser le message DNS et y trouver le code de retour DNS (NOERROR, NXDOMAIN, REFUSED, etc). Le serveur DoH ne mettra un code d'erreur HTTP que s'il n'a pas du tout de réponse DNS à renvoyer. Il mettra 403 s'il refuse de servir ce client DoH, 429 si le client fait trop de requêtes (RFC 6585), 500 si le serveur DoH a une grosse bogue, 415 si le type MIME utilisé n'est pas connu du serveur, et bien sûr 404 si le serveur HTTP ne trouve rien à l'URL indiqué par exemple parce que le service a été retiré. Dans tous ces cas, il n'y a pas de réponse DNS incluse. La sémantique de ces codes de retour, et le comportement attendu du client, suit les règles habituelles de HTTP, sans spécificité DoH. (C'est un point important et général de DoH : c'est du DNS normal sur du HTTP normal). Par exemple, lorsque le code de retour commence par un 4, le client n'est pas censé réessayer la même requête sur le même serveur : elle donnera forcément le même résultat.

Voici un exemple de réponse DoH :

:status = 200
content-type = application/dns-message
content-length = 61
cache-control = max-age=3709
[Les 61 octets, ici représentés en hexadécimal pour la lisibilité]
   00 00 81 80 00 01 00 01  00 00 00 00 03 77 77 77
   07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 1c 00
   01 c0 0c 00 1c 00 01 00  00 0e 7d 00 10 20 01 0d
   b8 ab cd 00 12 00 01 00  02 00 03 00 04
    

La réponse DNS signifie « l'adresse de www.example.com est 2001:db8:abcd:12:1:2:3:4 et le TTL est de 3709 secondes [notez comme il est repris dans le Cache-control: HTTP] ».

Comment un client DoH trouve-t-il le serveur ? La section 3 du RFC répond à cette question. En gros, c'est manuel. DoH ne fournit pas de mécanisme de sélection automatique. Concevoir un tel mécanisme et qu'il soit sécurisé est une question non triviale, et importante : changer le résolveur DNS utilisé par une machine revient quasiment à pirater complètement cette machine. Cela avait fait une très longue discussion au sein du groupe de travail DoH à l'IETF, entre ceux qui pensaient qu'un mécanisme automatique de découverte du gabarit faciliterait nettement la vie de l'utilisateur, et ceux qui estimaient qu'un tel mécanisme serait trop facile à subvertir. Donc, pour l'instant, le client DoH reçoit manuellement un gabarit d'URI (RFC 6570) qui indique le serveur DoH à utiliser. Par exemple, un client recevra le gabarit https://dns.example.net/{?dns}, et il fera alors des requêtes HTTPS à dns.example.net, en passant ?dns=[valeur de la requête].

Notez que l'URL dans le gabarit peut comporter un nom de domaine, qui devra lui-même être résolu via le DNS, créant ainsi un amusant problème d'œuf et de poule (cf. section 10 de notre RFC). Une solution possible est de ne mettre que des adresses IP dans l'URL, mais cela peut poser des problèmes pour l'authentification du serveur DoH, toutes les autorités de certification n'acceptant pas de mettre des adresses IP dans le certificat (cf. RFC 6125, section 1.7.2, et annexe B.2).

La section 5 du RFC détaille quelques points liés à l'intégration avec HTTP. D'abord, les caches. DNS et HTTP ont chacun son système. Et entre le client et le serveur aux extrémités, il peut y avoir plusieurs caches DNS et plusieurs caches HTTP, et ces derniers ne connaissent pas forcément DoH. Que se passe-t-il si on réinjecte dans le DNS des données venues d'un cache HTTP ? En général, les réponses aux requêtes POST ne sont pas mises en cache (elles le peuvent, en théorie) mais les requêtes GET le sont, et les implémenteurs de DoH doivent donc prêter attention à ces caches. La méthode recommandée est de mettre une durée de validité explicite dans la réponse HTTP (comme dans l'exemple plus haut avec Cache-control:), en suivant le RFC 7234, notamment sa section 4.2. La durée de validité doit être inférieure ou égale au plus petit TTL de la section principale de la réponse DNS. Par exemple, si un serveur DoH renvoie cette réponse DNS :

ns1.bortzmeyer.org.	27288 IN AAAA 2605:4500:2:245b::42
ns2.bortzmeyer.org.	26752 IN AAAA 2400:8902::f03c:91ff:fe69:60d3
ns4.bortzmeyer.org.	26569 IN AAAA 2001:4b98:dc0:41:216:3eff:fe27:3d3f
    

alors, la réponse HTTP aura un Cache-Control: max-age=26569, le plus petit des TTL.

Si la réponse DNS varie selon le client, le serveur DoH doit en tenir compte pour construire la réponse HTTP. Le but est d'éviter que cette réponse adaptée à un client spécifique soit réutilisée. Cela peut se faire avec Cache-Control: max-age=0 ou bien avec un en-tête Vary: (RFC 7231, section 7.1.4 et RFC 7234, section 4.1) qui va ajouter une condition supplémentaire à la réutilisation des données mises en cache.

S'il y a un en-tête Age: dans la réponse HTTP (qui indique depuis combien de temps cette information était dans un cache Web, RFC 7234, section 5.1), le client DoH doit en tenir compte pour calculer le vrai TTL. Si le TTL DNS dans la réponse est de 600 secondes, mais que Age: indiquait que cette réponse avait séjourné 250 secondes dans le cache Web, le client DoH doit considérer que cette réponse n'a plus que 350 secondes de validité. Évidemment, un client qui veut des données ultra-récentes peut toujours utiliser le Cache-control: no-cache dans sa requête HTTP, forçant un rafraichissement. (Il est à noter que le DNS n'a aucun mécanisme équivalent, et qu'un serveur DoH ne saura donc pas toujours rafraichir son cache DNS.)

La définition formelle du type MIME application/dns-message figure en section 6 de notre RFC, et ce type est désormais enregistré à l'IANA.

La section 8 du RFC est consacrée aux questions de vie privée. C'est à la fois un des principaux buts de DoH (empêcher l'écoute par un tiers) et un point qui a fait l'objet de certaines polémiques, puisque DoH peut être utilisé pour envoyer toutes les requêtes à un gros résolveur public auquel on ne fait pas forcément confiance. Le RFC 7626 traite séparément deux problèmes : l'écoute sur le réseau, et l'écoute effectuée par le serveur. Sur le réseau, DoH protège : tout est chiffré, via un protocole bien établi, TLS. Du fait que le serveur est authentifié, l'écoute par un homme du milieu est également empêchée. DNS sur TLS (RFC 7858) a exactement les mêmes propriétés, mais pour principal inconvénient d'utiliser un port dédié, le 853, trop facile à bloquer. Au contraire, le trafic DoH, passant au milieu d'autres échanges HTTP sur le port 443, est bien plus difficile à restreindre.

Mais et sur le serveur de destination ? Une requête DNS normale contient peu d'informations sur le client (sauf si on utilise la très dangereuse technique du RFC 7871). Au contraire, une requête HTTP est bien trop bavarde : cookies (RFC 6265), en-têtes User-Agent: et Accept-Language:, ordre des en-têtes sont trop révélateurs de l'identité du client. L'utilisation de HTTP présente donc des risques pour la vie privée du client, risques connus depuis longtemps dans le monde HTTP mais qui sont nouveaux pour le DNS. Il avait été envisagé, pendant la discussion à l'IETF, de définir un sous-ensemble de HTTP ne présentant pas ces problèmes, mais cela serait rentré en contradiction avec les buts de DoH (qui étaient notamment de permettre l'utilisation du code HTTP existant). Pour l'instant, c'est donc au client DoH de faire attention. Si la bibliothèque HTTP qu'il utilise le permet, il doit veiller à ne pas envoyer de cookies, à envoyer moins d'en-têtes, etc.

Notez que la question de savoir si les requêtes DoH doivent voyager sur la même connexion que le trafic HTTPS normal (ce que permet HTTP/2, avec son multiplexage) reste ouverte. D'un côté, cela peut aider à les dissimuler. De l'autre, les requêtes HTTP typiques contiennent des informations qui peuvent servir à reconnaitre le client, alors qu'une connexion servant uniquement à DoH serait moins reconnaissable, le DNS étant nettement moins sensible au fingerprinting.

Comme TLS ne dissimule pas la taille des messages, et qu'un observateur passif du trafic, et qui peut en plus envoyer des requêtes au serveur DNS, peut en déduire les réponses reçues, le RFC recommande aux clients DoH de remplir les requêtes DNS selon le RFC 7830.

Le choix de Mozilla d'utiliser DoH pour son navigateur Firefox (voir un compte-rendu de la première expérience) et le fait que, dans certaines configurations, le serveur DoH de Cloudflare était systématiquement utilisé a été très discuté (cf. cette discussion sur le forum des développeurs et cet article du Register). Mais cela n'a rien à voir avec DoH : c'est le choix d'utiliser un résolveur public géré par un GAFA qui est un problème, pas la technique utilisée pour accéder à ce résolveur public. DNS-sur-TLS aurait posé exactement le même problème. Si Mozilla a aggravé les choses avec leur discours corporate habituel (« nous avons travaillé très dur pour trouver une entreprise de confiance »), il faut rappeler que le problème de la surveillance et de la manipulation des requête et réponses DNS par les FAI est un problème réel (essayez de demander à votre FAI s'il s'engage à ne jamais le faire). On a vu plus haut que DoH ne prévoit pas de système de découverte du serveur. Il faut donc que cela soit configuré en dur (un travail supplémentaire pour les utilisateurs, s'il n'y a pas de résolveur par défaut). En tout cas, le point important est que DoH (ou DNS-sur-TLS) ne protège la vie privée que si le serveur DoH est honnête. C'est une limitation classique de TLS : « TLS permet de s'assurer qu'on communique bien avec Satan, et qu'un tiers ne peut pas écouter ». Mais DoH n'impose pas d'utiliser un serveur public, et impose encore moins qu'il s'agisse d'un serveur d'un GAFA.

La section 9 de notre RFC traite des autres problèmes de sécurité. D'abord, sur la relation entre DoH et DNSSEC. C'est simple, il n'y en a pas. DNSSEC protège les données, DoH protège le canal (une distinction que les promoteurs de DNSCurve n'ont jamais comprise). DNSSEC protège contre les modifications illégitimes des données, DoH (ou bien DNS-sur-TLS) protège contre l'écoute illégitime. Ils résolvent des problèmes différents, et sont donc tous les deux nécessaires.

Quant à la section 10 du RFC, elle expose diverses considérations pratiques liées à l'utilisation de DoH. Par exemple, si un serveur faisant autorité sert des réponses différentes selon l'adresse IP source du client (RFC 6950, section 4), utiliser un résolveur public, qu'on y accède via DoH ou par tout autre moyen, ne donnera pas le résultat attendu, puisque l'adresse IP vue par le serveur faisant autorité sera celle du résolveur public, probablement très distincte de celle du « vrai » client. Un exemple similaire figure dans le RFC : une technique comme DNS64 (RFC 6147) risque fort de ne pas marcher avec un résolveur DNS extérieur au réseau local.

Quelles sont les mises en œuvre de DoH ? Le protocole est assez récent donc votre système favori n'a pas forcément DoH, ou alors c'est seulement dans les toutes dernières versions. Mais DoH est très simple à mettre en œuvre (c'est juste la combinaison de trois protocoles bien maitrisés, et pour lesquels il existe de nombreuses bibliothèques, DNS, HTTP et TLS) et le déploiement ne devrait donc pas poser de problème.

Voyons maintenant ce qui existe, question logiciels et serveurs. On a vu que Cloudflare a un serveur public, le fameux 1.1.1.1 étant accessible en DoH (et également en DNS-sur-TLS). Je ne parlerai pas ici de la question de la confiance qu'on peut accorder à ce serveur (je vous laisse lire sa politique de vie privée et l'évaluer vous-même), qui avait été contestée lors de la polémique Mozilla citée plus haut. Cloudflare fournit également une bonne documentation sur DoH, avec une explication de l'encodage. Enfin, Cloudflare fournit un résolveur simple (comme stubby ou systemd cités plus haut) qui est un client DoH, cloudflared.

Un autre serveur DoH public, cette fois issu du monde du logiciel libre, est celui de l'équipe PowerDNS, https://doh.powerdns.org/ (cf. leur annonce). Il utilise leur logiciel dnsdist.

Vous trouverez une liste de serveurs DoH publics chez DefaultRoutes ou bien chez curl ou encore sur le portail dnsprivacy.org. Testons ces serveurs DoH publics avec le programme doh-nghttp.c, qui avait été écrit au hackathon IETF 101, on lui donne l'URL du serveur DoH, et le nom à résoudre, et il cherche l'adresse IPv4 correspondant à ce nom :

% ./doh-nghttp https://doh.powerdns.org/ www.bortzmeyer.org
The address is 204.62.14.153

% ./doh-nghttp  https://1.1.1.1/dns-query www.bortzmeyer.org 
The address is 204.62.14.153

% ./doh-nghttp  https://doh.defaultroutes.de/dns-query www.bortzmeyer.org 
The address is 204.62.14.153

% ./doh-nghttp   https://mozilla.cloudflare-dns.com/dns-query www.bortzmeyer.org
The address is 204.62.14.153
    

Parfait, tout a bien marché. Un autre serveur DoH a la particularité d'être un résolveur menteur (regardez son nom) :

% ./doh-nghttp    https://doh.cleanbrowsing.org/doh/family-filter/ www.bortzmeyer.org
The address is 204.62.14.153

% ./doh-nghttp    https://doh.cleanbrowsing.org/doh/family-filter/ pornhub.com       
The search had no results, and a return value of 8. Exiting.

% ./doh-nghttp https://doh.powerdns.org/   pornhub.com      
The address is 216.18.168.16
    

Bon, et si je veux faire mon propre serveur DoH, on a quelles solutions ? Voyons d'abord le doh-proxy de Facebook. On lui indique le résolveur qu'il va utiliser (il n'est pas inclus dans le code, il a besoin d'un résolveur complet, a priori sur la même machine ou le même réseau local) :


% doh-proxy --port=9443 --upstream-resolver=192.168.2.254 --certfile=server.crt --keyfile=server.key --uri=/
2018-09-27 10:04:21,997:     INFO: Serving on <Server sockets=[<socket.socket fd=6, family=AddressFamily.AF_INET6, type=2049, proto=6, laddr=('::1', 9443, 0, 0)>]>

Et posons-lui des questions avec le même client doh-nghttp :

% ./doh-nghttp  https://ip6-localhost:9443/ www.bortzmeyer.org 
The address is 204.62.14.153
   

C'est parfait, il a marché et affiche les visites :

   
2018-09-27 10:04:24,264:     INFO: [HTTPS] ::1 www.bortzmeyer.org. A IN 0 RD
2018-09-27 10:04:24,264:     INFO: [DNS] ::1 www.bortzmeyer.org. A IN 56952 RD
2018-09-27 10:04:24,639:     INFO: [DNS] ::1 www.bortzmeyer.org. A IN 56952 QR/RD/RA 1/0/0 -1/0/0 NOERROR 374ms
2018-09-27 10:04:24,640:     INFO: [HTTPS] ::1 www.bortzmeyer.org. A IN 0 QR/RD/RA 1/0/0 -1/0/0 NOERROR 375ms

Au même endroit, il y a aussi un client DoH :

% doh-client --domain 1.1.1.1 --uri /dns-query --qname www.bortzmeyer.org
2018-09-27 10:14:12,191:    DEBUG: Opening connection to 1.1.1.1
2018-09-27 10:14:12,210:    DEBUG: Query parameters: {'dns': 'AAABAAABAAAAAAAAA3d3dwpib3J0em1leWVyA29yZwAAHAAB'}
2018-09-27 10:14:12,211:    DEBUG: Stream ID: 1 / Total streams: 0
2018-09-27 10:14:12,219:    DEBUG: Response headers: [(':status', '200'), ('date', 'Thu, 27 Sep 2018 08:14:12 GMT'), ('content-type', 'application/dns-message'), ('content-length', '103'), ('access-control-allow-origin', '*'), ('cache-control', 'max-age=5125'), ('expect-ct', 'max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"'), ('server', 'cloudflare-nginx'), ('cf-ray', '460c83ee69f73c53-CDG')]
id 0
opcode QUERY
rcode NOERROR
flags QR RD RA AD
edns 0
payload 1452
;QUESTION
www.bortzmeyer.org. IN AAAA
;ANSWER
www.bortzmeyer.org. 5125 IN AAAA 2001:4b98:dc0:41:216:3eff:fe27:3d3f
www.bortzmeyer.org. 5125 IN AAAA 2605:4500:2:245b::42
;AUTHORITY
;ADDITIONAL
2018-09-27 10:14:12,224:    DEBUG: Response trailers: {}

Ainsi qu'un résolveur simple (serveur DNS et client DoH).

Il ne faut pas confondre ce doh-proxy écrit en Python avec un logiciel du même nom écrit en Rust (je n'ai pas réussi à le compiler, celui-là, des compétences Rust plus avancées que les miennes sont nécessaires).

Et les clients, maintenant ? Commençons par le bien connu curl, qui a DoH est depuis la version 7.62.0 (pas encore publiée à l'heure où j'écris, le développement est documenté ici.) curl (comme Mozilla Firefox) fait la résolution DNS lui-même, ce qui est contestable (il me semble préférable que cette fonction soit dans un logiciel partagé par toutes les applications). Voici un exemple :


% ./src/.libs/curl -v --doh-url  https://doh.powerdns.org/ www.bortzmeyer.org
... [Se connecter au serveur DoH]
* Connected to doh.powerdns.org (2a01:7c8:d002:1ef:5054:ff:fe40:3703) port 443 (#2)
* ALPN, offering h2
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*  subject: CN=doh.powerdns.org
... [Envoyer la requête DoH]
* Using Stream ID: 1 (easy handle 0x5631606cbd50)
> POST / HTTP/2
> Host: doh.powerdns.org
> Accept: */*
> Content-Type: application/dns-message
> Content-Length: 36
...
< HTTP/2 200 
< server: h2o/2.2.5
< date: Thu, 27 Sep 2018 07:39:14 GMT
< content-type: application/dns-message
< content-length: 92
... [On a trouvé la réponse DoH]
* DOH Host name: www.bortzmeyer.org
* TTL: 86392 seconds
* DOH A: 204.62.14.153
* DOH AAAA: 2001:4b98:0dc0:0041:0216:3eff:fe27:3d3f
* DOH AAAA: 2605:4500:0002:245b:0000:0000:0000:0042
... [On peut maintenant se connecter au serveur HTTP - le but
principal de curl - maintenant qu'on a son adresse IP]
* Connected to www.bortzmeyer.org (204.62.14.153) port 80 (#0)
> GET / HTTP/1.1
> Host: www.bortzmeyer.org
> User-Agent: curl/7.62.0-20180927
> Accept: */*
> 

Pour les programmeurs Go, l'excellente bibliothèque godns n'a hélas pas DoH (pour des raisons internes). Du code expérimental avait été écrit dans une branche mais a été abandonné. Les amateurs de Go peuvent essayer à la place cette mise en œuvre (on notera que ce client sait parler DoH mais aussi le protocole spécifique et non-standard du résolveur public Google Public DNS).

Pour les programmeurs C, la référence est la bibliothèque getdns (notez que c'est elle qui a été utilisée pour le client doh-nghttp cité plus haut). Le code DoH est, à la parution du RFC, toujours en cours de développement et pas encore dans un dépôt public. Une fois que cela sera fait, stubby, qui utilise getdns, pourra parler DoH.

Voilà, si vous n'êtes pas épuisé·e·s, il y a encore des choses à lire :


Téléchargez le RFC 8484


L'article seul

Les générateurs de site Web statiques, et mon choix de Pelican

Première rédaction de cet article le 19 octobre 2018


J'ai récemment dû faire deux sites Web et leur cahier des charges permettait de faire des sites Web statiques, ce qui a de nombreux avantages. Parmi les dizaines de logiciels qui permettent de faire un site Web statique, j'ai choisi Pelican.

Un de ces deux sites (l'autre est privé) est celui de mon livre.

Pourquoi un site Web statique, et non pas généré à la demande via un CMS ? Cela présente plusieurs avantages :

  • Le principal est de performance et de résistance à la charge : un site Web dépendant d'un CMS doit exécuter des milliers de lignes de PHP ou de Java à chaque requête. Cela le rend lent et, surtout, une attaque par déni de service, même modérée (par exemple avec un outil primitif comme LOIC) suffit à le rendre inutilisable. Même pas besoin d'attaque, d'ailleurs, parfois, une simple utilisation un peu intense (une mention sur Mastodon, par exemple) peut le rendre inaccessible. Un site Web dynamique doit donc être hébergé sur de grosses machines coûteuses, alors qu'un site statique peut tenir une charge bien plus élevée. Tous les serveurs HTTP savent servir des fichiers statiques très rapidement.
  • Un deuxième avantage est de dépendance. Le site statique ne dépend que du serveur HTTP. Au contraire, un site dynamique dépend de plusieurs logiciels supplémentaires (comme par exemple MariaDB) dont la panne peut le rendre inutilisable, souvent avec des messages d'erreur incompréhensibles.
  • Enfin, le site statique présente un gros avantage de sécurité : au contraire du site dynamique, qui peut souvent être piraté, par exemple par injection SQL, le site statique n'exécutant pas de code et étant composé de simples fichiers de données, n'a pas de failles de sécurité, autres que celles du serveur HTTP et de la machine sous-jacente.

Bref, pas question d'utiliser WordPress ou Drupal. Mais, alors, comment faire ? Une solution évidente est de tout faire à la main, éditant le HTML du site avec un éditeur texte ordinaire. Cette solution n'est pas forcément agréable. Éditer du HTML n'est pas très amusant (même si, au début du Web, tout le monde faisait comme cela car il n'y avait pas le choix), et surtout, cela rend très difficile le maintien d'une apparence cohérente entre toutes les pages du site. Bien sûr, l'utilisation d'un fichier CSS identique pour toutes les pages fera que des questions esthétiques comme la couleur du fond ou comme la police utilisée seront traitées de manière identique pour toutes les pages. Mais cela ne règle pas le cas d'éléments qu'on veut voir partout, et que CSS ne sait pas gérer, ou en tout cas pas facilement avec les navigateurs actuels. Par exemple, si on veut un pied de page identique partout, avec une adresse du webmestre et un menu, faire les pages à la main nécessiterait du copier/coller pénible et, surtout, rendrait difficile toute modification ultérieure de ce pied de page.

Une solution possible serait d'utiliser un CMS pour créer du contenu, ce qui permettrait aux utilisateurs attachés à ces outils de rédiger du contenu, puis de transformer le site Web dynamique en statique, avec un outil comme httrack, et de faire servir ensuite le contenu statique. Mais, ici, comme j'étais le seul à ajouter du contenu, le problème d'utilisation d'un éditeur ne se posait pas, je suis plus à l'aise avec un éditeur de texte qu'avec les éditeurs des CMS.

Les générateurs de site Web statiques utilisent tous le concept de gabarit. On écrit un gabarit que doivent respecter les pages, puis on écrit les pages et le générateur de site Web statique réalise l'incarnation de ces pages en fichiers HTML qui suivent le gabarit. De tels outils sont presque aussi anciens que le Web. Le premier que j'ai utilisé était wml, puis Blosxom a été le plus à la mode, puis Jekyll. Et il en existe aujourd'hui une quantité étonnante, beaucoup de programmeurs ayant apparemment eu envie d'écrire le leur. Pour en choisir un, mon cahier des charges était logiciel libre, et disponible sous forme d'un paquetage dans la version stable de Debian (car je souhaitais réaliser des sites Web, pas passer du temps à de l'administration système et de l'installation de logiciels).

Voyons maintenant les différents générateurs de sites Web statiques que j'ai testé, en commençant par celui que j'ai finalement choisi, Pelican. Pelican est écrit en Python (cela peut avoir son importance si vous souhaitez en étendre les fonctions, et même le fichier de configuration d'un site est en Python). Il est surtout prévu pour des blogs, avec une notion de chronologie, alors que mon utilisation est différente, juste un ensemble de pages. La plupart de ces générateurs de sites statiques sont, comme Pelican, plutôt orientés vers le blog.

Une fois installé (paquetage Debian pelican), on crée un répertoire pour les fichiers de son site, on se rend dans ce répertoire, et on lance la commande pelican-quickstart qui va interactivement vous guider et générer les fichiers nécessaires. Comme toutes les commandes interactives, c'est pénible à utiliser mais cela peut être utile aux débutants. La plupart des questions sont simples et la valeur par défaut est raisonnable, sauf pour les dernières, où pelican-quickstart vous demande comment installer les pages produites sur votre site Web. Il propose FTP, SSH, et des commandes spécifiques pour des environnements fermés chez des GAFA comme Dropbox ou S3. Personnellement, je n'aime pas que la réponse à la question « Do you want to specify a URL prefix? » soit Oui par défaut. Dans ce cas, Pelican définit une variable SITEURL dans la configuration et tous les liens sont préfixés par cet URL, ce qui empêche de tester le site en local, un comble pour un générateur de sites statiques. Je réponds donc Non à cette question (ou bien je mets RELATIVE_URLS à True dans publishconf.py).

Ensuite, nous pouvons rédiger le premier article. Pelican accepte des articles faits en Markdown et reST. Ici, j'utilise Markdown. J'édite un premier article content/bidon.md, et j'y mets :

Title: C'est trop tôt
Date: 2018-10-11

Test *bidon*, vraiment.
    

Les deux premières lignes sont des métadonnées spécifiques à Pelican. Il faut indiquer le titre de l'article et la date (rappelez-vous que Pelican est optimisé pour des blogs, où les articles sont classés par ordre rétro-chronologique). Si, comme moi, vous faites un site Web qui n'est pas un blog, la date n'est pas nécessaire (les détails suivent). Ensuite, pelican-quickstart ayant créé le Makefile qui va bien, un simple make publish suffit à fabriquer les fichiers HTML, dans le répertoire ./output. On peut alors pointer son navigateur Web favori vers output/index.html. (pelican content donne le même résultat que make publish. Tapez make sans argument pour voir la liste des possibilités.) Pour copier les fichiers vers la destination, si vous avez configuré un des mécanismes de téléversement, vous pouvez faire make XXX_upload, où XXX est votre méthode de téléversement. Par exemple, si vous avez configuré SSH, ce sera make ssh_upload (mais vous pouvez évidemment éditer le Makefile pour donner un autre nom).

Si vous voulez changer la configuration du site après, les fichiers de configuration sont eux-même écrits en Python, donc il est utile de connaitre un peu ce langage pour éditer pelicanconf.py et publishconf.py. Par exemple, si vous voulez que les dates soient affichées en français, avoir répondu fr aux questions de pelican-quickstart ne suffit pas, il faut ajouter LOCALE = ('fr_FR', 'fr') à pelicanconf.py.

En mode blog, Pelican met chaque article dans une catégorie, indiquée dans les métadonnées (si vous ne mettez rien, comme dans l'exemple de fichier Markdown plus haut, c'est mis dans la catégorie « misc »).

Je l'avais dit, les deux sites Web où j'utilise Pelican ne sont pas de type blog, mais plutôt des sites classiques, avec un ensemble de pages, sans notion d'ordre chronologique. Pour cela, il faut mettre ces pages (Pelican appelle les fichiers d'un blog chronologique « articles » et les autres fichiers, par exemple les mentions légales, des « pages ») dans un répertoire content/pages, et dire à Pelican sous quel nom enregistrer l'HTML produit, sinon, ses choix peuvent être différents de ce qu'on aurait choisi (mais on n'a plus à mettre la date) :

% mkdir content/pages
% emacs content/pages/mentions-legales.md
% make publish
Done: Processed 3 articles, 0 drafts, 1 page and 0 hidden pages in 0.12 seconds.
    

Vous voyez que vous avez maintenant « 1 page », en plus des articles. Ces pages apparaitront en haut de la page d'accueil (tout ceci peut évidemment se changer, voyez plus loin quand on parlera des thèmes).

Pour avoir les pages enregistrées sous un nom de fichier de son choix, on utilise save_as :

% cat content/pages/mentions-legales.md
Title: Mentions légales
save_as: legal.html

Faites ce que vous voulez avec ce site.
    

(Voir la bonne FAQ sur ce sujet.) Évidemment, dans ce cas, le menu automatique ne marchera plus et il faudra, dans le thème qu'on développe, mettre son menu à soi. Mais je n'ai pas encore expliqué les thèmes. Avant cela, notons qu'on peut redéfinir la page d'accueil de la même façon, avec save_as: index.html.

Alors, les thèmes, c'est quoi ? C'est un ensemble de gabarits HTML, de fichiers CSS et d'images qui, ensemble, vont assurer la cohérence du site Web, ses menus, son apparence graphique. Si vous avez fait votre propre site en suivant les instructions ci-dessus, vous avez utilisé le thème par défaut, qui se nomme « simple » et qui est livré avec Pelican. C'est lui qui définit par exemple le pied de page « Proudly powered by Pelican, which takes great advantage of Python ». S'il ne vous plait pas, vous pouvez avoir votre propre thème, soit en l'écrivant en partant de zéro (c'est bien documenté) soit en utilisant un thème existant (on en trouve en ligne, par exemple en http://pelicanthemes.com/). Et, bien sûr, vous pouvez aussi prendre un thème existant et le modifier. Comme exemple, je vais faire un thème ultra-simple en partant de zéro.

Appelons-le « red » :

% mkdir -p themes/red
% mkdir -p themes/red/static/css
% mkdir -p themes/red/templates
% emacs themes/red/templates/base.html
% emacs themes/red/templates/page.html
% emacs themes/red/templates/article.html
      

Le code de base.html est disponible dans ce fichier, celui de page.html dans celui-ci et enfin celui de article.html à cet endroit. base.html définit les éléments communs aux articles et aux pages. Ainsi, il contient <footer>Mon joli site.</footer>, qui spécifie le pied qu'on trouvera dans tous les fichiers HTML.

Pelican permet également d'utiliser des variables et des tests, avec le moteur de gabarit Jinja. C'est ainsi qu'on spécifie le titre d'un article : {{ SITENAME }} - {{ article.title }} indique que le titre comprend d'abord le nom du site Web, puis un tiret, puis la variable article.titre, obtenue via la métadonnée Title: mise plus haut dans le source Markdown.

Une fois le thème créé, on peut l'utiliser en le spécifiant sur la ligne de commande :

% pelican -t themes/red content

Ou bien si on veut utiliser make publish comme avant, on ajoute juste dans pelicanconf.py :

    
THEME = 'themes/red'

Notez qu'on n'est pas obligé de mettre le thème dans un sous-dossier de themes. Si on ne compte pas changer de thème de temps en temps, on peut aussi placer static et templates dans le dossier themes, voire directement à la racine du répertoire de développement.

On a rarement un thème qui marche du premier coup, il y a plusieurs essais, donc un truc utile est la commande make regenerate, qui tourne en permanence, surveille les fichiers, et regénère automatiquement et immédiatement les fichiers HTML en cas de changement. Une autre commande utile est make serve qui lance un serveur Web servant le contenu créé, le site étant désormais accessible en http://localhost:8000/ (personnellement, x-www-browser output/index.html me suffit).

Si les fonctions de base ne suffisent pas, Pelican peut ensuite être étendu de plusieurs façons différentes. Notez d'abord que Jinja fournit beaucoup de possibilités (cf. sa documentation). Ensuite, imaginons par exemple qu'on veuille inclure des données CSV dans ses articles ou pages. On peut écrire un plugin (c'est bien documenté) mais il existe aussi plein de plugins tout faits, n'hésitez pas à chercher d'abord si l'un d'eux vous convient (ici, peut-être Load CSV). Mais on peut aussi envisager un programme dans le langage de son choix, qui lise le CSV et produise le Markdown. Ou bien, puisque les fichiers de configuration sont du Python, on peut y mettre du code Python, produisant des variables qu'on utilisera ensuite dans son thème (notez qu'on peut définir ses propres métadonnées).

Dernière solution, étendre Markdown avec une extension au paquetage Python markdown, qu'utilise Pelican. Ces extensions sont bien documentées, et il existe un tutoriel. On peut alors programmer dans l'extension tout ce qu'on veut, et produire le HTML résultant, avec Element Tree. C'est personnellement ce que j'utilise le plus souvent.

Pour terminer avec Pelican, quelques bonnes lectures :

Voici pour Pelican. Et les autres générateurs de sites statiques, du moins les quelques-uns que j'ai testés, parmi la grande variété disponible ? Actuellement, Hugo semble le plus à la mode. Il est programmé en Go. Comme Pelican, il est très nettement orienté vers la réalisation de blogs chronologiques. Le paquetage Debian est très ancien par rapport à la syntaxe toujours changeante, et je n'ai pas réussi à traiter un seul des thèmes existants, n'obtenant que des messages incompréhensibles. Je ne suis pas allé plus loin, je ne sais notamment pas si Hugo peut être utilisé pour des sites qui sont des ensembles de pages plutôt que des blogs.

Au contraire d'Hugo, tout beau et tout neuf, Jekyll est stable et fait du bon travail. Un coup de jekyll build et on a son site dans le répertoire _site. On peut aussi faire un site non-blog. Jekyll est lui, écrit en Ruby. Par contre, je n'ai pas bien compris comment on créait son thème, et c'est une des raisons pour lesquelles j'ai choisi Pelican.

Au contraire de Jekyll, Gutenberg est récent, et développé dans un langage récent, Rust. Trop nouveau pour moi, il nécessite le gestionnaire de paquetages Cargo qui n'existe apparemment pas sur Debian stable.

Écrit dans un langage bien moins commun, Hakyll est en Haskell, et même le fichier de configuration est un programme Haskell. Mais il est inutilisable sur Debian stable, en raison d'une bogue qui affiche un message très clair :

AesonException "Error in $.packages.cassava.constraints.flags: failed
to parse field packages: failed to parse field constraints: failed to
parse field flags: Invalid flag name: \"bytestring--lt-0_10_4\""

Enfin, j'ai regardé du côté de PyBlosxom mais j'ai renoncé, trouvant la documentation peu claire pour moi.

Les solutions les plus simples étant souvent les meilleures, il faut se rappeler qu'on peut tout simplement faire un site statique avec pandoc. pandoc prend des fichiers Markdown (et bien d'autres formats) et un coup de pandoc --standalone --to html5 -o index.html index.md (qu'on peut automatiser avec make) produit de l'HTML. Si on veut donner une apparence cohérente à ses pages Web, pandoc a égakement un système de gabarits (mais, la plupart du temps, il n'est même pas nécessaire, utiliser le gabarit par défaut et définir quelques variables sur la ligne de commande de pandoc peut suffire).

Comme je l'ai dit au début, il y a vraiment beaucoup de générateurs de sites statiques et je suis très loin de les avoir tous testés. Rien que dans les paquetages Debian, il y a encore staticsite et blogofile.

Vu le grand nombre de générateurs de sites Web statiques, on ne s'étonne pas qu'il existe plusieurs articles de comparaison :

Et, évidemment, il existe toujours la solution bien geek consistant à développer son propre outil, comme je l'avais fait pour ce blog.


L'article seul

Fiche de lecture : Click here to kill everybody

Auteur(s) du livre : Bruce Schneier
Éditeur : Norton
978-0393-60888-5
Publié en 2018
Première rédaction de cet article le 6 octobre 2018


D'accord, le titre est vraiment putaclic mais il résume bien le livre. Bruce Schneier se pose la question de la sécurité de l'Internet des Objets, faisant notamment remarquer que le conséquences d'une panne ou d'une attaque changent. Contrairement à la sécurité informatique classique, avec l'Internet des Objets, il peut y avoir des conséquences dans le monde physique, y compris des conséquences mortelles.

Schneier est l'auteur de nombreux livres sur la sécurité (pas forcément uniquement la sécurité informatique). Il explique toujours bien et synthétise avec talent les questions de sécurité. C'est d'autant plus méritoire que la sécurité est un sujet hautement politisé, où il est difficile de parler sérieusement. Pensons par exemple aux mesures adoptées pour lutter contre l'ennemi djihadiste. Dès qu'on fait entendre un point de vue critique, ou simplement nuancé, on se fait accuser d'être « trop mou face au terrorisme » voire « complice des terroristes ». Schneier appelle au contraire à envisager la sécurité comme un sujet sérieux, et donc à s'abstenir de ce genre d'accusations tranchantes. Dans ses livres (comme « Beyond Fear ») et sur son blog, il remet sans cesse en cause les certitudes, critique le « show sécuritaire », demande qu'on évalue les mesures de sécurité, leur efficacité et leur coût, au lieu de simplement dire « il faut faire quelque chose, peu importe quoi ».

Le sujet de ce livre (plutôt un essai relativement court) est l'Internet des Objets. C'est un terme marketing, flou et mal défini. Schneier lui préfère celui d'« Internet+ », dont il reconnait qu'il n'est pas meilleur mais qu'il a l'avantage de forcer à reconsidérer de quoi on parle. En gros, il y a aujourd'hui énormément d'« objets » connectés à l'Internet. Ils ont en commun d'être des ordinateurs, mais de ne pas être perçus comme tels. Ce sont des ordinateurs, car ils en ont le matériel et surtout le logiciel, avec ses bogues et ses failles de sécurité. (Pour paraphraser l'auteur, « Un grille-pain moderne est un ordinateur avec des résistances chauffantes en plus ».) Mais ils ne sont pas perçus comme tels, donc le logiciel ne fait l'objet d'aucune analyse de sécurité, le problème de la mise à jour n'est pas envisagé, et les sociétés qui produisent ces objets n'ont aucune culture de sécurité, et refont en 2018 les erreurs que l'industrie informatique faisait il y a 20 ans (mots de passe par défaut, menaces judiciaires contre ceux qui signalent des failles de sécurité, tentative d'empêcher la rétro-ingénierie, affirmations grotesques du genre « notre système est parfaitement sécurisé »). La sécurité des objets connectés, de l'« Internet+ » est donc abyssalement basse. À chaque conférence de sécurité, on a de nombreux exposés montrant la facilité avec laquelle ces objets peuvent être piratés. Schneier cite une classe de politique du monde numérique où, au cours d'un travail pratique, la moitié des étudiants ont réussi à pirater une poupée connectée, alors même qu'ils et elles sont des juristes ou des étudiants en sciences politiques, pas des pentesteurs.

Tant que l'object connecté est une brosse à dents, et que le piratage a pour seule conséquence d'empêcher cette brosse de fonctionner, ce n'est pas trop grave. Mais beaucoup d'objets ont des capacités bien plus étendues, et qui touchent le monde physique (d'où le titre sensationnaliste du livre). Si l'objet est une voiture, ou un dispositif de sécurité d'une usine, ou un appareil électrique potentiellement dangereux, les conséquences peuvent être bien plus graves. On est loin des problèmes de sécurité de WordPress, où la seule conséquence en cas de piratage est l'affichage d'un message moqueur sur la page d'accueil du site Web !

(Je rajoute, à titre personnel - ce n'est pas dans le livre, qu'il est scandaleux que, pour beaucoup d'objets, l'acheteur n'ait plus le choix. Aujourd'hui, acheter une télévision ou une voiture qui ne soit pas connectée, est devenu difficile, et demain, ce sera impossible. Un changement aussi crucial dans nos vies a été décidé sans que le citoyen ait eu son mot à dire.)

Schneier explique en détail les raisons techniques, pratiques et financières derrière l'insécurité informatique mais il note que cette insécurité ne déplait pas à tout le monde. Des services étatiques comme la NSA (dont la mission est justement de pirater des systèmes informatiques) aux entreprises qui gagnent de l'argent en exploitant des données personnelles, des tas d'organisations profitent de cette insécurité, ce qui est une des raisons pour laquelle elle ne se réduit guère. (Pour la NSA, Schneier préconise de la séparer en deux organisations radicalement distinctes, une chargée de l'attaque et une de la défense. Actuellement, la NSA est censée faire les deux, et, en pratique, l'attaque est toujours jugée plus importante. Cela amène la NSA, par exemple, à ne pas transmettre aux auteurs de logiciels les failles de sécurité détectées, de façon à pouvoir les exploiter. Le système français a aussi ses défauts mais, au moins, l'attaque - armée et DGSE - et la défense - ANSSI - sont clairement séparées, et la défense ne dépend pas de l'armée ou de la police, qui sont intéressées à conserver l'insécurité informatique.)

Notez que le livre est clairement écrit d'un point de vue états-unien et parle surtout de la situation dans ce pays.

Et les solutions ? Parce que ce n'est pas tout de faire peur aux gens, avec des scénarios qui semblent sortis tout droit des séries télé « Black Mirror » ou « Mr Robot ». Il faut chercher des solutions. L'auteur expose successivement le quoi, le comment et le qui. Le quoi, c'est le paysage que nous voudrions voir émerger, celui d'un « Internet+ » dont la sécurité ne soit pas risible, comme elle l'est actuellement. Les solutions ne vont pas de soi, car elles auront forcément un coût, et pas uniquement en argent, mais aussi en facilité d'usage et en générativité (pour reprendre le terme de Jonathan Zittrain, qui désigne ainsi la capacité d'une technique à faire des choses non prévues par ses concepteurs). Un exemple d'un choix difficile : le logiciel de l'objet doit-il être mis à jour automatiquement et à distance ? Du point de vue de la sécurité, c'est clairement oui, mais cela ouvre des tas de problèmes, comme la possibilité pour le vendeur de garder un contrôle sur l'objet vendu (cf. RFC 8240 pour les détails). Autre point qui sera difficile à avaler (et l'auteur n'en parle d'ailleurs que très peu) : il ne faudra pas tout connecter. Connecter des frigos et des télés à l'Internet est peut-être pratique et sexy mais c'est dangereusement irresponsable.

Le comment, ce sont les moyens d'y arriver. Et le qui, c'est la question brûlante de savoir quelle organisation va devoir agir.

Schneier ne croit pas au marché, qui a largement démontré son incapacité à résoudre les problèmes de sécurité. Cela semble une évidence mais il ne faut pas oublier que Schneier écrit pour un public états-unien, pour qui le marché est sacré, et toute suggestion comme quoi le marché n'est pas parfait est vite assimilée au communisme. Bruce Schneier suggère donc un rôle essentiel pour l'État, une position courageuse quand on écrit aux États-Unis. Il ne se fait pas d'illusions sur l'État (il décrit plusieurs cas où l'État, ses lois, ses règles et ses pratiques ont contribué à aggraver le problème, comme par exemple la loi DMCA) mais il ne voit pas d'autre option réaliste, en tout cas certainement pas l'« auto-régulation » (autrement dit le laisser-faire) chère à la Silicon Valley.

Bruce Schneier est bien conscient qu'il n'y a pas de solution idéale, et que la sécurisation de l'Internet+ sera douloureuse. Si vous lisez ce livre, ce que je vous recommande fortement, vous ne serez certainement pas d'accord avec tout, comme moi. (Par exemple, la proposition de faire du FAI le responsable de la sécurité des réseaux des utilisateurs à la maison m'inquiète. Et sa suggestion d'ajouter encore des règles et des processus, alors qu'au contraire cela sert en général à encourager l'irresponsabilité n'est pas idéale non plus.) Mais ne nous faisons pas d'illusion : on n'aura pas de solution parfaite. Et, si nous ne faisons rien, nous aurons peut-être des « solutions » catastrophiques, par exemple des règles ultra-liberticides imposées en mode panique par des politiciens affolés, après une grosse crise due à un objet connecté.

Vous serez peut-être également intéressé·e par cet exposé de l'auteur au sujet de ce livre.


L'article seul

Conférence « Web et vie privée » au Centre Social des Abeilles

Première rédaction de cet article le 30 septembre 2018


Le 28 septembre, au Centre Social des Abeilles à Quimper, j'ai participé à un apéro/discussion sur le thème « Web et vie privée ». Je faisais l'introduction à la discussion

Voici les supports de cette introduction :

La vidéo est en ligne. La longue discussion qui a suivi ne l'est pas, pour respecter la vie privée des participants. (Une autre copie de la vidéo est sur le site original.)

Merci à Brigitte pour l'idée et l'organisation, à Salim pour l'accueil, à René pour la vidéo et à tou·te·s les participant·e·s, nombreu·x·ses et acti·f·ve·s. Un compte-rendu de cet apéro-discussion, avec plans pour le futur a été écrit par Brigitte. (Il y a aussi mon interview à France Bleu mais le titre choisi par la rédaction est trompeuse.)


L'article seul

[DNS] CNAME à l'apex d'une zone, pourquoi et comment ?

Première rédaction de cet article le 23 septembre 2018


Un problème courant que rencontrent les techniciens débutant en DNS est « je voudrais mettre un enregistrement CNAME - un alias - à l'apex de ma zone DNS mais l'ordinateur ne veut pas ». Pourquoi est-ce refusé ? Comment l'autoriser sans casser tout l'Internet ? La discussion dure depuis de nombreuses années et, je vous révèle tout de suite la conclusion de cet article, n'est pas près de se terminer.

Commençons par une description concrète du problème. Alice, technicienne DNS, a été informée par le webmestre de sa boîte (nommée Michu SA et ayant le nom de domaine michu.example) que le serveur Web de ladite boîte est désormais hébergé par un CDN nommé Example et qu'il est accessible par le nom michu-sa.example-cdn.net. Et le webmestre voudrait que les visiteurs puissent juste taper https://michu.example/. Alice connait assez le DNS pour savoir qu'il y a des alias (un type d'enregistrement nommé CNAME) et elle met donc dans le fichier de zone :

michu.example. IN CNAME michu-sa.example-cdn.net.
    

Ça devrait contenter tout le monde, pense-t-elle. Mais, si elle connait assez le DNS pour savoir que le type d'enregistrement CNAME existe, elle ne le connait pas assez pour avoir lu le RFC 1034, section 3.6.2 : If a CNAME RR is present at a node [a node in the domain name tree, so a domain name], no other data should be present. Et c'est le drame, au chargement de la zone, NSD dit error: /etc/nsd/michu.example:19: CNAME and other data at the same name. Si Alice avait utilisé BIND, elle aurait eu une erreur similaire : dns_master_load: michu.example:19: michu.example: CNAME and other data. L'enregistrement CNAME rentre en conflit avec les enregistrements qu'on trouve à l'apex d'une zone, comme le SOA et les NS. La solution simple ne marche donc pas.

www.michu.example. IN CNAME michu-sa.example-cdn.net.      
    

aurait marché mais le service communication voudrait un URL sans www devant.

Au passage, pourquoi est-ce que c'est interdit de mettre un alias et d'autres données au même nom ? La principale raison est qu'un enregistrement CNAME est censé créer un alias, un synonyme. Si on pouvait écrire :

michu.example. IN AAAA 2001:db8::ff
michu.example. IN CNAME michu-sa.example-cdn.net.      
    

Et qu'un client DNS demande l'enregistrement de type AAAA pour michu.example, que faudrait-il lui répondre ? 2001:db8::ff, ou bien l'adresse IPv6 de michu-sa.example-cdn.net ? Avec l'interdiction de coexistence du CNAME et d'autres données, le problème est réglé.

Bon, se dit Alice, ça ne marche pas, mais on peut essayer autrement : cherchons l'adresse IP correspondant au nom michu-sa.example-cdn.net et mettons-là dans le fichier de zone :

% dig +short AAAA michu-sa.example-cdn.net
2001:db8:1000:21::21:4
    
michu.example. IN AAAA 2001:db8:1000:21::21:4 
    

Cette fois, ça marche, mais il y a plusieurs inconvénients :

  • Le principal est que le CDN peut changer l'adresse IP à tout moment, sans prévenir. Au minimum, il faudra donc retester l'adresse, et changer la zone. À la main, aucune chance que ce soit fait assez souvent (il faut respecter le TTL du CDN). Il faudra donc l'automatiser.
  • Des CDN renvoient une adresse IP différente selon l'adresse IP source du client DNS, afin de diriger vers un serveur « proche ». L'astuce d'Alice casse ce service.

Bref, que faire ? Plusieurs sociétés ont développé une solution non-standard ne marchant que chez eux. L'IETF, dont c'est le rôle de développer des solutions standards, s'est penchée à de nombreuses reprises sur la question, et d'innombrables brouillons ont été produits, sans qu'un consensus ne se dégage. Déjà, il n'y a pas d'accord clair sur le cahier des charges. (Le scénario d'usage présenté plus haut n'est qu'un des scénarios possibles.) Je ne vais pas présenter tous ces brouillons, juste dégager les pistes de solution. Mais, comme vous le verrez, aucune n'est parfaite. Une des contraintes fortes est qu'on sait bien que, quelle que soit la décision prise par l'IETF, le nouveau logiciel, mettant en œuvre la décision, ne sera pas déployé immédiatement : il faudra des années, voire davantage, pour qu'une part significative des clients et serveurs DNS soient à jour. Il faudra donc, non seulement modifier les règles du DNS, mais également spécifier ce qu'il faudra faire pendant la très longue période de transition. (Et, s'il vous plait, pas de yakafokon du genre « les gens n'ont qu'à mettre à jour leur logiciel plus souvent ». Cela n'arrivera pas.)

Voici maintenant les diverses pistes envisagées. Avant de dire « ah, celle-ci a l'air cool », prudence. Rappelez-vous qu'il existe de nombreux cas (minimisation de la requête - RFC 7816 - ou pas, résolveur chaud - ayant déjà des informations dans sa mémoire - ou pas), et que la période de transition va être très longue, période pendant laquelle il faut que cela marche pour les anciens et pour les modernes.

Première idée, décider qu'il n'y a pas de problème. On laisse le DNS comme il est et le problème doit être entièrement traité côté avitaillement (le type qui édite le fichier de zone, ou bien le logiciel qui le produit). C'est l'idée de base du hack utilisé par Alice plus haut. Cela peut se faire avec un script shell du genre :

#!/bin/sh

zonefile=$1

while :
do
    target=$(awk '/ALIAS/ {print $3}'  $zonefile)
    ttl=$(dig A $target | awk "/^$target.*IN\s+A/ {print \$2}" | head -n 1)
    ip=$(dig A $target | awk "/^$target.*IN\s+A/ {print \$5}" | head -n 1)
    sed "s/IN.*ALIAS.*/  IN $ttl   A  $ip/" $zonefile > ${zonefile}-patched
    echo "Patched with IP address $ip"
    sleep $ttl
done
   

(En production, on voudra probablement quelque chose de plus propre, notamment en gestion d'erreurs, et de traitement des réponses multiples.)

Comme indiqué plus haut, cela marche, mais cela ne permet pas de tirer profit des caractéristiques du CDN, par exemple de la réponse différente selon le client. On peut voir cette variation de la réponse, en demandant à cent sondes RIPE Atlas :

% blaeu-resolve --requested 100 --type A www.elysee.fr                    
[208.178.167.254 4.26.226.126 4.27.28.126 8.27.4.254] : 1 occurrences 
[8.254.28.126 8.254.45.254 8.27.151.253 8.27.226.126] : 1 occurrences 
[205.128.73.126 206.33.35.125 209.84.20.126 8.27.243.253] : 1 occurrences 
[207.123.56.252 4.26.228.254 4.27.28.126 8.26.223.254] : 1 occurrences 
[205.128.90.126 209.84.9.126 8.254.214.254 8.254.94.254] : 1 occurrences 
[8.254.164.126 8.254.209.126 8.254.210.126 8.27.9.254] : 1 occurrences 
[4.23.62.126 4.26.227.126 8.254.173.254 8.254.95.126] : 1 occurrences 
[207.123.39.254 8.254.196.126 8.254.219.254 8.27.5.254] : 2 occurrences 
[120.28.42.254 36.66.10.126] : 1 occurrences 
...
   

Deuxième idée, relâcher la contrainte donnée dans le RFC 1034 et autoriser le CNAME à l'apex (note au passage : beaucoup de gens sont nuls en arbrologie et appellent incorrectement l'apex la racine, ce qui a un tout autre sens dans le DNS). L'expérience a été tentée par Ondřej Surý au hackathon de l'IETF à Montréal en juillet 2018 (les résultats complets de l'équipe DNS sont dans cette présentation). Une fois le serveur faisant autorité modifié pour autoriser le CNAME à l'apex, on l'interroge via un résolveur. En gros, dans la plupart des cas, le CNAME masque les autres enregistrements (ce qui est logique puisqu'il est censé être seul). Ainsi, si on a :

michu.example.     IN  CNAME   foobar.example.com.
                   IN  MX  10    gimmedata.gafa.example.
   

Un client DNS qui demande le MX de michu.example pour lui envoyer du courrier récupérera le MX de foobar.example.com, le vrai MX étant masqué.

Plus ennuyeux est le fait que cela dépend : dans certains cas, un autre enregistrement que celui du CNAME est récupéré. On ne peut rien reprocher aux logiciels qui font cela : ils sont conformes aux RFC actuels. Cette variabilité rend difficile de simplement autoriser le CNAME à l'apex.

Troisième possibilité : on peut aussi décider que le résolveur fera l'essentiel du boulot. On crée un nouveau type d'enregistrement, mettons SEEALSO, qui peut coexister avec les types existants :

michu.example.   IN SEEALSO  michu-sa.example-cdn.net.          
michu.example.   IN MX 10 gimmedata.gafa.example.
   

Le serveur faisant autorité n'aurait rien de particulier à faire, il renvoie juste le SEEALSO au résolveur (en terminologie DNS, on dit « il n'y a pas de traitement additionnel »). Le résolveur va alors, recevant le SEEALSO, le suivre. Le principal problème de cette approche est qu'initialement, peu de résolveurs auront le nouveau code, ce qui ne motivera pas les gens qui gèrent les zones à ajouter ce SEEALSO.

Quatrième idée, toujours avec un nouveau type d'enregistrement (et donc avec les problèmes de déploiement que cela pose dans un Internet non centralisé), généralement appelé ANAME ou ALIAS. L'idée est qu'on mettra dans la zone :

michu.example.   IN ANAME  michu-sa.example-cdn.net.          
michu.example.   IN MX 10 gimmedata.gafa.example.
   

Le ANAME, contrairement au CNAME, a le droit de coexister avec d'autres enregistrements, ici un MX. L'idée est que le serveur faisant autorité, chargeant la zone, va résoudre la cible (la partie droite du ANAME) et répondre avec l'adresse IP de la cible lorsqu'on l'interrogera. Le résolveur ne voit donc pas le CDN, si l'adresse au CDN est 2001:db8::ff, le résolveur recevra :

michu.example.   3600 IN AAAA 2001:db8::ff   
   

Le serveur faisant autorité, ayant chargé la zone, sera responsable de changer cette valeur lorsque le TTL expirera.

On voit que cette solution nécessite que le serveur faisant autorité soit également résolveur. C'est considéré comme une mauvaise pratique, car cela complique sérieusement le déboguage : on ne sait plus d'où viennent les données, et celles du résolveur peuvent potentiellement masquer celles qui font autorité. D'ailleurs, les meilleurs logiciels serveur faisant autorité, comme NSD, n'ont pas du tout de code pour faire de la résolution (cette simplicité améliore grandement la sécurité).

D'autre part, introduire un nouveau type de données DNS n'est jamais évident, cela nécessite de modifier les serveurs faisant autorité (les résolveurs, eux, n'ont pas besoin d'être modifiés, pour ce ANAME), mais également les logiciels d'avitaillement (interfaces web chez l'hébergeur DNS permettant de gérer sa zone).

Cette idée de ANAME pose également des problèmes à DNSSEC. Comme le serveur faisant autorité va devoir modifier le contenu de la zone fréquemment (les TTL des CDN sont souvent courts), il faudra qu'il signe les enregistrements créés, ce qui obligera à avoir la clé privée disponible (on préfère parfois la garder hors-ligne, pour des raisons de sécurité, ce qui est opérationnellement faisable si on ne modifie pas la zone trop souvent). Et cela nécessitera un serveur qui peut signer dynamiquement, ou bien des bricolages particuliers.

On peut avoir des tas de variantes sur cette idée. C'est d'ailleurs une des raisons pour laquelle le débat est compliqué. Chaque idée a des sous-idées. Par exemple, puisque dans ce cas, le serveur faisant autorité est également résolveur, on pourrait renvoyer le ANAME au client DNS, avec l'adresse IP du CDN, pour gagner du temps. La réponse serait :

;; ANSWER SECTION:
michu.example.   3600 IN ANAME michu-sa.example-cdn.net.          

;; ADDITIONAL SECTION:
michu-sa.example-cdn.net. 600 IN AAAA 2001:db8::ff   
   

Plus de problèmes avec DNSSEC cette fois, puisqu'on n'importerait plus de données extérieures dans la zone michu.example. Le principal problème de cette variante est que l'optimisation serait probablement inutile : un résolveur DNS raisonnablement paranoïaque, craignant une attaque par empoisonnement, ignorerait la section additionnelle, puisque le serveur interrogé ne fait autorité que pour michu.example, pas pour example-cdn.net. On serait donc ramené à la troisième idée (le résolveur fait tout).

Cinquième idée, résoudre le problème côté client, comme dans la troisième, mais en modifiant les applications et non plus les résolveurs. Après tout, le principal scénario d'usage est pour HTTP. Ce sont les gens du Web qui se plaignent de ne pas pouvoir mettre des CNAME à l'apex. Les gens de SMTP ou de XMPP ne se plaignent pas, car ils ont un système d'indirection. On indique dans le DNS le nom du serveur pour un domaine donné (enregistrement MX pour SMTP et les plus généraux enregistrements SRV pour XMPP). HTTP est hélas le seul protocole normalisé qui a « oublié » de faire une indirection entre domaine et serveur. C'est une de ses plus graves fautes de conception. (Un protocole comme SSH est un cas à part puisque son but est de se connecter à une machine spécifique.) Donc, la meilleure solution, du point de vue de l'architecture de l'Internet, est de modifier HTTP pour que les clients HTTP utilisent SRV. La zone serait alors :

michu.example.   IN SRV 0 1 80  michu-sa.example-cdn.net.          
; Autres types
michu.example.   IN MX 10 gimmedata.gafa.example.
   

SRV, normalisé dans le RFC 2782, a plein d'autres possibilités très pratiques, comme d'indiquer plusieurs serveurs, avec des poids différents (fournissant ainsi un système non centralisé de répartition de charge) et des priorités différentes (les serveurs de faible priorité n'étant sollicité qu'en cas de panne des autres).

Tout cela pose évidemment un réel problème de déploiement puisqu'il faudrait modifier tous les clients HTTP (rappelez-vous qu'il n'y a pas que les navigateurs !) Tant qu'il n'y aura pas de déploiement significatif, les titulaires de noms de domaine devront avoir le SRV et les enregistrements classiques. D'autre part, HTTP ayant évolué sans les enregistrements SRV, il y a quelques points d'accrochage. Par exemple, SRV permet d'indiquer le port et cela peut rentrer en conflit avec le concept d'origine du Web, qui est essentiel pour sa sécurité (http://example.com/ et http://example.com:3000/ sont des origines différentes, cf. RFC 6454). Il y a aussi quelques pièges liés au SRV (voir mes notes à ce sujet et, cette discussion au sujet des SRV dans Mastodon.)

Et je n'ai pas cité toutes les idées, comme la possibilité d'utiliser Alt-Svc (RFC 7838).

Conclusion ? Le problème est bien sûr réel et se pose à beaucoup d'acteurs de l'Internet. Mais il n'y a pas de solution idéale. Il faudra, soit continuer comme actuellement si l'IETF n'arrive pas à un accord, soit adopter une solution qui, de toute façon, créera ses propres problèmes. Personnellement, je pense que la solution la plus propre serait de modifier HTTP, pour utiliser une indirection, comme tous les autres protocoles. Si cela n'est pas possible, il vaut encore mieux ne rien faire : le dromadaire est assez chargé comme cela.


L'article seul

Fiche de lecture : Le livre-échange

Auteur(s) du livre : Mariannig Le Béchec, Dominique Boullier, Maxime Crépel
Éditeur : C & F Éditions
978-2-915825-76-3
Publié en 2018
Première rédaction de cet article le 30 août 2018


Le livre, sous ses deux formes, papier ou numérique, est un objet de passion depuis longtemps. Ce ne sont pas juste des lettres qu'on lit. Les lecteurices ont des usages, des pratiques, ils et elles se prêtent les livres, les annotent, les commentent, les échangent, en parlent sur leur blog…

Ce livre est une étude de ces pratiques. Que font les lecteurs de leur livre ? Pour chaque pratique, des lecteurices sont interrogé·e·s, des experts commentent parfois. On ne parle pas du texte, uniquement des usages que les lecteurices font du livre.

Les usages du livre sur papier forment l'essentiel de cet ouvrage, qui note que le livre numérique fait apparemment peu l'objet de ces diverses formes d'échange. On le lit, mais c'est tout.

Les usages du livre papier sont très variés (sans compter, dirait le cynique, celui de caler les meubles). Et les avis des lecteurices sont également divers. L'annotation, par exemple, est sans doute le chapitre où les avis sont les plus tranchés, entre celles et ceux qui considèrent le livre comme « sacré », et qui ne se permettraient pas d'y ajouter la moindre marque, et ceux et celles qui griffonnent, corrigent, et ajoutent des commentaires au stylo rouge. Le livre n'est clairement pas un objet comme les autres. À propos de l'achat de livres d'occasion, une lectrice explique qu'elle n'y recourt pas, car elle lit au lit et qu'elle ne veut pas faire rentrer dans son lit, espace intime, des livres déjà manipulés par un inconnu…

En résumé, un bel hommage à l'abondance de pratiques sociales autour du livre.

Déclaration de conflit d'intérêt : j'ai reçu un exemplaire de ce livre gratuitement.


L'article seul

RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3

Date de publication du RFC : Août 2018
Auteur(s) du RFC : E. Rescorla (RTFM)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 11 août 2018


Après un très long processus, et d'innombrables polémiques, la nouvelle version du protocole de cryptographie TLS, la 1.3, est enfin publiée. Les changements sont nombreux et, à bien des égards, il s'agit d'un nouveau protocole (l'ancien était décrit dans le RFC 5246, que notre nouveau RFC remplace).

Vous pouvez voir l'histoire de ce RFC sur la Datatracker de l'IETF. Le premier brouillon a été publié en avril 2014, plus de trois années avant le RFC. C'est en partie pour des raisons techniques (TLS 1.3 est très différent de ses prédécesseurs) et en partie pour des raisons politiques. C'est que c'est important, la sécurité ! Cinq ans après les révélations de Snowden, on sait désormais que des acteurs puissants et sans scrupules, par exemple les États, espionnent massivement le trafic Internet. Il est donc crucial de protéger ce trafic, entre autres par la cryptographie. Mais dire « cryptographie » ne suffit pas ! Il existe des tas d'attaques contre les protocoles de cryptographie, et beaucoup ont réussi contre les prédécesseurs de TLS 1.3. Il était donc nécessaire de durcir le protocole TLS, pour le rendre moins vulnérable. Et c'est là que les ennuis ont commencé. Car tout le monde ne veut pas de la sécurité. Les États veulent continuer à espionner (le GCHQ britannique s'était clairement opposé à TLS 1.3 sur ce point). Les entreprises veulent espionner leurs employés (et ont pratiqué un lobbying intense contre TLS 1.3). Bref, derrière le désir de « sécurité », partagé par tout le monde, il y avait un désaccord de fond sur la surveillance. À chaque réunion de l'IETF, une proposition d'affaiblir TLS pour faciliter la surveillance apparaissait, à chaque fois, elle était rejetée et, tel le zombie des films d'horreur, elle réapparaissait, sous un nom et une forme différente, à la réunion suivante. Par exemple, à la réunion IETF de Prague en juillet 2017, l'affrontement a été particulièrement vif, alors que le groupe de travail TLS espérait avoir presque fini la version 1.3. Des gens se présentant comme enterprise networks ont critiqué les choix de TLS 1.3, notant qu'il rendait la surveillance plus difficile (c'était un peu le but…) gênant notamment leur déboguage. Ils réclamaient un retour aux algorithmes n'ayant pas de sécurité persistante. Le début a suivi le schéma classique à l'IETF : « vous réclamez un affaiblissement de la sécurité » vs. « mais si on ne le fait pas à l'IETF, d'autres le feront en moins bien », mais, au final, l'IETF est restée ferme et n'a pas accepté de compromissions sur la sécurité de TLS. (Un résumé du débat est dans « TLS 1.3 in enterprise networks ».)

Pour comprendre les détails de ces propositions et de ces rejets, il faut regarder un peu en détail le protocole TLS 1.3.

Revenons d'abord sur les fondamentaux : TLS est un mécanisme permettant aux applications client/serveur de communiquer au travers d'un réseau non sûr (par exemple l'Internet) tout en empêchant l'écoute et la modification des messages. TLS suppose un mécanisme sous-jacent pour acheminer les bits dans l'ordre, et sans perte. En général, ce mécanisme est TCP. Avec ce mécanisme de transport, et les techniques cryptographiques mises en œuvre par dessus, TLS garantit :

  • L'authentification du serveur (celle du client est facultative), authentification qui permet d'empêcher l'attaque de l'intermédiaire, et qui se fait en général via la cryptographie asymétrique,
  • La confidentialité des données (mais attention, TLS ne masque pas la taille des données, permettant certaines analyses de trafic),
  • L'intégrité des données (qui est inséparable de l'authentification : il ne servirait pas à grand'chose d'être sûr de l'identité de son correspondant, si les données pouvaient être modifiées en route).

Ces propriétés sont vraies même si l'attaquant contrôle complètement le réseau entre le client et le serveur (le modèle de menace est détaillé dans la section 3 - surtout la 3.3 - du RFC 3552, et dans l'annexe E de notre RFC).

TLS est un protocole gros et compliqué (ce qui n'est pas forcément optimum pour la sécurité). Le RFC fait 147 pages. Pour dompter cette complexité, TLS est séparé en deux composants :

  • Le protocole de salutation (handshake protocol), chargé d'organiser les échanges du début, qui permettent de choisir les paramètres de la session (c'est un des points délicats de TLS, et plusieurs failles de sécurité ont déjà été trouvées dans ce protocole pour les anciennes versions de TLS),
  • Et le protocole des enregistrements (record protocol), au plus bas niveau, chargé d'acheminer les données chiffrées.

Pour comprendre le rôle de ces deux protocoles, imaginons un protocole fictif simple, qui n'aurait qu'un seul algorithme de cryptographie symétrique, et qu'une seule clé, connue des deux parties (par exemple dans leur fichier de configuration). Avec un tel protocole, on pourrait se passer du protocole de salutation, et n'avoir qu'un protocole des enregistrements, indiquant comment encoder les données chiffrées. Le client et le serveur pourraient se mettre à communiquer immédiatement, sans salutation, poignée de mains et négociation, réduisant ainsi la latence. Un tel protocole serait très simple, donc sa sécurité serait bien plus facile à analyser, ce qui est une bonne chose. Mais il n'est pas du tout réaliste : changer la clé utilisée serait complexe (il faudrait synchroniser exactement les deux parties), remplacer l'algorithme si la cryptanalyse en venait à bout (comme c'est arrivé à RC4, cf. RFC 7465) créerait un nouveau protocole incompatible avec l'ancien, communiquer avec un serveur qu'on n'a jamais vu serait impossible (puisque on ne partagerait pas de clé commune), etc. D'où la nécessité du protocole de salutation, où les partenaires :

  • S'authentifient avec leur clé publique (ou, si on veut faire comme dans le protocole fictif simple, avec une clé secrète partagée),
  • Sélectionnent l'algorithme de cryptographie symétrique qui va chiffrer la session, ainsi que ses paramètres divers,
  • Choisir la clé de la session TLS (et c'est là que se sont produites les plus grandes bagarres lors de la conception de TLS 1.3).

Notez que TLS n'est en général pas utilisé tel quel mais via un protocole de haut niveau, comme HTTPS pour sécuriser HTTP. TLS ne suppose pas un usage particulier : on peut s'en servir pour HTTP, pour SMTP (RFC 7672), pour le DNS (RFC 7858), etc. Cette intégration dans un protocole de plus haut niveau pose parfois elle-même des surprises en matière de sécurité, par exemple si l'application utilisatrice ne fait pas attention à la sécurité (Voir mon exposé à Devoxx, et ses transparents.)

TLS 1.3 est plutôt un nouveau protocole qu'une nouvelle version, et il n'est pas directement compatible avec son prédécesseur, TLS 1.2 (une application qui ne connait que 1.3 ne peut pas parler avec une application qui ne connait que 1.2.) En pratique, les bibliothèques qui mettent en œuvre TLS incluent en général les différentes versions, et un mécanisme de négociation de la version utilisée permet normalement de découvrir la version maximum que les deux parties acceptent (historiquement, plusieurs failles sont venues de ce point, avec des pare-feux stupidement configurés qui interféraient avec la négociation).

La section 1.3 de notre RFC liste les différences importantes entre TLS 1.2 (qui était normalisé dans le RFC 5246) et 1.3 :

  • La liste des algorithmes de cryptographie symétrique acceptés a été violemment réduite. Beaucoup trop longue en TLS 1.2, offrant trop de choix, comprenant plusieurs algorithmes faibles, elle ouvrait la voie à des attaques par repli. Les « survivants » de ce nettoyage sont tous des algorithmes à chiffrement intègre.
  • Un nouveau service apparait, 0-RTT (zero round-trip time, la possibilité d'établir une session TLS avec un seul paquet, en envoyant les données tout de suite), qui réduit la latence du début de l'échange. Attention, rien n'est gratuit en ce monde, et 0-RTT présente des nouveaux dangers, et ce nouveau service a été un des plus controversés lors de la mise au point de TLS 1.3, entrainant de nombreux débats à l'IETF.
  • Désormais, la sécurité future est systématique, la compromission d'une clé secrète ne permet plus de déchiffrer les anciennes communications. Plus de clés publiques statiques, tout se fera par clés éphémères. C'était le point qui a suscité le plus de débats à l'IETF, car cela complique sérieusement la surveillance (ce qui est bien le but) et le déboguage. L'ETSI, représentante du patronat, a même normalisé son propre TLS délibérement affaibli, eTLS.
  • Plusieurs messages de négociation qui étaient auparavant en clair sont désormais chiffrés. Par contre, l'indication du nom du serveur (SNI, section 3 du RFC 6066) reste en clair et c'est l'une des principales limites de TLS en ce qui concerne la protection de la vie privée. Le problème est important, mais très difficile à résoudre (voir par exemple la proposition ESNI, Encrypted SNI.)
  • Les fonctions de dérivation de clé ont été refaites.
  • La machine à états utilisée pour l'établissement de la connexion également (elle est détaillée dans l'annexe A du RFC).
  • Les algorithmes asymétriques à courbes elliptiques font maintenant partie de la définition de base de TLS (cf. RFC 7748), et on voit arriver des nouveaux comme ed25519 (cf. RFC 8422).
  • Par contre, DSA a été retiré.
  • Le mécanisme de négociation du numéro de version (permettant à deux machines n'ayant pas le même jeu de versions TLS de se parler) a changé. L'ancien était très bien mais, mal implémenté, il a suscité beaucoup de problèmes d'interopérabilité. Le nouveau est censé mieux gérer les innombrables systèmes bogués qu'on trouve sur l'Internet (la bogue ne provenant pas tant de la bibliothèque TLS utilisée que des pare-feux mal programmés et mal configurés qui sont souvent mis devant).
  • La reprise d'une session TLS précédente fait l'objet désormais d'un seul mécanisme, qui est le même que celui pour l'usage de clés pré-partagées. La négociation TLS peut en effet être longue, en terme de latence, et ce mécanisme permet d'éviter de tout recommencer à chaque connexion. Deux machines qui se parlent régulièrement peuvent ainsi gagner du temps.

Un bon résumé de ce nouveau protocole est dans l'article de Mark Nottingham.

Ce RFC concerne TLS 1.3 mais il contient aussi quelques changements pour la version 1.2 (section 1.4 du RFC), comme un mécanisme pour limiter les attaques par repli portant sur le numéro de version, et des mécanismes de la 1.3 « portés » vers la 1.2 sous forme d'extensions TLS.

La section 2 du RFC est un survol général de TLS 1.3 (le RFC fait 147 pages, et peu de gens le liront intégralement). Au début d'une session TLS, les deux parties, avec le protocole de salutation, négocient les paramètres (version de TLS, algorithmes cryptographiques) et définissent les clés qui seront utilisées pour le chiffrement de la session. En simplifiant, il y a trois phases dans l'établissement d'une session TLS :

  • Définition des clés de session, et des paramètres cryptographiques, le client envoie un ClientHello, le serveur répond avec un ServerHello,
  • Définition des autres paramètres (par exemple l'application utilisée au-dessus de TLS, ou bien la demande CertificateRequest d'un certificat client), cette partie est chiffrée, contrairement à la précédente,
  • Authentification du serveur, avec le message Certificate (qui ne contient pas forcément un certificat, cela peut être une clé brute - RFC 7250 ou une clé d'une session précédente - RFC 7924).

Un message Finished termine cette ouverture de session. (Si vous êtes fana de futurisme, notez que seule la première étape pourrait être remplacée par la distribution quantique de clés, les autres resteraient indispensables. Contrairement à ce que promettent ses promoteurs, la QKD ne dispense pas d'utiliser les protocoles existants.)

Comment les deux parties se mettent-elles d'accord sur les clés ? Trois méthodes :

  • Diffie-Hellman sur courbes elliptiques qui sera sans doute la plus fréquente,
  • Clé pré-partagée,
  • Clé pré-partagée avec Diffie-Hellman,
  • Et la méthode RSA, elle, disparait de la norme (mais RSA peut toujours être utilisé pour l'authentification, autrement, cela ferait beaucoup de certificats à jeter…)

Si vous connaissez la cryptographie, vous savez que les PSK, les clés partagées, sont difficiles à gérer, puisque devant être transmises de manière sûre avant l'établissement de la connexion. Mais, dans TLS, une autre possibilité existe : si une session a été ouverte sans PSK, en n'utilisant que de la cryptographie asymétrique, elle peut être enregistrée, et resservir, afin d'ouvrir les futures discussions plus rapidement. TLS 1.3 utilise le même mécanisme pour des « vraies » PSK, et pour celles issues de cette reprise de sessions précédentes (contrairement aux précédentes versions de TLS, qui utilisaient un mécanisme séparé, celui du RFC 5077, désormais abandonné).

Si on a une PSK (gérée manuellement, ou bien via la reprise de session), on peut même avoir un dialogue TLS dit « 0-RTT ». Le premier paquet du client peut contenir des données, qui seront acceptées et traitées par le serveur. Cela permet une importante diminution de la latence, dont il faut rappeler qu'elle est souvent le facteur limitant des performances. Par contre, comme rien n'est idéal dans cette vallée de larmes, cela se fait au détriment de la sécurité :

  • Plus de confidentialité persistante, si la PSK est compromise plus tard, la session pourra être déchiffrée,
  • Le rejeu devient possible, et l'application doit donc savoir gérer ce problème.

La section 8 du RFC et l'annexe E.5 détaillent ces limites, et les mesures qui peuvent être prises.

Le protocole TLS est décrit avec un langage spécifique, décrit de manière relativement informelle dans la section 3 du RFC. Ce langage manipule des types de données classiques :

  • Scalaires (uint8, uint16),
  • Tableaux, de taille fixe - Datum[3] ou variable, avec indication de la longueur au début - uint16 longer<0..800>,
  • Énumérations (enum { red(3), blue(5), white(7) } Color;),
  • Enregistrements structurés, y compris avec variantes (la présence de certains champs dépendant de la valeur d'un champ).

Par exemple, tirés de la section 4 (l'annexe B fournit la liste complète), voici, dans ce langage, la liste des types de messages pendant les salutations, une énumération :

       enum {
          client_hello(1),
          server_hello(2),
          new_session_ticket(4),
          end_of_early_data(5),
          encrypted_extensions(8),
          certificate(11),
          certificate_request(13),
          certificate_verify(15),
          finished(20),
          key_update(24),
          message_hash(254),
          (255)
      } HandshakeType;
    

Et le format de base d'un message du protocole de salutation :

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case end_of_early_data:     EndOfEarlyData;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
          };
      } Handshake;     
    

La section 4 fournit tous les détails sur le protocole de salutation, notamment sur la délicate négociation des paramètres cryptographiques. Notez que la renégociation en cours de session a disparu, donc un ClientHello ne peut désormais plus être envoyé qu'au début.

Un problème auquel a toujours dû faire face TLS est celui de la négociation de version, en présence de mises en œuvre boguées, et, surtout, en présence de boitiers intermédiaires encore plus bogués (pare-feux ignorants, par exemple, que des DSI ignorantes placent un peu partout). Le modèle original de TLS pour un client était d'annoncer dans le ClientHello le plus grand numéro de version qu'on gère, et de voir dans ServerHello le maximum imposé par le serveur. Ainsi, un client TLS 1.2 parlant à un serveur qui ne gère que 1.1 envoyait ClientHello(client_version=1.2) et, en recevant ServerHello(server_version=1.1), se repliait sur TLS 1.1, la version la plus élevée que les deux parties gèraient. En pratique, cela ne marche pas aussi bien. On voyait par exemple des serveurs (ou, plus vraisemblablement, des pare-feux bogués) qui raccrochaient brutalement en présence d'un numéro de version plus élevé, au lieu de suggérer un repli. Le client n'avait alors que le choix de renoncer, ou bien de se lancer dans une série d'essais/erreurs (qui peut être longue, si le serveur ou le pare-feu bogué ne répond pas).

TLS 1.3 change donc complètement le mécanisme de négociation. Le client annonce toujours la version 1.2 (en fait 0x303, pour des raisons historiques), et la vraie version est mise dans une extension, supported_versions (section 4.2.1), dont on espère qu'elle sera ignorée par les serveurs mal gérés. (L'annexe D du RFC détaille ce problème de la négociation de version.) Dans la réponse ServerHello, un serveur 1.3 doit inclure cette extension, autrement, il faut se rabattre sur TLS 1.2.

En parlant d'extensions, concept qui avait été introduit originellement dans le RFC 4366, notre RFC reprend des extensions déjà normalisées, comme le SNI (Server Name Indication) du RFC 6066, le battement de cœur du RFC 6520, le remplissage du ClientHello du RFC 7685, et en ajoute dix, dont supported_versions. Certaines de ces extensions doivent être présentes dans les messages Hello, car la sélection des paramètres cryptographiques en dépend, d'autres peuvent être uniquement dans les messages EncryptedExtensions, une nouveauté de TLS 1.3, pour les extensions qu'on n'enverra qu'une fois le chiffrement commencé. Le RFC en profite pour rappeler que les messages Hello ne sont pas protégés cryptographiquement, et peuvent donc être modifiés (le message Finished résume les décisions prises et peut donc protéger contre ce genre d'attaques).

Autrement, parmi les autres nouvelles extensions :

  • Le petit gâteau (cookie), pour tester la joignabilité,
  • Les données précoces (early data), extension qui permet d'envoyer des données dès le premier message (« O-RTT »), réduisant ainsi la latence, un peu comme le fait le TCP Fast Open du RFC 7413,
  • Liste des AC (certificate authorities), qui, en indiquant la liste des AC connues du client, peut aider le serveur à choisir un certificat qui sera validé (par exemple en n'envoyant le certificat CAcert que si le client connait cette AC).

La section 5 décrit le protocole des enregistrements (record protocol). C'est ce sous-protocole qui va prendre un flux d'octets, le découper en enregistrements, les protéger par le chiffrement puis, à l'autre bout, déchiffrer et reconstituer le flux… Notez que « protégé » signifie à la fois confidentialité et intégrité puisque TLS 1.3, contrairement à ses prédécesseurs, impose AEAD (RFC 5116).

Les enregistrements sont typés et marqués handshake (la salutation, vue dans la section précédente), change cipher spec, alert (pour signaler un problème) et application data (les données elle-mêmes) :

enum {
          invalid(0),
          change_cipher_spec(20),
          alert(21),
          handshake(22),
          application_data(23),
          (255)
      } ContentType;
    

Le contenu des données est évidemment incompréhensible, en raison du chiffrement (voici un enregistrement de type 23, données, vu par tshark) :

    TLSv1.3 Record Layer: Application Data Protocol: http-over-tls
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 6316
        Encrypted Application Data: eb0e21f124f82eee0b7a37a1d6d866b075d0476e6f00cae7...
    

Et décrite par la norme dans son langage formel :

struct {
          ContentType opaque_type = application_data; /* 23 */
          ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
          uint16 length;
          opaque encrypted_record[TLSCiphertext.length];
      } TLSCiphertext;
    

(Oui, le numéro de version reste à TLS 1.2 pour éviter d'énerver les stupides middleboxes.) Notez que des extensions à TLS peuvent introduire d'autres types d'enregistrements.

Une faiblesse classique de TLS est que la taille des données chiffrées n'est pas dissimulée. Si on veut savoir à quelle page d'un site Web un client HTTP a accédé, on peut parfois le déduire de l'observation de cette taille. D'où la possibilité de faire du remplissage pour dissimuler cette taille (section 5.4 du RFC). Notez que le RFC ne suggère pas de politique de remplissage spécifique (ajouter un nombre aléatoire ? Tout remplir jusqu'à la taille maximale ?), c'est un choix compliqué. Il note aussi que certaines applications font leur propre remplissage, et qu'il n'est alors pas nécessaire que TLS le fasse.

La section 6 du RFC est dédiée au cas des alertes. C'est un des types d'enregistrements possibles, et, comme les autres, il est chiffré, et les alertes sont donc confidentielles. Une alerte a un niveau et une description :

 struct {
          AlertLevel level;
          AlertDescription description;
      } Alert;
    

Le niveau indiquait si l'alerte est fatale mais n'est plus utilisé en TLS 1.2, où il faut se fier uniquement à la description, une énumération des problèmes possibles (message de type inconnu, mauvais certificat, enregistrement non décodable - rappelez-vous que TLS 1.3 n'utilise que du chiffrement intègre, problème interne au client ou au serveur, extension non acceptée, etc). La section 6.2 donne une liste des erreurs fatales, qui doivent mener à terminer immédiatement la session TLS.

La section 8 du RFC est entièrement consacrée à une nouveauté délicate, le « 0-RTT ». Ce terme désigne la possibilité d'envoyer des données dès le premier paquet, sans les nombreux échanges de paquets qui sont normalement nécessaires pour établir une session TLS. C'est très bien du point de vue des performances, mais pas forcément du point de vue de la sécurité puisque, sans échanges, on ne peut plus vérifier à qui on parle. Un attaquant peut réaliser une attaque par rejeu en envoyant à nouveau un paquet qu'il a intercepté. Un serveur doit donc se défendre en se souvenant des données déjà envoyées et en ne les acceptant pas deux fois. (Ce qui peut être plus facile à dire qu'à faire ; le RFC contient une bonne discussion très détaillée des techniques possibles, et de leurs limites. Il y en a des subtiles, comme d'utiliser des systèmes de mémorisation ayant des faux positifs, comme les filtres de Bloom, parce qu'ils ne produiraient pas d'erreurs, ils rejetteraient juste certains essais 0-RTT légitimes, cela ne serait donc qu'une légère perte de performance.)

La section 9 de notre RFC se penche sur un problème difficile, la conformité des mises en œuvres de TLS. D'abord, les algorithmes obligatoires. Afin de permettre l'interopérabilité, toute mise en œuvre de TLS doit avoir la suite de chiffrement TLS_AES_128_GCM_SHA256 (AES en mode GCM avec SHA-256). D'autres suites sont recommandées (cf. annexe B.4). Pour l'authentification, RSA avec SHA-256 et ECDSA sont obligatoires. Ainsi, deux programmes différents sont sûrs de pouvoir trouver des algorithmes communs. La possibilité d'authentification par certificats PGP du RFC 6091 a été retirée.

De plus, certaines extensions à TLS sont obligatoires, un pair TLS 1.3 ne peut pas les refuser :

  • supported_versions, nécessaire pour annoncer TLS 1.3,
  • cookie,
  • signature_algorithms, signature_algorithms_cert, supported_groups et key_share,
  • server_name, c'est à dire SNI (Server Name Indication), souvent nécessaire pour pouvoir choisir le bon certificat (cf. section 3 du RFC 6066).

La section 9 précise aussi le comportement attendu des équipements intermédiaires. Ces dispositifs (pare-feux, par exemple, mais pas uniquement) ont toujours été une plaie pour TLS. Alors que TLS vise à fournir une communication sûre, à l'abri des équipements intermédiaires, ceux-ci passent leur temps à essayer de s'insérer dans la communication, et souvent la cassent. Normalement, TLS 1.3 est conçu pour que ces interférences ne puissent pas mener à un repli (le repli est l'utilisation de paramètres moins sûrs que ce que les deux machines auraient choisi en l'absence d'interférence).

Il y a deux grandes catégories d'intermédiaires, ceux qui tripotent la session TLS sans être le client ou le serveur, et ceux qui terminent la session TLS de leur côté. Attention, dans ce contexte, « terminer » ne veut pas dire « y mettre fin », mais « la sécurité TLS se termine ici, de manière à ce que l'intermédiaire puisse accéder au contenu de la communication ». Typiquement, une middlebox qui « termine » une session TLS va être serveur TLS pour le client et client TLS pour le serveur, s'insérant complètement dans la conversation. Normalement, l'authentification vise à empêcher ce genre de pratiques, et l'intermédiaire ne sera donc accepté que s'il a un certificat valable. C'est pour cela qu'en entreprise, les machines officielles sont souvent installées avec une AC contrôlée par le vendeur du boitier intermédiaire, de manière à permettre l'interception.

Le RFC ne se penche pas sur la légitimité de ces pratiques, uniquement sur leurs caractéristiques techniques. (Les boitiers intermédiaires sont souvent programmés avec les pieds, et ouvrent de nombreuses failles.) Le RFC rappelle notamment que l'intermédiaire qui termine une session doit suivre le RFC à la lettre (ce qui devrait aller sans dire…)

Depuis le RFC 4346, il existe plusieurs registres IANA pour TLS, décrits en section 11, avec leurs nouveautés. En effet, plusieurs choix pour TLS ne sont pas « câblés en dur » dans le RFC mais peuvent évoluer indépendamment. Par exemple, le registre de suites cryptographiques a une politique d'enregistrement « spécification nécessaire » (cf. RFC 8126, sur les politiques d'enregistrement). La cryptographie fait régulièrement des progrès, et il faut donc pouvoir modifier la liste des suites acceptées (par exemple lorsqu'il faudra y ajouter les algorithmes post-quantiques) sans avoir à toucher au RFC (l'annexe B.4 donne la liste actuelle). Le registre des types de contenu, lui, a une politique d'enregistrement bien plus stricte, « action de normalisation ». On crée moins souvent des types que des suites cryptographiques. Même chose pour le registre des alertes ou pour celui des salutations.

L'annexe C du RFC plaira aux programmeurs, elle donne plusieurs conseils pour une mise en œuvre correcte de TLS 1.3 (ce n'est pas tout d'avoir un protocole correct, il faut encore qu'il soit programmé correctement). Pour aider les développeurs à déterminer s'ils ont correctement fait le travail, un futur RFC fournira des vecteurs de test.

Un des conseils les plus importants est évidemment de faire attention au générateur de nombres aléatoires, source de tant de failles de sécurité en cryptographie. TLS utilise des nombres qui doivent être imprévisibles à un attaquant pour générer des clés de session. Si ces nombres sont prévisibles, toute la cryptographie s'effondre. Le RFC conseille fortement d'utiliser un générateur existant (comme /dev/urandom sur les systèmes Unix) plutôt que d'écrire le sien, ce qui est bien plus difficile qu'il ne semble. (Si on tient quand même à le faire, le RFC 4086 est une lecture indispensable.)

Le RFC conseille également de vérifier le certificat du partenaire par défaut (quitte à fournir un moyen de débrayer cette vérification). Si ce n'est pas le cas, beaucoup d'utilisateurs du programme ou de la bibliothèque oublieront de le faire. Il suggère aussi de ne pas accepter certains certificats trop faibles (clé RSA de seulement 1 024 bits, par exemple).

Il existe plusieurs moyens avec TLS de ne pas avoir d'authentification du serveur : les clés brutes du RFC 7250 (à la place des certificats), ou bien les certificats auto-signés. Dans ces conditions, une attaque de l'homme du milieu est parfaitement possibe, et il faut donc prendre des précautions supplémentaires (par exemple DANE, normalisé dans le RFC 6698, que le RFC oublie malheureusement de citer).

Autre bon conseil de cryptographie, se méfier des attaques fondées sur la mesure du temps de calcul, et prendre des mesures appropriées (par exemple en vérifiant que le temps de calcul est le même pour des données correctes et incorrectes).

Il n'y a aucune bonne raison d'utiliser certains algorithmes faibles (comme RC4, abandonné depuis le RFC 7465), et le RFC demande que le code pour ces algorithmes ne soit pas présent, afin d'éviter une attaque par repli (annexes C.3 et D.5 du RFC). De la même façon, il demande de ne jamais accepter SSL v3 (RFC 7568).

L'expérience a prouvé que beaucoup de mises en œuvre de TLS ne réagissaient pas correctement à des options inattendues, et le RFC rappelle donc qu'il faut ignorer les suites cryptographiques inconnues (autrement, on ne pourrait jamais introduire une nouvelle suite, puisqu'elle casserait les programmes), et ignorer les extensions inconnues (pour la même raison).

L'annexe D, elle, est consacrée au problème de la communication avec un vieux partenaire, qui ne connait pas TLS 1.3. Le mécanisme de négociation de la version du protocole à utiliser a complètement changé en 1.3. Dans la 1.3, le champ version du ClientHello contient 1.2, la vraie version étant dans l'extension supported_versions. Si un client 1.3 parle avec un serveur <= 1.2, le serveur ne connaitra pas cette extension et répondra sans l'extension, avertissant ainsi le client qu'il faudra parler en 1.2 (ou plus vieux). Ça, c'est si le serveur est correct. S'il ne l'est pas ou, plus vraisemblablement, s'il est derrière une middlebox boguée, on verra des problèmes comme par exemple le refus de répondre aux clients utilisant des extensions inconnues (ce qui sera le cas pour supported_versions), soit en rejettant ouvertement la demande soit, encore pire, en l'ignorant. Arriver à gérer des serveurs/middleboxes incorrects est un problème complexe. Le client peut être tenté de re-essayer avec d'autres options (par exemple tenter du 1.2, sans l'extension supported_versions). Cette méthode n'est pas conseillée. Non seulement elle peut prendre du temps (attendre l'expiration du délai de garde, re-essayer…) mais surtout, elle ouvre la voie à des attaques par repli : l'attaquant bloque les ClientHello 1.3 et le client, croyant bien faire, se replie sur une version plus ancienne et sans doute moins sûre de TLS.

En parlant de compatibilité, le « 0-RTT » n'est évidemment pas compatible avec les vieilles versions. Le client qui envoie du « 0-RTT » (des données dans le ClientHello) doit donc savoir que, si la réponse est d'un serveur <= 1.2, la session ne pourra pas être établie, et il faudra donc réessayer sans 0-RTT.

Naturellement, les plus gros problèmes ne surviennent pas avec les clients et les serveurs mais avec les middleboxes. Plusieurs études ont montré leur caractère néfaste (cf. présentation à l'IETF 100, mesures avec Chrome (qui indique également que certains serveurs TLS sont gravement en tort, comme celui installé dans les imprimantes Canon), mesures avec Firefox, et encore d'autres mesures). Le RFC suggère qu'on limite les risques en essayant d'imiter le plus possible une salutation de TLS 1.2, par exemple en envoyant des messages change_cipher_spec, qui ne sont plus utilisés en TLS 1.3, mais qui peuvent rassurer la middlebox (annexe D.4).

Enfin, le RFC se termine par l'annexe E, qui énumère les propriétés de sécurité de TLS 1.3 : même face à un attaquant actif (RFC 3552), le protocole de salutation de TLS garantit des clés de session communes et secrètes, une authentification du serveur (et du client si on veut), et une sécurité persistante, même en cas de compromission ultérieure des clés (sauf en cas de 0-RTT, un autre des inconvénients sérieux de ce service, avec le risque de rejeu). De nombreuses analyses détaillées de la sécurité de TLS sont listées dans l'annexe E.1.6. À lire si vous voulez travailler ce sujet.

Quant au protocole des enregistrements, celui de TLS 1.3 garantit confidentialité et intégrité (RFC 5116).

TLS 1.3 a fait l'objet de nombreuses analyses de sécurité par des chercheurs, avant même sa normalisation, ce qui est une bonne chose (et qui explique en partie les retards). Notre annexe E pointe également les limites restantes de TLS :

  • Il est vulnérable à l'analyse de trafic. TLS n'essaie pas de cacher la taille des paquets, ni l'intervalle de temps entre eux. Ainsi, si un client accède en HTTPS à un site Web servant quelques dizaines de pages aux tailles bien différentes, il est facile de savoir quelle page a été demandée, juste en observant les tailles. (Voir « I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis », de Miller, B., Huang, L., Joseph, A., et J. Tygar et « HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting », de Husak, M., Čermak, M., Jirsik, T., et P. Čeleda). TLS fournit un mécanisme de remplissage avec des données bidon, permettant aux applications de brouiller les pistes. Certaines applications utilisant TLS ont également leur propre remplissage (par exemple, pour le DNS, c'est le RFC 7858). De même, une mise en œuvre de TLS peut retarder les paquets pour rendre l'analyse des intervalles plus difficile. On voit que dans les deux cas, taille des paquets et intervalle entre eux, résoudre le problème fait perdre en performance (c'est pour cela que ce n'est pas intégré par défaut).
  • TLS peut être également vulnérable à des attaques par canal auxiliaire. Par exemple, la durée des opérations cryptographiques peut être observée, ce qui peut donner des informations sur les clés. TLS fournit quand même quelques défenses : l'AEAD facilite la mise en œuvre de calculs en temps constant, et format uniforme pour toutes les erreurs, empêchant un attaquant de trouver quelle erreur a été déclenchée.

Le 0-RTT introduit un nouveau risque, celui de rejeu. (Et 0-RTT a sérieusement contribué aux délais qu'à connu le projet TLS 1.3, plusieurs participants à l'IETF protestant contre cette introduction risquée.) Si l'application est idempotente, ce n'est pas très grave. Si, par contre, les effets d'une requête précédentes peuvent être rejoués, c'est plus embêtant (imaginez un transfert d'argent répété…) TLS ne promet rien en ce domaine, c'est à chaque serveur de se défendre contre le rejeu (la section 8 donne des idées à ce sujet). Voilà pourquoi le RFC demande que les requêtes 0-RTT ne soient pas activées par défaut, mais uniquement quand l'application au-dessus de TLS le demande. (Cloudflare, par exemple, n'active pas le 0-RTT par défaut.)

Voilà, vous avez maintenant fait un tour complet du RFC, mais vous savez que la cryptographie est une chose difficile, et pas seulement dans les algorithmes cryptographiques (TLS n'en invente aucun, il réutilise des algorithmes existants comme AES ou ECDSA), mais aussi dans les protocoles cryptographiques, un art complexe. N'hésitez donc pas à lire le RFC en détail, et à vous méfier des résumés forcément toujours sommaires, comme cet article.

À part le 0-RTT, le plus gros débat lors de la création de TLS 1.3 avait été autour du concept que ses partisans nomment « visibilité » et ses adversaires « surveillance ». C'est l'idée qu'il serait bien pratique si on (on : le patron, la police, le FAI…) pouvait accéder au contenu des communications TLS. « Le chiffrement, c'est bien, à condition que je puisse lire les données quand même » est l'avis des partisans de la visibilité. Cela avait été proposé dans les Internet-Drafts draft-green-tls-static-dh-in-tls13 et draft-rhrd-tls-tls13-visibility. Je ne vais pas ici pouvoir capturer la totalité du débat, juste noter quelques points qui sont parfois oubliés dans la discussion. Côté partisans de la visibilité :

  • Dans une entreprise capitaliste, il n'y pas de citoyens, juste un patron et des employés. Les ordinateurs appartiennent au patron, et les employés n'ont pas leur mot à dire. Le patron peut donc décider d'accéder au contenu des communications chiffrées.
  • Il existe des règles (par exemple PCI-DSS dans le secteur financier ou HIPAA dans celui de la santé) qui requièrent de certaines entreprises qu'elles sachent en détail tout ce qui circule sur le réseau. Le moyen le plus simple de le faire est de surveiller le contenu des communications, même chiffrées. (Je ne dis pas que ces règles sont intelligentes, juste qu'elles existent. Notons par exemple que les mêmes règles imposent d'utiliser du chiffrement fort, sans faille connue, ce qui est contradictoire.)
  • Enregistrer le trafic depuis les terminaux est compliqué en pratique : applications qui n'ont pas de mécanisme de journalisation du trafic, systèmes d'exploitation fermés, boîtes noires…
  • TLS 1.3 risque de ne pas être déployé dans les entreprises qui tiennent à surveiller le trafic, et pourrait même être interdit dans certains pays, où la surveillance passe avant les droits humains.

Et du côté des adversaires de la surveillance :

  • La cryptographie, c'est compliqué et risqué. TLS 1.3 est déjà assez compliqué comme cela. Lui ajouter des fonctions (surtout des fonctions délibérement conçues pour affaiblir ses propriétés de sécurité) risque fort d'ajouter des failles de sécurité. D'autant plus que TLS 1.3 a fait l'objet de nombreuses analyses de sécurité avant son déploiement, et qu'il faudrait tout recommencer.
  • Contrairement à ce que semblent croire les partisans de la « visibilité », il n'y a pas que HTTPS qui utilise TLS. Ils ne décrivent jamais comment leur proposition marcherait avec des protocoles autres que HTTPS.
  • Pour HTTPS, et pour certains autres protocoles, une solution simple, si on tient absolument à intercepter tout le trafic, est d'avoir un relais explicite, configuré dans les applications, et combiné avec un blocage dans le pare-feu des connexions TLS directes. Les partisans de la visibilté ne sont en général pas enthousiastes pour cette solution car ils voudraient faire de la surveillance furtive, sans qu'elle se voit dans les applications utilisées par les employés ou les citoyens.
  • Les partisans de la « visibilité » disent en général que l'interception TLS serait uniquement à l'intérieur de l'entreprise, pas pour l'Internet public. Mais, dans ce cas, tous les terminaux sont propriété de l'entreprise et contrôlés par elle, donc elle peut les configurer pour copier tous les messages échangés. Et, si certains de ces terminaux sont des boîtes noires, non configurables et dont on ne sait pas bien ce qu'ils font, eh bien, dans ce cas, on se demande pourquoi des gens qui insistent sur leurs obligations de surveillance mettent sur leur réseau des machines aussi incontrôlables.
  • Dans ce dernier cas (surveillance uniquement au sein d'une entreprise), le problème est interne à l'entreprise, et ce n'est donc pas à l'IETF, organisme qui fait des normes pour l'Internet, de le résoudre. Après tout, rien n'empêche ces entreprises de garder TLS 1.2.

Revenons maintenant aux choses sérieuses, avec les mises en œuvre de TLS 1.3. Il y en existe au moins une dizaine à l'heure actuelle mais, en général, pas dans les versions officiellement publiées des logiciels. Notons quand même que Firefox 61 sait faire du TLS 1.3. Les autres mises en œuvre sont prêtes, même si pas forcément publiées. Prenons l'exemple de la bibliothèque GnuTLS. Elle dispose de TLS 1.3 depuis la version 3.6.3. Pour l'instant, il faut compiler cette version avec l'option ./configure --enable-tls13-support, qui n'est pas encore activée par défaut. Un bon article du mainteneur de GnuTLS explique bien les nouveautés de TLS 1.3.

Une fois GnuTLS correctement compilé, on peut utiliser le programme en ligne de commande gnutls-cli avec un serveur qui accepte TLS 1.3 :

% gnutls-cli  gmail.com 
...
- Description: (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: X25519
 - Curve size: 256 bits
- Version: TLS1.3
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-PSS-RSAE-SHA256
- Cipher: AES-256-GCM
- MAC: AEAD
...

Et ça marche, on fait du TLS 1.3. Si vous préférez écrire le programme vous-même, regardez ce petit programme. Si GnuTLS est en /local, il se compilera avec cc -I/local/include -Wall -Wextra -o test-tls13 test-tls13.c -L/local/lib -lgnutls et s'utilisera avec :

% ./test-tls13 www.ietf.org      
TLS connection using "TLS1.3 AES-256-GCM"

%  ./test-tls13 gmail.com  
TLS connection using "TLS1.3 AES-256-GCM"

%  ./test-tls13 mastodon.gougere.fr
TLS connection using "TLS1.2 AES-256-GCM"

% ./test-tls13 www.bortzmeyer.org
TLS connection using "TLS1.2 AES-256-GCM"

% ./test-tls13 blog.cloudflare.com
TLS connection using "TLS1.3 AES-256-GCM"
  

Cela vous donne une petite idée des serveurs qui acceptent TLS 1.3.

Un pcap d'une session TLS 1.3 est disponible en tls13.pcap. Notez que le numéro de version n'est pas encore celui du RFC (0x304). Ici, 0x7f1c désigne l'Internet-Draft numéro 28. Voici la session vue par tshark :

    1   0.000000 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 94 36866 → https(443) [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=3528788861 TSecr=0 WS=128
    2   0.003052 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 86 https(443) → 36866 [SYN, ACK] Seq=0 Ack=1 Win=24400 Len=0 MSS=1220 SACK_PERM=1 WS=1024
    3   0.003070 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [ACK] Seq=1 Ack=1 Win=28800 Len=0
    4   0.003354 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1 403 Client Hello
    5   0.006777 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [ACK] Seq=1 Ack=330 Win=25600 Len=0
    6   0.011393 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TLSv1.3 6496 Server Hello, Change Cipher Spec, Application Data
    7   0.011413 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [ACK] Seq=330 Ack=6423 Win=41728 Len=0
    8   0.011650 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1.3 80 Change Cipher Spec
    9   0.012685 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1.3 148 Application Data
   10   0.015693 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [ACK] Seq=6423 Ack=411 Win=25600 Len=0
   11   0.015742 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TLSv1.3 524 Application Data
   12   0.015770 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [RST] Seq=411 Win=0 Len=0
   13   0.015788 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [FIN, ACK] Seq=6873 Ack=411 Win=25600 Len=0
   14   0.015793 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [RST] Seq=411 Win=0 Len=0

Et, complètement décodée par tshark :

Secure Sockets Layer [sic]
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Version: TLS 1.2 (0x0303)
...
            Extension: supported_versions (len=9)
                Type: supported_versions (43)
                Length: 9
                Supported Versions length: 8
                Supported Version: Unknown (0x7f1c)
                Supported Version: TLS 1.2 (0x0303)
                Supported Version: TLS 1.1 (0x0302)
                Supported Version: TLS 1.0 (0x0301)

Le texte complet est en tls13.txt. Notez bien que la négociation est en clair.

Quelques autres articles à lire :


Téléchargez le RFC 8446


L'article seul

RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier

Date de publication du RFC : Août 2018
Auteur(s) du RFC : Y. Nir (Check Point), S. Josefsson (SJD AB), M. Pegourie-Gonnard (Independent / PolarSSL)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 7 août 2018


Ce RFC décrit les algorithmes cryptographiques à base de courbes elliptiques utilisés dans TLS. Il remplace le RFC 4492.

Plus exactement, il normalise les algorithmes utilisés dans les versions de TLS allant jusqu'à 1.2 incluse. L'utilisation des courbes elliptiques par TLS 1.3 est décrite dans le RFC sur TLS 1.3, le RFC 8446. Les deux points importants de ce nouveau RFC sont :

  • L'utilisation de courbes elliptiques pour un échange Diffie-Hellman de la clé de session TLS (ce qu'on nomme ECDHE),
  • Les algorithmes de signature à courbes elliptiques ECDSA et EdDSA pour authentifier le pair TLS.

Commençons par l'échange de clés de session (section 2). TLS nécessite que les deux pairs se mettent d'accord sur une clé de chiffrement symétrique qui sera ensuite utilisée pendant toute la session, avec des algorithmes comme AES. Une des façons de synchroniser cette clé de session est qu'un des pairs la génère aléatoirement, puis la chiffre avec la clé publique (chiffrement asymétrique) de son pair avant de lui transmettre (cela marche avec RSA mais je n'ai pas l'impression qu'il y ait un moyen normalisé de faire cela avec les courbes elliptiques). Une autre façon est d'utiliser un échange Diffie-Hellman. Contrairement à l'échange Diffie-Hellman originel, celui présenté dans ce RFC, ECDHE, utilise la cryptographie sur courbes elliptiques. (J'ai simplifié pas mal : par exemple, l'échange ECDHE ne donnera pas directement la clé de session, celle-ci sera en fait dérivée de la clé obtenue en ECDHE.) Le principal avantage de Diffie-Hellman est de fournir de la sécurité même en cas de compromission ultérieure de la clé privée.

Notre RFC présente trois variantes d'ECDHE, selon la manière dont l'échange est authentifié, l'une utilisant ECDSA ou EdDSA, l'autre utilisant le traditionnel RSA, et la troisième n'authentifiant pas du tout, et étant donc vulnérable aux attaques de l'Homme du Milieu, sauf si une authentification a lieu en dehors de TLS. (Attention, dans le cas de ECDHE_RSA, RSA n'est utilisé que pour authentifier l'échange, la génération de la clé se fait bien en utilisant les courbes elliptiques.)

Lorsque l'échange est authentifié (ECDHE_ECDSA - qui, en dépit de son nom, inclut EdDSA - ou bien ECDHE_RSA), les paramètres ECDH (Diffie-Hellman avec courbes elliptiques) sont signés par la clé privée (ECDSA, EdDSA ou RSA). S'il n'est pas authentifié (ECDH_anon, mais notez que le nom est trompeur, bien que le E final - ephemeral - manque, la clé est éphémère), on n'envoie évidemment pas de certificat, ou de demande de certificat.

Voilà, avec cette section 2, on a pu générer une clé de session avec Diffie-Hellman, tout en authentifiant le serveur avec des courbes elliptiques. Et pour l'authentification du client ? C'est la section 3 de notre RFC. Elle décrit un mécanisme ECDSA_sign (là encore, en dépit du nom du mécanisme, il fonctionne aussi bien pour EdDSA), où le client s'authentifie en signant ses messages avec un algorithme à courbes elliptiques.

Les courbes elliptiques ont quelques particularités qui justifient deux extensions à TLS que présente la section 4 du RFC. Il y a Supported Elliptic Curves Extension et Supported Point Formats Extension, qui permettent de décrire les caractéristiques de la courbe elliptique utilisée (on verra plus loin que la deuxième extension ne sert plus guère). Voici, vue par tshark, l'utilisation de ces extensions dans un ClientHello TLS envoyé par OpenSSL :

Extension: elliptic_curves
                Type: elliptic_curves (0x000a)
                Length: 28
                Elliptic Curves Length: 26
                Elliptic curves (13 curves)
                    Elliptic curve: secp256r1 (0x0017)
                    Elliptic curve: secp521r1 (0x0019)
                    Elliptic curve: brainpoolP512r1 (0x001c)
                    Elliptic curve: brainpoolP384r1 (0x001b)
                    Elliptic curve: secp384r1 (0x0018)
                    Elliptic curve: brainpoolP256r1 (0x001a)
                    Elliptic curve: secp256k1 (0x0016)
...
Extension: ec_point_formats
                Type: ec_point_formats (0x000b)
                Length: 4
                EC point formats Length: 3
                Elliptic curves point formats (3)
                    EC point format: uncompressed (0)
                    EC point format: ansiX962_compressed_prime (1)
                    EC point format: ansiX962_compressed_char2 (2)

La section 5 du RFC donne les détails concrets. Par exemple, les deux extensions citées plus haut s'écrivent, dans le langage de TLS (cf. section 4 du RFC 5246) :

enum {
          elliptic_curves(10),
          ec_point_formats(11)
} ExtensionType;

La première extension permet d'indiquer les courbes utilisées. Avec celles du RFC 7748, cela donne, comme possibilités :

enum {
               deprecated(1..22),
               secp256r1 (23), secp384r1 (24), secp521r1 (25),
               x25519(29), x448(30),
               reserved (0xFE00..0xFEFF),
               deprecated(0xFF01..0xFF02),
               (0xFFFF)
} NamedCurve;  

secp256r1 est la courbe P-256 du NIST, x25519 est la Curve-25519 de Bernstein. Notez que beaucoup des courbes de l'ancien RFC 4492, jamais très utilisées, ont été abandonnées. (Les courbes se trouvent dans un registre IANA.)

Normalement, dans TLS, on peut choisir séparément l'algorithme de signature et celui de condensation (cf. section 7.4.1.4.1 du RFC 5246). Avec certains algorithmes comme EdDSA dans sa forme « pure », il n'y a pas de condensation séparée et un « algorithme » bidon, Intrinsic (valeur 8) a été créé pour mettre dans le champ « algorithme de condensation » de l'extension signature_algorithms.

Voici une négociation TLS complète, vue par curl :

%  curl -v https://www.nextinpact.com
...
* Connected to www.nextinpact.com (2400:cb00:2048:1::6819:f815) port 443 (#0)
...
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
...
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=nextinpact.com
...
> GET / HTTP/1.1
> Host: www.nextinpact.com
> User-Agent: curl/7.52.1
> Accept: */*

On voit que l'algorithme utilisé par TLS est ECDHE-ECDSA-AES128-GCM-SHA256, ce qui indique ECDHE avec ECDSA. Le certificat du serveur doit donc inclure une clé « courbe elliptique ». Regardons ledit certificat :

% openssl s_client -connect www.nextinpact.com:443 -showcerts | openssl x509 -text
Certificate:
...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Domain Validation Secure Server CA 2
...
        Subject: OU = Domain Control Validated, OU = PositiveSSL Multi-Domain, CN = ssl378410.cloudflaressl.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
...
                ASN1 OID: prime256v1
                NIST CURVE: P-256
...
            X509v3 Subject Alternative Name: 
                DNS:ssl378410.cloudflaressl.com, DNS:*.baseballwarehouse.com, DNS:*.campusgroups.com, DNS:*.cretedoc.gr, DNS:*.groupment.com, DNS:*.icstage.com, DNS:*.ideacouture.com, DNS:*.industrialtour-deloitte.com, DNS:*.jonessnowboards.com, DNS:*.nextinpact.com, DNS:*.pcinpact.com, DNS:*.pinkapple.com, DNS:*.softballrampage.com, DNS:*.undercovercondoms.co.uk, DNS:baseballwarehouse.com, DNS:campusgroups.com, DNS:cretedoc.gr, DNS:groupment.com, DNS:icstage.com, DNS:ideacouture.com, DNS:industrialtour-deloitte.com, DNS:jonessnowboards.com, DNS:nextinpact.com, DNS:pcinpact.com, DNS:pinkapple.com, DNS:softballrampage.com, DNS:undercovercondoms.co.uk
    Signature Algorithm: ecdsa-with-SHA256

On a bien une clé sur la courbe P-256.

Quel est l'état des mises en œuvre de ces algorithmes dans les bibliothèques TLS existantes ? ECDHE et ECDSA avec les courbes NIST sont très répandus. ECDHE avec la courbe Curve25519 est également dans plusieurs bibliothèques TLS. Par contre, EdDSA, ou ECDHE avec la courbe Curve448, sont certes implémentés mais pas encore largement déployés.

Les changements depuis le RFC 4492 sont résumés dans l'annexe B. Souvent, une norme récente ajoute beaucoup de choses par rapport à l'ancienne mais, ici, pas mal de chose ont au contraire été retirées :

  • Plusieurs courbes peu utilisées disparaissent,
  • Il n'y a plus qu'un seul format de point accepté (uncompressed),
  • Des algorithmes comme toute la famille ECDH_ECDSA (ECDH et pas ECDHE, donc ceux dont la clé n'est pas éphémère) sont retirés.

Parmi les ajouts, le plus important est évidemment l'intégration des « courbes Bernstein », Curve25519 et Curve448, introduites par le RFC 7748. Et il y avait également plusieurs erreurs techniques dans le RFC 4492, qui sont corrigées par notre nouveau RFC.

Et, pendant que j'y suis, si vous voulez générer un certificat avec les courbes elliptiques, voici comment faire avec OpenSSL :

% openssl ecparam -out ec_key.pem -name prime256v1 -genkey
% openssl req -new -key ec_key.pem  -nodes -days 1000 -out cert.csr
  

J'ai utilisé ici la courbe P-256 (prime256v1 est encore un autre identificateur pour la courbe NIST P-256, chaque organisme qui normalise dans ce domaine ayant ses propres identificateurs). Si vous voulez la liste des courbes que connait OpenSSL :

% openssl ecparam -list_curves 

Ce blog est accessible en TLS mais pas avec des courbes elliptiques. En effet, l'AC que j'utilise, CAcert, ne les accepte hélas pas (« The keys you supplied use an unrecognized algorithm. For security reasons these keys can not be signed by CAcert. ») Il y a des raisons pour cela mais c'est quand même déplorable. (Enfin, j'accepte quand même ECDHE.)

Enfin, un échange TLS complet vu par tshark est visible ici.

Merci à Manuel Pégourié-Gonnard pour sa relecture vigilante.


Téléchargez le RFC 8422


L'article seul

Articles des différentes années : 2018  2017  2016  2015  2014  2013  2012  Précédentes années

Syndication : en HTTP non sécurisé, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu, en HTTPS, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.