GuiGui's Show

‒ Bon, on me demande une estimation du budget cloud de l'année…
‒ Ah ouais, chaud…
‒ Il faut récupérer les estimations de trafic, essayer d'estimer le nombre d'instances, la puissance, les durées de traitement, déduire la bande passante et le volume à stocker… Ou alors j'le fais au doigt mouillé…
‒ Mais ouais vas-y, t'as l'habitude, gros…
‒ « En moyenne, les entreprises dépassent d'environ 23 M le budget consacré aux dépenses liées au cloud… »
‒ Bizarre…

S'il y avait qu'avec le cloud qu'on a des estimations bidons… S'il y avait qu'en informatique qu'on a des estimations bidons (voir les fréquents articles du Canard enchaîné sur les dépassements de budget de chantiers)… Les indicateurs et les budgets, c'est bullshit over bullshit for more bullshitness (tm) au détriment de la qualité des services rendus… Mais bon, ça occupe des gens de """"calculer"""" tout ça.

Durant la mise à jour de la base de données de Tiny Tiny RSS à la version 137, j'ai l'erreur suivante : « ERROR 1062 (23000) at line 3: Duplicate entry '2' for key 'ttrss_feeds_feed_url_owner_uid_key' ».

Cette mise à jour ajoute une contrainte d'unicité pour le couple URL d'un flux RSS + propriétaire du flux. En gros, un même utilisateur de tt-rss ne peut plus avoir deux flux ayant la même URL.

Comment indentifier le flux RSS en double ? Réponse ici : How To Find Duplicate Values in MySQL. Je nettoie un peu la requête et je la mets ici pour archivage : select feed_url, COUNT(feed_url) AS cpt_feedurl FROM ttrss_feeds GROUP BY feed_url HAVING cpt_feedurl > 1;.

Dans mon cas, il s'agit bien d'une erreur, donc j'ai supprimé le flux RSS concerné. Si ce n'est pas une erreur, on peut conserver le flux prétendument en double en ajoutant, dans l'URL, un caractère qui a aucun impact sur sa signification, comme « ? ».

On peut ensuite poursuivre la mise à jour de tt-rss.

Pour copier des images disque sur un autre serveur FOG, rsync + export des définitions (onglet « images ») + import des définitions. Sans l'export+import, l'image disque sera perçue comme étant vide, donc l'erreur suivante se produira sur les postes durant le déploiement « Unable to locate image store (/bin/fog.download) ».

J'installe un nouveau nœud de stockage (storage node) FOG (outil de déploiement d'images disque) avec le script d'installation de FOG (installfog.sh).
Dans l'assistant d'installation, je valide précipitamment l'adresse IP du serveur de base de données FOG (qui est le serveur qui porte l'interface web de FOG), donc elle vaut l'adresse IP du nœud que je déploie. Mais je ne m'en rend pas compte.

systemctl status FOGMulticastManager (mais c'est pareil pour les autres services FOG genre FOGPingHosts, FOGTaskScheduler, etc.) affiche « Active: failed » + « A valid database connection could not be made ».
Je corrige la ligne « snmysqlhost= » dans le fichier /opt/fog/.fogsettings. Je restart les services FOG. Sans succès.
Je redémarre la machine. Sans succès.
Je tente une connexion à la BDD en ligne de commande comme indiqué dans le message sur le forum pointé par ce shaarli : ça fonctionne.

FOG ne prend pas en compte la modification du fichier « .fogsettings ». Au final, j'ai lancé, une nouvelle fois, le script installfog.sh. Il a détecté la présence d'une installation existante, il a fait sa tambouille, et, ça fonctionne. ÉDIT DU 04/09/2020 À 15 H 06 : pour que la modification soit prise en compte à chaud (sans utiliser installfog.sh), il faut modifier « DATABASE_HOST » dans /var/www/fog/lib/fog/config.class.php. FIN DE L'ÉDIT DU 04/09/2020.

Match un motif sauf si la ligne contient d'autres motifs à ignorer, avec une regex Perl-Compatible :

Ho, une regex look-ahead + negative look-ahead. Utilisable avec grep -Po.
J'en ai déjà parlé. Cool de revoir cette syntaxe bien pratique afin d'éviter des grep / cut / awk / etc. en cascade. :)
Dans cet exemple, la partie look-ahead me semble être superflue et la fin me semble être saturée en parenthèses inutiles. La regex suivante devrait produire le même résultat : \MOTIF_A_MATCH\b(?!ignoreme1|ignoreme2|ignoremeX)$.

Une analyse critique de la généralisation à prévoir de la confidentialité différentielle (manipuler des données personnelles tout en utilisant des statistiques et, éventuellement, de la cryptographie afin d'empêcher des croisements / levées d'anonymat) par les géants du net. Pérennisation du "business as usual" autour des données personnelles face au RGPD (il voit d'un bon œil les stats, la prétendue anonymisation, tout ça, le RGPD) en racontant potentiellement du bullshit (si l'anonymiseur est celui qui bénéficie financièrement du traitement de données persos, comment garantir qu'il ne désanonymisera pas les données pour son propre compte ? ‒ pompier pyromane ‒) et en permettant, de fait, de fuir tout questionnement autour de la protection de notre intimité ("faites-nous confiance, c'est de l'anonymisation military-grade avec tout plein de calculs compliqués dedans !").

Péréniser l’exploitation commerciale des données personnelles en dégradant leur granularité par des mécanismes cryptographiques, c’esi ici une intéressante approche poussée par Google et d’autres.

[…]

Le concept s'appelle confidentialité différentielle, et vous risquez d'en entendre parler ces prochains mois vu que Google commence à envoyer l'artillerie lourde pour pousser ce concept. Rappel des faits : il y a environ un an, Google publiait sa bibliothèque dédiée. Il n'est pas le premier à s'intéresser à ce concept. Apple avait placé ses pions en 2016, mais de manière peut-être moins ostantatoire. Normal car, contrairement à Google, la collecte des données n'est pas la principale source de revenu d'Apple.

[…]

[…] C'est bien ce que propose la confidentialité différentielle en introduisant des aléas mathématique dans les sets de données afin qu'un croisement ultérieur non prévu ne permette pas d'identifier nomminativement une personne.

Quand un acteur soutient qu'il anonymise les données, il se garde souvent d'expliquer par quel procédé il parvient à une anonymisation interdisant à des tiers, mais aussi à lui-même, de "désanonymiser" ces données. […]

[…]

[…] Le RGPD a sifflé la fin d'une récréation et ceci a été anticipé de longue date par quelques gros acteurs qui voient dans l'anonymisation de la collecte une piste pour continuer à exploiter ces données personnelles.

[…]

Selon le principe du pompier pyromane, c'est celui qui collecte qui "anonymise", qui stocke, qui traite, et qui monétise... Au doigt mouillé, c'est ce que l'on appelle un bug d'architecture.

[…]

C'est encore l'un des coups de génie de Google qui va s'approprier la généralisation du concept de confidentialité différentielle. L'objectif est ici de se poser en "tiers de confiance" et ainsi enfermer un peu plus un public déjà captif de professionnels qui pourront brandir ce nouvel argument pour instaurer un climat de confiance avec leurs propres clients... Parce que le client, "il a confiance en Google".

Via https://twitter.com/bearstech/status/1291009891688210433 .

J'aime beaucoup l'exemple exposé dans la fiche Wikipedia de la confidentialité différentielle, car il permet de nuancer la critique enflammée précédente :

La confidentialité différentielle est souvent obtenue en appliquant un procédé qui introduit de l'aléa dans les données. Un exemple simple, qui s'est notamment développé en sciences sociales6, est de demander à une personne de répondre à la question "Possédez-vous l'attribut A ?" selon le déroulement suivant :

1. Lancer une pièce.
2. Si pile, alors répondre honnêtement.
3. Si face, alors lancer à nouveau la pièce et répondre "Oui" si face, "Non" si pile.

La confidentialité surgit du caractère réfutable de chacune des réponses individuelles. En particulier, si A est synonyme de comportement illégal, alors répondre "Oui" n'est pas incriminant, dans la mesure où la personne a une probabilité d'un quart de réponse "Oui", quel qu'il en soit. Mais, de façon globale, ces données sont significatives, puisque les réponses positives sont données à un quart par des personnes qui n'ont pas l'attribut A et à trois quart par des personnes qui le possèdent véritablement. Ainsi, si p est la proportion véritable de personnes ayant A, alors on s'attend à obtenir (1/4)(1-p) + (3/4)p = (1/4) + p/2 réponses positives. D'où une estimation possible de p.

Bien que cette illustration, s'inspirant de la réponse aléatoire, puisse s'appliquer à la divulgation de micro-données (c'est-à-dire de jeu de données contenant une entrée par participant), la confidentialité différentielle exclut par définition ce type de divulgation, en ne permettant que la divulgation de données agrégées par requêtes. En effet, la divulgation de micro-données violerait les axiomes fondant la confidentialité différentielle, dont notamment le déni plausible d'inclusion ou d'exclusion de participants

Carte de France collaborative de la surveillance sécuritaire de l'espace public : drones, police prédictive, vidéosurveillance automatisée, reconnaissance faciale, capteurs sonors, safe city, etc.

Via https://twitter.com/technopolice_fr/status/1292759840780148738 via https://twitter.com/vincib/ .

Résumé : epmd, l'un des bidules erlang dont dépend le serveur XMPP ejabberd, écoute le monde entier sur le port tcp/4369 en utilisant le mécanisme d'activation par socket de systemd (à la inetd / xinetd). Pour le faire écouter uniquement en local, il faut modifier la configuration de la socket systemd epmd.socket, changer la configuration de ejabberdctl a aucun effet. ejabberd écoute également sur un port aléatoire…

Sur un de mes serveurs, je regarde tous les ports ouverts / en écoute avec ss -ltupn (je rappelle que netstat est déprécié depuis de nombreuses années, ss utilise les """"nouvelles"""" fonctions du noyau et est capable d'afficher plus d'informations ‒ tous les processus qui utilisent une socket, les options de la socket genre ipv6only, les timers dans un format lisible, l'algo de contrôle de la congestion, la pmtu, la mss, etc. ‒) et je vois ceci :

tcp    LISTEN    0    128    0.0.0.0:4369    0.0.0.0:*     users:(("systemd",pid=1,fd=47)) ino:11367904 sk:166 <->

Pourquoi systemd écoute-t-il sur le port tcp/4369 ? Une recherche sur le web montre qu'il s'agit en fait d'epmd, un démon Erlang qui utilise le mécanisme d'activation par socket de systemd (à la inetd / xinetd). Pourquoi epmd n'apparaît pas dans la liste des utilisateurs de la socket (ss fait ça d'habitude, contrairement à netstat ;) ) ? Car, à ce moment-là, j'avais arrêté (systemctl stop) ejabberd, donc epmd n'était plus en activité.

Le seul bidule Erlang que j'utilise est ejabberd. Lisons la doc' : « epmd (Erlang Port Mapper Daemon) is a small name server included in Erlang/OTP and used by Erlang programs when establishing distributed Erlang communications. ejabberd needs epmd to use ejabberdctl and also when clustering ejabberd nodes. This small program is automatically started by Erlang, and is never stopped. »

J'ai un seul serveur derrière mon service Jabber et j'ose espérer qu'on peut piloter son serveur avec un ejabberdctl exécuté localement. Pas besoin d'être ouvert à tous les vents.

Lisons encore la doc' : « You should block the port 4369 in the firewall in such a way that only the programs in your machine can access it, or configure the option ERL_EPMD_ADDRESS in the file ejabberdctl.cfg. ». Non, ça ne fonctionne pas.

Lisons encore : « It is also possible to configure in ejabberdctl.cfg the network interface where the Erlang node will listen and accept connections. The Erlang command-line parameter used internally is, for example: erl ... -kernel inet_dist_use_interface "{127,0,0,1}" ». Non, changer la valeur de la variable « INET_DIST_INTERFACE » ne fonctionne pas non plus.

Au final, j'ai suivi ce tuto (mais pour obtenir le résultat inverse) et j'ai fait la modification côté systemd :

• systemctl edit epmd.socket ;
  
  

• Contenu :

  [Socket]
  ListenStream=127.0.0.1:4369

  
  

• systemctl daemon-reload ;
  
  
• systemctl restart epmd.socket ejabberd ;

J'étais persuadé que ce changement est intervenu avec Buster, mais, non, j'observe ce comportement dans une machine virtuelle Jessie… Ça doit dater du passage à systemd. Vache, toutes ces années sans rien voir. :O

Résumé : virer les protocoles antérieurs à TLS 1.2 quand c'est possible (pas sur un serveur emails), migrer sur une configuration qui indique le plus vieux protocole TLS que l'on veut prendre en charge (comme conseillé dans la documentation d'OpenSSL) plutôt qu'une configuration qui spécifie chaque protocole qu'on veut prendre en charge (syntaxe imposée par dovecot et possible uniquement avec Apache httpd, pour l'instant), utiliser uniquement des mécanismes d'échange de clés qui permettent la confidentialité persistante, utiliser uniquement des algorithmes de chiffrement intègre (AEAD) quand c'est possible (pas sur un serveur emails), utiliser des courbes elliptiques un peu plus costaudes lors des échanges de clés quand c'est possible (pas sur un serveur emails), tenter d'utiliser des paramètres plus costauds lors des échanges de clés sans courbes elliptiques (mais ce n'est pas possible pour le moment avec la version d'OpenSSL livrée dans Debian), et autres manips en lien avec TLS. À la fin, je publie mes configurations TLS actualisées.

Quand j'ai étudié les nouveautés apportées par TLS 1.3, je me suis demandé « quand a été publiée la norme TLS 1.2 ? ». En 2008. Il y a 12 ans. Ça laisse le temps de migrer. Ça a été le déclic : il est temps de renforcer à nouveau les configurations TLS de mes serveurs. Ma dernière réflexion globale sur le sujet date de 2014 (et il y a une erreur dans la conf' Postfix que je propose…). Depuis, j'ai fait évoluer mes configurations, comme ici, en 2016, mais je n'ai pas réfléchi globalement.

Ce que je viens d'écrire est une vue de l'esprit. Certes, la norme TLS 1.2 a été publiée en 2008, mais l'implémentation TLS la plus répandue, OpenSSL, l'a implémentée à partir de 2012 (version 1.0.1). Ce qui signifie que TLS 1.2 est arrivée dans la version Wheezy / 7 de Debian publiée en 2013. TLS 1.2 est activé par défaut à partir de winwin 8, publié en 2012. Pour winwin 7 (client) / winwin 2008 + IIS, il faut activer TLS 1.2 dans le registre après une mise à jour publiée en 2016. Les principaux navigateurs web ont activé TLS 1.2 à partir de 2013-2014. Idem pour OpenVPN (2014). TLS 1.2 n'a pas vraiment 12 ans, mais plutôt 6 à 8 ans.

Conseils

Avant de commencer, je vais te donner trois conseils : 1) ne me suis pas aveuglément, je ne suis ni mathématicien, ni cryptographe, ni expert en sécurité informatique, ni… ; 2) vérifie le comportement de tes configurations TLS avec plusieurs testeurs TLS ; 3) évalue, dans le temps (plusieurs mois), le bon fonctionnement de tes confs TLS actualisées, car certains problèmes se détectent sur le tard (exemple ci-dessous).

Une configuration TLS doit être adapté au service protégé et à son public.

• Ça sert à rien d'être extrême dans la configuration TLS de son serveur emails, par exemple, car l'écrasante majorité des autres serveurs emails de la planète sont conçus pour ré-émettre l'email en clair (sans chiffrement) si son acheminement chiffré n'a pas fonctionné (car aucun paramètre TLS en commun). En revanche, pas de problème technique pour serrer la vis sur le web ou sur la messagerie Jabber XMPP, car il n'y a pas de bascule en clair automatique ;
  
  
• On ne devrait pas être aussi strict sur un service mutualisé que sur un service qu'on est le seul à utiliser. Car on ne sait jamais si autrui est à jour, avec qui il communique, etc. De même, on ne renforce pas la configuration TLS d'un site web insignifiant (mon site, un site où on communique des photos à la famille, etc.) comme on renforce celle d'un site web massivement fréquenté par un public très divers (site gouvernemental, commercial, etc.).

Pour illustrer ça, une petite anecdote. La CPAM envoie des informations à l'ensemble des assurés ("ce que nous faisons pour vous durant le Covid", "attention à la campagne de phishing en cours", etc.). Pour cela, elle a recours à un prestataire, Worldline. Dans le journal de mon Postfix, je lis l'erreur TLS library problem: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 80. Sur le web, on trouve aucune aide. Je suis revenu progressivement en arrière dans ma configuration TLS. Au final, Wordline refuse que je priorise les algorithmes d'échange de clés qui ne sont pas basés sur les courbes elliptiques par rapport à ceux qui les utilisent. C'est compréhensible : l'utilisation des courbes elliptiques est un gain de performance, donc de temps. Comme la CPAM n'envoie pas d'emails tous les jours (et que les emails relatifs à une question posée via l'espace personnel emprunte un autre circuit), cette compréhension du problème m'a pris trois mois. Bref, ne fais pas n'importe quoi et surveille tes journaux pendant plusieurs mois.

Voici les commandes que j'ai utilisées afin de surveiller les journaux de mes serveurs pendant plusieurs mois :

• Postfix : grep -E -C1 "(unsupported protocol|unknown protocol|no shared cipher|TLS library problem|SSL_connect error|handshake failure)" /var/log/mail/postfix.log (attention, ce chemin est spécifique à ma configuration) ;
  
  
• Dovecot : grep -E -C1 "(unsupported protocol|unknown protocol|no shared cipher|TLS handshaking|SSL_connect error|handshake failure)" /var/log/mail/dovecot.log (idem) ;
  
  
• Ejabberd : grep -E "(unsupported protocol|unknown protocol|no shared cipher|TLS failed|SSL_connect error|handshake failure)" /var/log/ejabberd/ejabberd.log ;
  
  
• Apache httpd / nginx : on peut journaliser des informations (version du protocole, algorithmes utilisés) uniquement sur les connexions réussies. Pour voir celles qui échouent, il faut utiliser tshark, la version ligne de commande de wireshark (on peut la laisser tourner dans un screen ou un tmux, par exemple) : tshark -Y 'ssl.record.content_type == 21 && ssl.record.length <= 2 && ssl.alert_message.desc != 48' 'tcp and port 443'. Source 1. Source 2.

Que changer ? (théorie)

Protocoles

Comme dit ci-dessus, TLS 1.2 a été publié en 2008 et implémenté depuis 2012-2014. Il est temps de désactiver les versions antérieures à TLS 1.2.

Les principaux éditeurs de navigateurs web sont arrivés à la même conclusion. Mozilla devrait désactiver TLS 1.0 et TLS 1.1 dans la version 78 de Firefox qui devrait être publiée fin juin 2020 (source). Google devrait faire de même dans la version 84 de Chrome prévue pour fin juillet 2020 (source). Microsoft devrait suivre avec la version 84 d'Edge sui devrait être publiée en juillet 2020 (source) et avec un correctif pour la version 11 d'IE (source) qui devrait être publié en septembre 2020.

Côté emails, je déconseille de virer TLS 1.0 / 1.1, car des fournisseurs d'emails utilisent uniquement ces protocoles. Exemple : Orange utilise exclusivement TLS 1.0.

Le manuel d'OpenSSL indique qu'à partir de sa version 1.1.0, définir les protocoles est déprécié. Il vaut mieux préciser le plus petit protocole que l'on souhaite activer et, éventuellement, le plus grand. Source 1, source 2. Dovecot utilise nativement cette syntaxe. Avec Apache httpd, on peut se débrouiller ainsi : SSLOpenSSLConfCmd MinProtocol TLSv1.2. J'ai rien trouvé pour nginx, postfix et ejabberd.

Suites cryptographiques

Seuls 5 algorithmes de chiffrement symétrique + intégrité sont utilisables avec TLS 1.3 à l'heure actuelle. Il s'agit des plus robustes du moment, donc il n'y a pas de ménage à faire. Néanmoins, si l'on veut changer les suites de chiffrement utilisées dans une connexion TLS 1.3, comme l'API d'OpenSSL est différente pour gérer TLS 1.2 et TLS 1.3, il faut utiliser le paramètre « Ciphersuites » de la fonction « SSL_CONF_cmd » qui s'utilise ainsi avec Apache httpd : « SSLOpenSSLConfCmd Ciphersuites TLS_CHACHA20_POLY1305_SHA256 ». Je n'ai pas trouvé d'équivalent pour nginx, postfix, dovecot et ejabberd. Pour tester, il faut utiliser l'argument -ciphersuites de s_client.

En revanche, c'est le bazar complet avec les versions antérieures de TLS.

Dans l'idéal, on aimerait dégager tout ce qui n'inclut pas un échange de clés éphémères (EDH / EECDH) car c'est ce qui permet la confidentialité persistante (Perfect Forward Secrecy), le fait que des communications passées qui auraient été enregistrées ne pourront être déchiffrées, même si la clé privée du serveur est compromise. Cet objectif est atteignable, même sur le protocole emails : même mon serveur d'emails mutualisé n'a pas eu d'échanges sans confidentialité persistante sur l'année passée. Attention toutefois : ce serveur a peu d'utilisateurs et nos usages du numérique sont limitées (très peu de commerce en ligne, très très peu d'inscriptions sur des sites web, peu de sites web gouvernementaux).

Dans l'idéal, on voudrait aussi dégager SHA-1, car sa robustesse a pris de sacrés coups ces dernières années. Côté emails, ce n'est pas possible : des fournisseurs emails l'utilisent pour garantir l'intégrité d'une communication. Orange, par exemple.

Dans l'idéal, on voudrait aussi dégager tout ce qui n'est pas chiffrement intègre (AEAD) vu que ça a toujours été plus ou moins vulnérable (voir mon article sur TLS 1.3), mais, ce n'est pas possible pour l'email : l'utilisation de SHA-1 emporte l'utilisation de suites cryptographiques sans chiffrement intègre, par définition.

De nos jours, il vaut mieux privilégier EECDH à EDH (plus performant, prétendument plus robuste), mais je continue de privilégier EDH car je n'ai pas compris le problème mathématique insoluble sur lequel repose la cryptographie avec courbes elliptiques alors que j'ai compris le problème de la factorisation d'un très grand nombre en facteurs premiers. Néanmoins, des services emails, comme celui retenu par la CPAM imposent un échange de clés EECDH.

Au final :

• Sur un site web, un serveur Jabber, ou un serveur POP/IMAP personnel et insignifiant comme le mien, la configuration suivante est viable : suites de chiffrement = EDH:EECDH:!ECDSA:!DSS:!SHA1:!SHA256:!SHA384:@STRENGTH. Confidentialité persistante + authentification RSA + chiffrement intègre AES ou ARIA. Attention : si tu utilises un certificat x509 avec une clé de type courbes elliptiques, il faut remplacer « !ECDSA » par « !aRSA » ;
  
  
• Sur un serveur emails mutualisé mais insignifiant, la configuration suivante est viable : suites de chiffrement = EECDH:EDH:!ECDSA:!DSS:!PSK:!CAMELLIA:!SEED:!eNULL:@STRENGTH. Confidentialité persistante + authentification RSA + chiffrement intègre AES / ARIA ou AES / ARIA avec SHA-1 / SHA-256 / SHA-384. Attention : si tu utilises un certificat x509 avec une clé de type courbes elliptiques, il faut remplacer « !ECDSA » par « !aRSA ».

Relevons l'erreur qui se trouvait dans la configuration TLS de mon Postfix jusqu'en février 2020 :

smtpd_tls_security_level = may
smtpd_tls_mandatory_ciphers = medium
tls_medium_cipherlist = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXP, RC4, 3DES, MD5, LOW

J'active le chiffrement opportuniste (« may ») : le serveur indiquera qu'il accepte les connexions TLS, mais il ne rejettera pas les clients emails (les autres serveurs emails, concrètement) qui viendront lui causer. Pourtant, j'effectue la configuration des algorithmes cryptographiques dans les paramètres qui sont uniquement utilisés quand le chiffrement est obligatoire, c'est-à-dire quand la valeur de « smtpd_tls_security_level » est « encrypt ». Résultat, cette configuration est ignorée, sauf la dernière ligne, qui définit les algos à ne pas utiliser. Lorsque l'on active le chiffrement opportuniste, il faut utiliser le paramètre « smtpd_tls_ciphers » pour définir le niveau de sécurité des algorithmes de chiffrement utilisables. Si l'on configure la valeur de ce paramètre à « medium », il est possible de surcharger la liste des algos autorisés avec le paramètre « tls_medium_cipherlist ».

Au final, la même configuration, mais corrigée est celle-ci :comparée

smtpd_tls_security_level = may
smtpd_tls_ciphers = medium
tls_medium_cipherlist = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXP, RC4, 3DES, MD5, LOW

Courbes elliptiques utilisées dans les échanges EECDH

On aimerait choisir les courbes elliptiques utilisables lors des échanges EECDH des clés de session (utilisées pour effectuer le chiffrement symétrique). D'abord pour faire péter notre score sur Cryptcheck (dans la première version, la courbe elliptique la plus utilisée, prime256v1, avait une note faible liée à sa robustesse comparée à celle d'un algo symétrique), ensuite car la courbe P-256 aka prime256v1 aka secp256r1 a été normalisée au NIST (entre autres), organisme américain qui a aussi normalisé Dual_EC_DRBG, un générateur de nombres pseudo-aléatoires volontairement affaibli par la NSA, et qui a jamais publié le choix des paramètres de la courbe P-256. Un peu de diversité ne fait pas de mal.

À part les courbes d'organismes de normalisation fermés états-uniens, il existe les courbes X25519, Brainpool et X448. En pratique, X25519 a la plus grande part de marché. Brainpool a la plus petite, au point d'avoir été dégagée de TLS 1.3 pour cette raison avant d'y être ré-intégré en février 2020 (source). En pratique, s_client ou Firefox / Thunderbird préfère X25519 à tout autre courbe. s_client préfère X448 aux courbes du NIST, ce qui n'est pas le cas de Firefox / Thunderbird, qui acceptent uniquement X25519 ou les courbes du NIST (source : capture réseau + lecture du champ supported_groups dans une poignée de main TLS 1.2 ou 1.3). En TLS 1.2, s_client préfère basculer sur un échange EDH plutôt que de procéder à un échange EECDH utilisant Brainpool, c'est dire…

De plus, contrairement à la négociation des suites de chiffrement (voir ci-dessus) dans laquelle l'ordre des suites du serveur l'emporte sur celui du client, la négociation des courbes elliptiques dans un échange EECDH en TLS 1.3 semble être à la faveur d'un client quand X25519 est autorisé sur le serveur. Soit un client annonçant « X25519, P-256, X448, P-521, P-384 » dans son ClientHello. Côté serveur, même si X25519 est défini en dernier, il sera quand même choisi (même en utilisant « Options ServerPreference » de SSL_CONF_cmd). Si x25519 est totalement absent et que X448 vient avant P-256, alors X448 sera choisi (cette fois-ci, l'ordre du serveur importe) et le client reçoit un message « Hello Retry Request » lui demandant de renégocier. En TLS 1.2, l'ordre du serveur est parfaitement respecté.

Donc, en TLS 1.3, la présence de X25519 dans la liste des courbes autorisées par le serveur, même au fond de la liste, fera qu'il sera utilisé. Ne pas l'autoriser contraint l'utilisation des courbes du NIST (avec Firefox / Thunderbird, autre), ce qui est moins malin. Autoriser les courbes Brainpool sur le serveur a aucun effet, ni en TLS 1.3 ni en 1.2. Ne pas le faire n'encourage pas à la diversité.

Sur un serveur emails, la prise en charge de P-256 aka prime256v1 aka secp256r1 est nécessaire pour dialoguer avec certains fournisseurs d'emails, comme Microsoft.

Le serveur XMPP ejabberd ne permet pas encore de choisir les courbes elliptiques utilisables lors d'un échange EECDH. La négociation automatique est codée depuis 2017 dans la bibliothèque sous-jacente, mais rien semble permettre de définir la liste des courbes utilisables.

Au final :

• Sur un site web ou un serveur POP/IMAP personnel et insignifiant comme le mien, la configuration suivante est viable : supported groupes = X448:brainpoolP512r1:brainpoolP384r1:X25519:P-521:P-384. X448 pour un peu de variété crédible (les algorithmes de l'équipe du cryptographe djb, Curve25519 et ChaCha20+Poly1305 sont trop utilisés partout sans discernement, à mon goût), Brainpool pour une variété factice puisque elle très peu utilisée en pratique, et les courbes du NIST les plus robustes (en termes de comparaison avec la robustesse d'un algorithme symétrique) pour la compatibilité ;
  
  
• Sur un serveur emails mutualisé mais insignifiant, la configuration suivante est viable : supported groups = X448 brainpoolP512r1 brainpoolP384r1 X25519 P-521 P-384 P-256 (oui, ici il faut séparer les courbes avec des espaces…). J'ajoute P-256 afin de maintenir une compatibilité "à tout prix".

Groupes finis EDH

Définir certains paramètres mathématiques (comme le module) afin d'améliorer la sécurité, la compatibilité et la performance des échanges de clés EDH ? C'est l'objectif du RFC 7919 qui normalise des groupes finis pour EDH. Le but est d'éviter que les implémentations choisissent des paramètres vaseux et que l'interlocuteur ne puisse pas les refuser.

Au début, je me suis intéressé à ça afin de prioriser un échange EDH sur un échange EECDH dans TLS 1.3. En effet, par défaut, l'échange de clés se fait avec des courbes elliptiques (ECDHE). Définir les suites de chiffrement est vain puisqu'en TLS 1.3, elles indiquent uniquement les algorithmes de chiffrement et d'intégrité, plus l'échange de clés. La négociation des algorithmes EDH et EECDH se fait dans le champ « supported groups » des messages qui constituent une poignée de main TLS 1.3.

Dans un deuxième temps, je voulais résoudre la contradiction énoncée dans la section 6 du RFC 7919 (uniquement valable pour TLS < 1.3) : mon serveur propose uniquement des courbes elliptiques dans le champ TLS « supported groups » tout en proposant d'abord des suites de chiffrement EDH dans le champ « cipher suites ». La résolution automatique de cette contradiction est laissée à l'implémentation TLS utilisée côté serveur, d'après la norme, ce qui est jamais une bonne idée.

Le côté amélioration de la sécurité est sympa aussi, mais on est clairement en dehors du modèle de menace applicable à mes services… Comme tout le reste de ce shaarli, ceci dit…

Comme pour la définition des courbes elliptiques EECDH, OpenSSL permet d'indiquer les groupes finis EDH utilisables via la directive « Groups » de sa fonction SSL_CONF_cmd. Cette prise en charge a été codée en juin 2019 (source 1, source 2) et documentée en mai 2019 (source), mais elle n'est pas utilisable dans Debian à l'heure actuelle, y compris dans sid, sauf à utiliser le dépôt experimental.

ÉDIT DU 06/09/2022 : cette section est erronée. DH repose toujours des groupes finis. Ce que le RFC 7919 normalise, c'est des groupes DH prédéfinis choisis, en effet, pour leur robustesse mathématique. Les paramètres DH à groupes prédéfinis s'utilisent comme les autres paramètres DH, avec les mêmes directives de configuration. Donc, il n'y a pas lieu d'attendre une quelconque directive de configuration spécifique. Voir : Mise à jour de mes configurations TLS pour utiliser les paramètres Diffie-Hellman normalisés. FIN DE L'ÉDIT DU 06/09/2022.

Autre

On peut également définir les algorithmes et les schémas utilisables pour authentifier le pair et les messages d'initialisation de la connexion TLS.

C'est la directive « SignatureAlgorithms » de la fonction « SSL_CONF_cmd » qui s'utilise ainsi avec Apache httpd : « SSLOpenSSLConfCmd SignatureAlgorithms rsa_pss_pss_sha256 ». Je n'ai pas trouvé d'équivalent pour nginx, dovecot, postfix et ejabberd.

Avec TLS 1.3, il est obligatoire d'utiliser le schéma RSA PSS si l'on fait de l'authentification RSA des messages TLS, mais, l'ancien schéma RSA PKCS#1 1.5 reste utilisable pour l'authentification du pair, d'après la norme. Or, OpenSSL semble mélanger les deux : tenter d'utiliser le schéma RSA PKCS#1 1.5 dans SignatureAlgorithms conduit à l'échec de la connexion TLS.

Évidemment, il faut choisir un algorithme (liste à l'IANA) qui correspond à celui utilisé dans le certificat de ton serveur : inutile d'utiliser ed25519 avec un certificat x509 signé avec RSA+SHA256.

Je vois peu l'intérêt de la manip', à part pour forcer l'utilisation du schéma RSA PSS avec TLS 1.2. Avec Apache httpd, je fais ça avec « SSLOpenSSLConfCmd SignatureAlgorithms rsa_pss_rsae_sha256:rsa_pss_pss_sha256 ». Cependant, beaucoup de clients seront exclus d'après le testeur SSLLabs. Même SSLLabs et Cryptcheck ne parviennent pas à discuter en TLS 1.2 + RSA PSS. :D Donc, il faut impérativement supporter PKCS#1 1.5 en dernier ressort avec SSLOpenSSLConfCmd SignatureAlgorithms rsa_pss_rsae_sha256:rsa_pss_pss_sha256:rsa_pkcs1_sha256.

Mes configurations TLS 2020

Apache httpd

# TLS 1.2 + TLS 1.3 uniquement
SSLOpenSSLConfCmd MinProtocol TLSv1.2

# Confidentialité persistante + authentification RSA + chiffrement symétrique AEAD (AES et ARIA)
# Le choix du serveur l'emporte sur celui du client
SSLCipherSuite EDH:EECDH:!ECDSA:!DSS:!SHA1:!SHA256:!SHA384:@STRENGTH
SSLHonorCipherOrder on

# Paramètres EDH 4096 bits (3072 saurait suffisant, ne pas aller en dessous)
SSLOpenSSLConfCmd DHParameters "/etc/apache2/ssl/dh_4096.pem"
# Courbes elliptiques EECDH
SSLOpenSSLConfCmd ECDHParameters Automatic
SSLOpenSSLConfCmd Groups X448:brainpoolP512r1:brainpoolP384r1:X25519:P-521:P-384

# Désactivation de la compression TLS (pour TLS 1.2). Déjà désactivée par défaut.
# SSLCompression off

# Cache partagé des sessions TLS : activé par défaut (module ssl dépend du module socache_shmcb)
# SSLSessionCacheTimeout 300

# Prioriser l'utilisation du schéma RSA-PSS (PKCS#1 version 2.1)
SSLOpenSSLConfCmd SignatureAlgorithms rsa_pss_rsae_sha256:rsa_pss_pss_sha256:rsa_pkcs1_sha256

# Si certificat x509 signé par une autorité de certification publique, activer OCSP stapling 
# (http://shaarli.guiguishow.info/?bbeKhg) afin de respecter la vie privée des visiteurs
# (http://shaarli.guiguishow.info/?SgQmAA)
# SSLCACertificateFile </chemin/vers/cert/CA.pem>
# SSLUseStapling on

# Journaliser des informations plus détaillées sur les connexions TLS entrantes échouées.
# Pas possible

nginx

# TLS 1.2 + TLS 1.3 uniquement
ssl_protocols TLSv1.2 TLSv1.3;

# Confidentialité persistante + authentification RSA + chiffrement symétrique AEAD (AES et ARIA)
# Le choix du serveur l'emporte sur celui du client
ssl_ciphers EDH:EECDH:!ECDSA:!DSS:!SHA1:!SHA256:!SHA384:@STRENGTH;
ssl_prefer_server_ciphers on;

# Paramètres EDH 4096 bits (3072 saurait suffisant, ne pas aller en dessous)
ssl_dhparam /etc/nginx/ssl/dh_4096.pem;
# Courbes elliptiques EECDH
ssl_ecdh_curve X448:brainpoolP512r1:brainpoolP384r1:X25519:P-521:P-384;

# Compression TLS (pour TLS 1.2) totalement désactivée dans nginx

# Cache partagé des sessions TLS. Le site web servi par ce serveur nginx affiche une page blanche (sans CSS)
# et permet à des connaissance de télécharger quelques fichiers. Je n'ai pas de
# visiteurs réguliers. Il est inutile d'activer la réouverture de session TLS ainsi que le cache qui va avec.
ssl_session_cache off;

# Prioriser l'utilisation du schéma RSA-PSS (PKCS#1 version 2.1)
# Je n'ai pas trouvé le paramètre KiVaBien

# Si certificat x509 signé par une autorité de certification publique, activer OCSP stapling 
# (http://shaarli.guiguishow.info/?bbeKhg) afin de respecter la vie privée des visitteurs
# (http://shaarli.guiguishow.info/?SgQmAA)
# ssl_trusted_certificate </chemin/vers/cert/CA.pem>
# ssl_stapling on;
# ssl_stapling_verify on;

# Journaliser des informations plus détaillées sur les connexions TLS entrantes échouées.
# Pas possible

Postfix

## Serveur

# Chiffrement opportuniste (si pas possible, on accepte de recevoir en clair)
smtpd_tls_security_level = may

# Pas d'authentification tant qu'on n'a pas établie une connexion TLS
smtpd_tls_auth_only = yes

# TLS 1.0 + TLS 1.1 + TLS 1.2 + TLS 1.3, car des fournisseurs d'emails ont besoin de TLS 1.0 (Orange, par exemple)
smtpd_tls_protocols = !SSLv2, !SSLv3

# Confidentialité persistante + authentification RSA + chiffrement intègre (AES ou ARIA) ou AES / ARIA avec SHA-1 / SHA-256 / SHA-384.
# Des fournisseurs d'emails exigent que EECDH soit prioritaire sur EDH, genre Worldline qui opère pour le compte de la CPAM
# Le choix du serveur l'emporte sur celui du client
smtpd_tls_ciphers = medium
tls_medium_cipherlist = EECDH:EDH:!ECDSA:!DSS:!PSK:!CAMELLIA:!SEED:!eNULL:@STRENGTH
tls_preempt_cipherlist = yes

# Paramètres EDH 4096 bits (3072 saurait suffisant, ne pas aller en dessous)
smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_4096.pem
# Courbes elliptiques EECDH
# Des fournisseurs d'emails exigent P-256, comme Microsoft
# Cela s'applique aussi au client SMTP
smtpd_tls_eecdh_grade = auto
tls_eecdh_auto_curves = X448 brainpoolP512r1 brainpoolP384r1 X25519 P-521 P-384 P-256

# Désactivation de la compression TLS (pour TLS 1.2)
# Cela s'applique aussi au client SMTP
tls_ssl_options = NO_COMPRESSION

# Cache partagé des sessions TLS. Par défaut, une session expire au bout d'une heure
# Pratique pour les échanges rapides avec un même destinataire genre une liste de discussion ou un même interlocuteur
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_tls_cache

# Prioriser l'utilisation du schéma RSA-PSS (PKCS#1 version 2.1)
# Je n'ai pas trouvé le paramètre KiVaBien

# Pas de prise en charge d'OCSP stapling

# Journaliser des informations plus détaillées sur les connexions TLS entrantes
smtpd_tls_loglevel = 1

##  Client

# J'utilise DANE TLSA (http://shaarli.guiguishow.info/?M3y2yQ)
# Cela peut parfois faire chier (http://shaarli.guiguishow.info/?tQqSHw)
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

# La doc' dit « For purposes of protocol and cipher selection, the "dane" security level is treated
# like a "mandatory" TLS security level ». 
# On fait pointer la liste de suites de chiffrement de ce niveau de sécurité sur tls_medium_cipherlist 
# défini plus haut avec mandatory = medium
smtp_tls_mandatory_protocols = $smtpd_tls_protocols
smtp_tls_mandatory_ciphers = medium

# Les courbes utilisables lors d'un échange EECDH sont configurées dans la partie serveur

# La compression TLS est désactivée dans la partie serveur

# Cache partagé des sessions TLS. Par défaut, une session expire au bout d'une heure
smtp_tls_session_cache_database = btree:${data_directory}/smtp_tls_cache

# Journaliser des informations plus détaillées sur les connexions TLS sortantes
smtp_tls_loglevel = $smtpd_tls_loglevel

Dovecot

# TLS est obligatoire avant tout échange
ssl = required

# TLS 1.2 + TLS 1.3 uniquement
ssl_min_protocol = TLSv1.2

# Confidentialité persistante + authentification RSA + chiffrement symétrique AEAD (AES et ARIA)
# Le choix du serveur l'emporte sur celui du client
ssl_cipher_list = EDH:EECDH:!ECDSA:!DSS:!SHA1:!SHA256:!SHA384:@STRENGTH
ssl_prefer_server_ciphers = yes

# Paramètres EDH 4096 bits (3072 saurait suffisant, ne pas aller en dessous)
ssl_dh   = </etc/dovecot/ssl/dh_4096.pem
# Courbes elliptiques EECDH
ssl_curve_list = X448:brainpoolP512r1:brainpoolP384r1:X25519:P-521:P-384

# Désactivation de la compression TLS (pour TLS 1.2). Déjà désactivée par défaut.
# ssl_options  = no_compression

# Cache partagé des sessions TLS. Pas pertinent, un seul utilisateur, qui se moque de la performance

# Prioriser l'utilisation du schéma RSA-PSS (PKCS#1 version 2.1)
# Je n'ai pas trouvé le paramètre KiVaBien

# Pas de prise en charge d'OCSP stapling

# Pas de journalisation détaillée des connexions TLS entrantes échouées

Ejabberd

# TLS est obligatoire avant tout échange
s2s_use_starttls: required

define_macro:
  # Confidentialité persistante + authentification RSA + chiffrement symétrique AEAD (AES et ARIA)
  'TLS_CIPHERS': "EDH:EECDH:!ECDSA:!DSS:!SHA1:!SHA256:!SHA384:@STRENGTH"
  # Paramètres EDH 4096 bits (3072 saurait suffisant, ne pas aller en dessous)
  'DH_FILE': "/etc/ejabberd/ssl/dh_4096.pem"
  # Impossible pour l'instant de préciser les courbes elliptiques utilisables lors d'un échange EECDH
  'TLS_OPTIONS':
    # TLS 1.2 ou TLS 1.3 uniquement
    - "no_sslv3"
    - "no_tlsv1"
    - "no_tlsv1_1"
    # En matière d'algorithmes de chiffrement, le choix du serveur l'emporte sur celui du client
    - "cipher_server_preference"
    # Désactivation de la compression TLS
    - "no_compression"

c2s_ciphers: 'TLS_CIPHERS'
s2s_ciphers: 'TLS_CIPHERS'
c2s_protocol_options: 'TLS_OPTIONS'
s2s_protocol_options: 'TLS_OPTIONS'
c2s_dhfile: 'DH_FILE'
s2s_dhfile: 'DH_FILE'

# Cache partagé des sessions TLS. Pas pertinent, un seul utilisateur, qui se moque de la performance

# Prioriser l'utilisation du schéma RSA-PSS (PKCS#1 version 2.1)
# Je n'ai pas trouvé le paramètre KiVaBien

# Pas de journalisation détaillée des connexions TLS entrantes échouées

Résumé : si l'interface graphique d'Ubuntu se gèle pendant son installation dans une machine virtuelle KVM + virt-manager, soit tu la laisses se terminer en la surveillant avec iotop sur l'hôte (quand il n'y a plus d'écritures, l'installation est terminée), soit tu affectes, à la machine virtuelle, un modèle de CPU « kvm64 » ou un modèle supporté par ton CPU réel / physique.

L'installation d'Ubuntu dans une machine virtuelle KVM (+ interface graphique virt-manager, donc libvirt) sur mes ordinateurs a jamais trop fonctionné.

Avec la version 18.10, l'installeur se gelait lors de la saisie du nom d'utilisateur. Le pointeur de la souris bougeait, mais l'interface graphique ne réagissait plus.

Avec la version 20.04, l'installeur se gèle aux trois quarts de la copie des fichiers. Le pointeur de la souris bouge, mais l'interface graphique ne réagit plus. L'heure n'avance plus. Le diaporama des fonctionnalités essentielles d'Ubuntu (lecteur multimédia, communauté, accessibilité, etc.) ne se déroule pas. Sur l'hôte, un iotop montre que la machine virtuelle écrit toujours sur son disque dur. Si l'on attend la fin des écritures puis que l'on redémarre la machine virtuelle, le système Ubuntu installé fonctionne parfaitement. C'est donc uniquement un problème d'interface graphique gelé.

Dans virt-manager, je choisis bien « Ubuntu 18.04 LTS » (j'ai pas plus récent) comme système d'exploitation, car je sais que ça active / désactive des paramètres en douce et que ça conseille des valeurs plutôt sensées pour la quantité de RAM et autres. J'alloue deux cœurs CPU et 2 Go de RAM à la machine virtuelle. Allouer 4 Go de RAM (le reste demeure inchangé) change rien. J'utilise un disque dur VirtIO de 20 Go dynamique, rien de folichon.

Par le plus grand des hasards, j'ai trouvé une solution : il faut changer le modèle de CPU de la machine virtuelle. Par défaut, « copier la configuration du processeur de l'hôte » est coché dans la rubrique « Configuration » de l'item « Processeurs » dans les paramètres de la machine virtuelle. Mais, si l'architecture du CPU hôte n'est pas disponible, virt-manager va en choisir une autre lors du démarrage de la machine virtuelle. Sur mon ordinateur équipé d'un Intel Core i5-4200M (architecture Haswell), virt-manager choisit une architecture « Haswell-noTSX ». Sur mon ordinateur équipé d'un Intel Core i5-7300HQ (architecture Kaby Lake), virt-manager choisit une architecture « Skylake-client ». Dans les deux cas, l'interface graphique de l'installeur d'Ubuntu 20.04 se fige.

Dans les deux cas, choisir un modèle de CPU « kvm64 » ou « IvyBridge » (sur le i5-7300HQ) résout ce problème.