GuiGui's Show

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.

Rappel : si une instruction blacklist <nom_module> ajoutée dans /etc/modprobe.d/blacklist.conf (ou autre fichier .conf dans le même dossier) n'empêche pas le chargement d'un module dans le noyau Linux, on peut utiliser l'instruction install <nom_module> /bin/true. J'avais oublié.

Quelle différence ? Un module a un nom présentable (genre « uvcvideo ») et des noms techniques qui correspondent aux matériels pris en charge par le module (exemple : « usb:v0416pA91Addcdscdpic0Eisc01ip00in* » est la désignation technique d'un ensemble de caméras USB pris en charge par le module uvcvideo).

blacklist a pour effet d'inhiber les noms techniques. Donc, quand Linux détecte un matériel, il cherche dans les modules, il ne trouve pas de nom qui correspond au matériel, donc il ne charge pas le module (pourtant présent sur le système), donc le matériel n'est pas activé / pris en charge. En revanche, si le module est désigné par son nom présentable par un autre module ou par l'administrateur système (modprobe <nom_module>), alors il sera chargé.

install permet de faire exécuter une commande au lieu de charger un module. Tout le temps. Même si le module est appelé par son nom présentable par l'adminsys ou par un autre module.

Commande pour vérifier que modprobe a bien pris en compte une configuration déposée dans /etc/modprobe.d/ : modprobe --showconfig. C'est très verbeux, donc il faut y aller à coup de grep.

Il n'est pas forcément nécessaire de reconstruire l'initrd (avec update-initramfs -vuk <version_noyau>) après l'exclusion d'un module. C'est utile uniquement si l'initrd est susceptible de charger ledit module, donc plutôt sur les modules de matériels (pas vboxnetflt, le module "réseau pont" de VirtualBox, par exemple) nécessaires au boot (pas uvcvideo pour une caméra USB, par exemple).

Bien joué pour l'analyse du problème. :)

Le PC-P de @Lenny tout comme le mien ont une partition Ext4 chiffrée ! Or mon PC Fixe a une partition en clair et il faut savoir qu'une partoche Ext4 en claire permet des chemins de fichiers de 255 caractères tandis qu'une Ext4 chiffrée est limitée à 143 caractères ! Le voilà notre coupable...

Quel procédé utilises-tu pour chiffrer ta partition ext4 ?

Pour ma part, j'utilise dm_crypt+luks et je peux utiliser les 255 octets (oui, octets, pas caractères : si tu mets un caractère Unicode dans un nom de fichier, tu perds 2 octets alors qu'un seul caractère est affiché) autorisés par ext4 pour un nom de fichier. La longueur maximale du chemin d'un fichier permise par ext4 est de 4 096 octets. C'est logique que dm_crypt ne réduise pas cette limite d'ext4 car il se place au-dessous de tout système de fichiers.

J'en déduis que t'utilises probablement une surcouche cryptographique aux systèmes de fichiers comme EncFS ou eCryptfs. La limite que tu rencontres viendrait donc de cette surcouche cryptographique, pas du fait que tu utilises de la crypto (regarde, j'en fais et je conserve la limite de 255 octets).

Grâce à toi, j'ai découvert qu'ext4 propose le chiffrement natif. J'ai essayé viteuf : c'est bien bien bien le bazar. La taille maximale du nom d'un fichier est toujours de 255 caractères.

J'ai voulu signaler leur problème DNS à la Banque Populaire et à la Caisse d'Épargne, mais impossible de leur envoyer un email.

Le serveur emails pour tous les domaines dont font partie les adresses emails techniques trouvées dans les bases de données publiques accessibles avec le protocole whois (et bientôt RDAP ?) est mail-in.bpce-it.fr.

Celui-ci refuse mes emails pour le motif suivant : « 550 #5.7.5 DKIM unauthenticated mail is prohibited. If you believe that this failure is in error, please refer to https://tools.ietf.org/html/rfc6376 or contact postmaster [à] bpce-it.fr for more information via alternate means. »

J'ai bien envoyé mon courriel via le seul serveur emails autorisé pour mon domaine.

Étrangement, un email envoyé par Stéphane depuis un domaine qui n'implémente pas DKIM passe très bien. Cela illustre que DKIM n'est pas obligatoire pour communiquer avec BPCE. Peut-être qu'une signature DKIM devient obligatoire quand la réputation de l'adresse IP ou du réseau du serveur emails émetteur est questionnable ? Mon serveur est hébergé chez OVH, émetteur de spam malgré lui, alors que celui de Stéphane est dans un réseau IP de bonne réputation.

Encore plus étrange : mes emails sont bien signés en suivant la norme DKIM. Peut-être y a-t-il un problème technique de mon côté ?

Je m'envoie un email à une autre adresse que je gère et qui met en œuvre la validation DKIM : à l'arrivée, les entêtes de l'email confirment qu'il comporte bien une signature DKIM et que celle-ci est valide : « Authentication-Results: viki.guiguishow.info; dkim=pass (3072-bit key; secure) header.d=[CENSURE] header.i=@[CENSURE] header.b="PGTxFJuT"; dkim-atps=neutral ».

Il existe des testeurs de serveur emails. J'en ai utilisé trois (plus que ça en vrai, mais certains ne fonctionnent plus) : https://www.mail-tester.com/ , auth-results [à] verifier.port25.com , et ping [à] stamper.itconsult.co.uk . Tous les trois confirment la présence et la validité d'une signature DKIM dans mes emails sortant. Il semble donc que le problème est du côté de BPCE.

De plus, j'ai configuré une politique ADSP souple, « dkim=all » qui signifie "normalement, tout courriel émanant de ce domaine sera signé, mais si ce n'est pas le cas, ne le jete pas à la corbeille, stp". Évidemment, elle a la valeur d'un conseil : le récepteur fait bien ce qu'il veut.

Pour signer les entêtes de mes emails sortants, mon serveur emails utilise une clé RSA 3072 bits. C'est la taille recommandée par l'ANSSI (document B1) pour mettre sérieusement en pratique de la cryptographie au long terme. Mais, c'est vrai que, pour signer des emails dans le cadre de la lutte anti-spam (c'est l'objet de DKIM), une clé de taille inférieure serait suffisante. Néanmoins, début 2018, le RFC 8301 a mis à jour le RFC de DKIM (6376) : « Signers SHOULD use RSA keys of at least 2048 bits. Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. ».

Je conçois bien un problème à ce niveau-là : ma clé est rejetée en raison de sa taille, donc mon email est considéré comme étant non signé, donc, soit la réputation du réseau de mon serveur emails joue contre lui, soit BPCE-IT est intransigeant avec les domaines qui ont une politique ADSP fut-elle souple. Cette hypothèse a été confirmée par BPCE-IT : « […] en raison d’une limitation de notre produit actuel, nous ne pouvons pas vérifier de signature au-dessus de 2048 bits et il ne connait pas la notion de politique ADSP. Ainsi la signature 3072 bits est traitée en erreur […] ».

A priori, ce souci a été signalé à BPCE-IT par Stéphane, merci. :)

Depuis au moins jeudi 28 mai 2020 à 22 h 45 (UTC+2), impossible d'accéder à certains sites web du groupe Banque Populaire Caisse d'Épargne :

• https://www.banquepopulaire.fr ne fonctionne pas (vitrine + SSO) ;
  
  
• https://www.ibps.loirelyonnais.banquepopulaire.fr ou https://www.ibps.bpaca.banquepopulaire.fr ou https://www.ibps.mediterranee.banquepopulaire.fr/ ne fonctionnent pas (accès à l'espace personnel) ;
  
  
• https://groupebpce.com/ fonctionne.
  
  
• ÉDIT DU 31/05/2020 À 14 H 05 : www.caisse-epargne.fr est également impacté, voir Problème DNS BPCE : la Caisse d'Épargne également impactée. FIN DE L'ÉDIT DU 31/05/2020.

Qu'est-ce qui ne fonctionne pas, précisément ? La résolution des noms DNS. Mon navigateur web Mozilla Firefox affiche « Recherche de […] » puis « Hum, nous ne parvenons pas à trouver ce site. ».

Comme d'habitude, Twitter fournit des témoignages dont le plus savoureux relate :

Bonjour @BanquePopulaire impossible de se connecter avec l’application sur iPhone depuis hier soir et donc de déverrouiller ma carte bancaire... C’est un problème général?

À quel moment tu t'es dit que c'est génial de débloquer une carte bancaire avec un logiciel pour ordinateur de poche ?! Tout peut foirer ! Ton ordinateur de poche peut tomber en panne, ton opérateur de téléphonie mobile aussi, un opérateur Internet de transit idem, Banque Populaire également, etc. Ce choix d'une telle dépendance à une technologie est hallucinant.

J'ai mon accès à Internet fixe chez le Fournisseur d'Accès à Internet associatif FDN et j'utilise les serveurs DNS récursifs de ce dernier. Le problème est le même depuis un serveur OVH (en utilisant les serveurs DNS récursifs d'OVH). Le service de résolution des noms de CloudFlare parvient jamais à résoudre le nom. Celui de Google y parvient plutôt souvent, mais il y a encore des ratés. Depuis un accès à Internet Orange avec un dnsmasq local, ça fonctionne difficilement ou pas du tout.

La transmission réseau entre FDN (ou OVH ou Orange) et le réseau Banque Populaire est OK : un mtr -T -P 443 91.135.183.174 montre ni incident réseau ni perte de paquets.

Le niveau applicatif est OK : un openssl s_client -connect 91.135.183.174:443 -crlf permet de dialoguer en HTTPS avec l'un des serveurs de la Banque Populaire. Une mesure depuis le réseau RIPE Atlas confirme cela, voire la mesure numéro 25558553.

Enfin, ajouter une association IP pour les noms www.ibps.bpaca.banquepopulaire.fr et www.banquepopulaire.fr dans mon fichier /etc/hosts rend ces sites web parfaitement fonctionnels. Attention : utiliser ce contournement uniquement pour des tests ! Si Banque Populaire change les adresses IP de ses services, la surcharge locale rendra inaccessibles les services.

On confirme donc un problème de résolution de certains des noms DNS de la Banque Populaire.

Néanmoins, mes mesures avec le réseau RIPE Atlas montre un faible taux d'échec de la résolution DNS : mesure numéro 25556510, mesure numéro 25556573 et mesure numéro 25556574.

Effectuons la résolution DNS à la main :

$ dig @d.nic.fr www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
banquepopulaire.fr.        172800        IN        NS        dns2.bpce.fr.
banquepopulaire.fr.        172800        IN        NS        dns1.bpce.fr.

;; ADDITIONAL SECTION:
dns1.bpce.fr.                172800        IN        A        91.135.189.110
dns2.bpce.fr.                172800        IN        A        91.135.177.110
[…]

$ dig @91.135.189.110 www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.ibps.bpaca.banquepopulaire.fr. 3600        IN NS
nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.177.110 www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.ibps.bpaca.banquepopulaire.fr. 3600        IN NS
nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.182.250 www.ibps.bpaca.banquepopulaire.fr
[…]
;; ANSWER SECTION:
www.ibps.bpaca.banquepopulaire.fr. 30 IN A        91.135.183.174
[…]

$ dig @91.135.189.110 www.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.banquepopulaire.fr.        3600        IN        NS        nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.177.110 www.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.banquepopulaire.fr.        3600        IN        NS        nsisp1.i-bp.banquepopulaire.fr.

;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr.        300 IN        A        91.135.182.250
[…]

$ dig @91.135.182.250 www.banquepopulaire.fr 
[…]
;; ANSWER SECTION:
www.banquepopulaire.fr.        30        IN        A        91.135.183.180
www.banquepopulaire.fr.        30        IN        A        91.135.183.180
[…]

$ dig @k.gtld-servers.net. groupebpce.com
[…]
;; AUTHORITY SECTION:
groupebpce.com.                172800        IN        NS        dns1.bpce.fr.
groupebpce.com.                172800        IN        NS        dns2.bpce.fr.
[…]

$ dig @91.135.189.110 groupebpce.com
[…]
;; ANSWER SECTION:
groupebpce.com.                3600        IN        A        151.101.194.133
groupebpce.com.                3600        IN        A        151.101.2.133
groupebpce.com.                3600        IN        A        151.101.66.133
groupebpce.com.                3600        IN        A        151.101.130.133
[…]

$ dig @91.135.177.110 groupebpce.com
[…]
;; ANSWER SECTION:
groupebpce.com.                3600        IN        A        151.101.130.133
groupebpce.com.                3600        IN        A        151.101.66.133
groupebpce.com.                3600        IN        A        151.101.2.133
groupebpce.com.                3600        IN        A        151.101.194.133
[…]

On constate trois choses :

• Les noms www.ibps.*.banquepopulaire.fr, www.*.banquepopulaire.fr et www.banquepopulaire.fr sont délégués à un seul serveur de noms DNS qui fait autorité ! C'est une très mauvaise pratique !
  
  
• Le nom corporate (présentation du groupe), groupebpce.com, dispose d'une qualité de service supérieure à celle des noms utilisés par les clients de la Banque Populaire (pour consulter leurs comptes, entrer en contact avec leur conseillère, etc.) : deux serveurs de noms, de multiples adresses IPs sur lesquelles récupérer le contenu du site web, etc. Amusant. Ça expose les priorités. Ça explique pourquoi je parviens à accéder au site web https://groupebpce.com tout en ne parvenant pas à accéder au site web de ma banque régionale Banque Populaire ;
  
  
• Un TTL (durée de vie de l'information associée à un nom DNS dans le cache des serveurs récursifs) très court (30 secondes). Si un tel délai est très utile lors d'une migration afin de rendre la bascule effective sous un court délai, il est très déconseillé le reste du temps, car, ne bénéficiant pas des caches, le moindre problème technique entraînera une panne d'une toute autre ampleur.

Jusque-là, le problème reste entier. Continuons à creuser.

Le serveur qui fait autorité pour les zones www.ibps.*.banquepopulaire.fr et www.banquepopulaire.fr , nsisp1.i-bp.banquepopulaire.fr , répond négativement aux requêtes de types NS et SOA :

$ dig @91.135.182.250 SOA www.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17798
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 NS www.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 36129
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 SOA www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31905
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig @91.135.182.250 NS www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17813
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

Cela est totalement contraire à la norme DNS et cela peut bloquer certaines implémentations de récursifs DNS (voire certaines versions d'une même implémentation), ce qui explique le côté aléatoire de la panne.

Les serveurs DNS dns1.bpce.fr et dns2.bpce.fr répondent aux requêtes de types NS et SOA pour la zone groupebpce.com, ce qui explique que le site web corporate fonctionne là où les autres sites web ne fonctionnent pas.

Le serveur DNS nsisp1.i-bp.banquepopulaire.fr ne répond pas aux requêtes DNS émises au-dessus du protocole TCP :

$ dig +tcp @91.135.182.250 A www.banquepopulaire.fr
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +tcp @91.135.182.250 A www.banquepopulaire.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.

C'est, là encore, totalement contraire à la norme DNS : tout serveur DNS doit être accessible sur udp/53 et tcp/53.

Cette absence de réponse aux requêtes de types SOA/NS posera encore plus de problèmes aux récursifs DNS qui implémentent la qname minimisation, un mécanisme qu'il faut activer car il participe à la préservation de la vie privée des utilisateurs d'un serveur DNS récursif. En effet, une divergence d'interprétation de la norme existe concernant la recherche des délégations. On rappelle au passage qu'une délégation DNS ne se voit pas à l'œil nu. Exemples : bpaca.banquepopulaire.fr n'est pas délégué par banquepopulaire.fr, ibps.bpaca.banquepopulaire.fr n'est pas non plus délégué par bpaca.banquepopulaire.fr. Bref : un point entre deux labels d'un nom de domaine ne marque pas forcément une délégation. Afin d'identifier les délégations, certaines implémentations, comme Unbound, effectuent des requêtes de type A (que le serveur DNS nsisp1.i-bp.banquepopulaire.fr accepte, pour rappel), d'autres des requêtes de type NS (qui sont refusées par nsisp1.i-bp.banquepopulaire.fr).

Concernant l'amplification du problème par certaines implémentations de qname minimisation dans les serveurs DNS récursifs , le mystère continue, car :

$ dig +short @80.67.169.40 version.bind chaos txt
"unbound 1.6.0"

$ dig +short @80.67.169.12 version.bind chaos txt
"unbound 1.9.0"

$ dig +short @::1 version.bind chaos txt
"unbound 1.9.0"

$ dig +short @80.67.169.12 www.ibps.bpaca.banquepopulaire.fr
;; connection timed out; no servers could be reached

$ dig @80.67.169.12 www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33639
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]

$ dig +short @::1 www.ibps.bpaca.banquepopulaire.fr
91.135.183.174

En clair : une même version d'Unbound œuvrant sur le même réseau IP, deux comportements différents. Que j'active ou non la qname-minimisation sur mon Unbound local (sur mon accès à Internet fixe FDN, donc), ça fonctionne. Peu importe le type de qname-minimisation, souple ou stricte.

Même chose avec un BIND9.16 sur mon accès à Internet FDN : quelle que soit la configuration retenue pour la qname-minimisation (« strict » ou « relaxed »), ça fonctionne. J'ai réussi à obtenir un « SERVFAIL » en mode « relaxed », mais je n'arrive pas à le reproduire sur demande (même en redémarrant BIND, même en le stoppant+rallumant).

Dans le sens inverse, on peut exposer que le résolver de CloudFlare implémente la qname-minimisation (source) et que, justement, il ne parvient pas à résoudre les noms de la Banque Populaire sus-mentionnés.

Bref, on peut affirmer tout et son contraire.

Mais, pourquoi les sondes du réseau RIPE Atlas ne remontent-elles pas un taux d'échec de la résolution DNS plus élevé ? Concentration des serveurs DNS récursifs utilisés. Au sein d'un même réseau, celui d'Orange par exemple, tous les clients (au sens commercial du terme) vont utiliser le même serveur DNS récursif, celui d'Orange (ou celui de Google Public DNS ou celui de CloudFlare). Si le serveur DNS récursif parvient à résoudre le nom une fois, toutes les sondes Atlas situées dans ce réseau en bénéficieront le temps du TTL (durée de rétention de l'information dans le cache du serveur récursif, 30 secondes dans le cas présent). Rappelons que les serveurs DNS récursifs de certains réseaux, comme Free, sont connus pour ré-écrire les TTL jugés courts (les ignorer, donc), ce qui permet de limiter l'ampleur de l'effet "ça marche, ça marche plus, ça marche, etc.".

Les TTL courts amplifient l'aspect "ça marche, ça marche plus".

Alors, au final, quelle est l'origine du problème ?

Difficile à dire. On le saura jamais vraiment, toute entité (société commerciale, administration, association, personne) étant toujours très réticente à faire des retours sur ses erreurs / fautes / échecs.

Je pense qu'il y a une middlebox entre Internet et le serveur DNS qui fait autorité nsisp1.i-bp.banquepopulaire.fr qui, comme tout boîtier externalisé prétendument magique imposé au service informatique par la direction afin qu'elle puisse prétendre œuvrer pour la sécurité des clients sans investir ni comprendre / maîtriser la technique sous-jacente, doit bloquer certaines requêtes DNS de manière excessive (sur-blocage). Qu'est-ce qui me fait penser cela ? L'implémentation de serveur qui fait autorité est un BIND 9.11.5-P4 (dig @91.135.182.250 CH TXT version.bind ;) ). Ce logiciel refuse de charger une zone DNS dénuée de NS/SOA (« zone [CENSURE]/IN: has 0 SOA records […] zone [CENSURE]/IN: has no NS records […] zone [CENSURE]/IN: not loaded due to errors. »), donc, si l'on a des réponses, sauf pour les types NS et SOA, c'est probablement un intermédiaire entre nous et le serveur qui les vire.

Néanmoins, ça n'explique pas l'intégralité du problème. Pourquoi deux serveurs récursifs DNS avec la même version d'Unbound ne parviennent pas au même résultat ? Pourquoi la plupart des serveurs DNS récursifs de la planète parviennent à résoudre les noms de la Banque Populaire ? Les différentes implémentations de qname-minimisation amplifient-elles le problème ? Aucune idée…

La Banque Populaire est coutumière d'une configuration DNS défectueuse.

En 2015, le nom banquepopulaire.fr était délégué à deux serveurs de noms Orange Business Services (ex Oléane) qui n'étaient pas configurés pour ce nom (on nomme ça une lame delegation). Les deux autres serveurs DNS qui font autorité étaient internes au groupe BPCE et cessaient de répondre aux requêtes (UDP et TCP) au moins une fois par semaine, et notamment le dimanche matin entre 11 h et 12 h. Amusant, non ?

Comme ces derniers jours, il y avait des tweets (notamment celui-ci), mais ça n'a pas suffit. Stéphane Bortzmeyer et moi-même avons envoyé des emails à toutes les adresses BPCE pertinentes trouvées. Il a fallu deux mois avant d'avoir un acquittement (email acquitté le 24/08) et plusieurs mois pour que le problème soit corrigé…

Merci à Stéphane Bortzmeyer de m'avoir expliqué l'origine probable de cette panne partielle. L'outil dnsviz m'avait bien pointé l'absence de réponse aux requêtes de type SOA/NS de la part du serveur nsisp1.i-bp.banquepopulaire.fr , mais je ne l'ai pas interprété correctement.

Le protocole TLS 1.3 a été publié en 2018. Ce protocole permet de sécuriser (confidentialité, authentification, intégrité) les communications sur Internet de tout type (web, emails, messagerie instantanée, téléphonie, etc.) de point à point (d'un client à un serveur, par opposition à un chiffrement de bout en bout, c'est-à-dire d'un internaute à un autre). Pour plus d'infos sur TLS 1.3, voir le billet de blog de tonton Bortzmeyer, l'article Prise en main de TLS 1.3 avec OpenSSL 1.1.1 publié dans le numéro 226 de GLMF et l'article RFC 8446 - TLS 1.3 : que faut-il attendre de cette nouvelle version ? publié dans le numéro 105 de MISC.

Pour ma part, je retiens :

• Grand nettoyage :

  • RSA n'est plus utilisable pour échanger des clés de session (nécessaires pour le chiffrement symétrique), donc il reste uniquement des échanges de clés DH qui garantissent la confidentialité persistante / future ;
    
    
  • Tous les algos démodés / foireux (RC4, algos de chiffrement par bloc dits CBC, MD5, SHA-1, etc.) dégagent. Il reste cinq suites cryptographiques (dont trois sont activées par défaut dans OpenSSL), toutes basées sur le chiffrement intègre (AEAD) afin de pallier aux attaques à texte choisi contre les algos CBC (genre BEAST) et aux attaques par rembourrage contre la manière d'implémenter la preuve d'intégrité dans les algos CBC (la dénommée Mac-then-Pad-then-Encrypt, voir l'article de tonton Bortz) genre POODLE, même si une extension TLS permet depuis plusieurs années de passer au mode plus sécurisé Encrypt-then-Pad-then-Mac). En résumé, les grandes familles d'algos à notre disposition sont les suivantes : échange de clés éphémères = DHE ou ECDHE, authentification (signature) = RSA ou ECDSA (DSA dégage, tout comme la possibilité de présenter des certificats OpenPGP) et chiffrement symétrique = AES AEAD. Enfin, si dans les versions précédentes de TLS, on peut négocier des courbes, leurs paramètres et des groupes finis de DH, avec TLS 1.3, il n'est plus possible d'utiliser des paramètres (courbes, points sur les courbes, groupes finis DHE, etc.) maison pour (EC)DHE, il faut utiliser exclusivement ceux normalisés. L'idée est d'éviter les paramètres foireux et/ou générés par une implémentation foireuse (ça s'est déjà vu) ;
    
    
  • La compression TLS et la renégociation des clés de session en cours de route n'existent plus. Vu les attaques les utilisant genre CRIME, ce n'est pas une perte. La reprise d'une session fonctionne désormais comme un échange de clé partagée, il n'y a plus de code informatique dédié à cette fonctionnalité ;
    
    
  • Pour l'authentification des messages TLS, si l'on utilise RSA, alors on l'utilise forcément avec le schéma / profil RSA-PSS (Probabilistic signature scheme) défini dans la version 2.1 du standard PKCS#1 qui est plus robuste que celui de la version 1.5 de PKCS#1 qui rendait possible des attaques par rembourrage genre ROBOT. Pour l'authentification du pair (serveur ou client), les implémentations doivent supporter RSA-PSS (c'est la nouveauté) et le prioriser dans la négociation, mais sans plus ;
• La poignée de main TLS est désormais partiellement confidentielle et intègre. Ça explique pourquoi, au sein d'un échange TLS, on voit très rapidement des messages du type « Application data » auparavant réservés au seul contenu applicatif protégé : ces messages contiennent désormais la fin de la poignée de main sous une forme chiffrée. C'est ça, qui rend envisageable ESNI, le chiffrement du SNI, c'est-à-dire le nom du serveur que l'on cherche à contacter (utile sur un serveur mutualisé afin que le serveur envoie le bon certificat x509, celui du service avec lequel on veut échanger). Les clés de session (je simplifie) sont échangées dans l'extension « Keyshare » des messages « (Client|Server)Hello » puis confirmées après l'échange du certificat du serveur (afin d'en garantir l'authenticité). L'authenticité de la poignée de main n'est garantie qu'à sa fin ;
  
  

• Afin d'éviter les pare-feux mal-conçus et les boitiers de sécurité foireux massivement déployés, TLS 1.3 imite, au niveau réseau, TLS 1.2 : la version présentée dans le message « ClientHello » est toujours 1.2 alors que la vraie version est négociée dans une extension, on conserve le champ « CompressionMethod » dans les messages « *Hello » alors qu'il n'y a plus de compression TLS (voir ci-dessus), et l'on conserve les messages « ChangeCipherSpec » qui servent pourtant plus à rien, etc. Voilà où nous en sommes pour quelques enfoirés qui font nawak :( ;

• Une poignée de main TLS < 1.3 se fait en 2 RTT (deux allers-retours entre le client et le serveur). Hors poignée de main TCP (1 RTT) et hors requête applicative (1 RTT). Je trouve cette présentation trompeuse, car, dans un même trajet (aller ou retour), plusieurs messages TLS seront échangés, potentiellement dans des paquets IP séparés. On tombe à 1 RTT lors de la reprise d'une session existante. Un mode 0 RTT (0-RTT / early-data) apparaît avec TLS 1.3 : lors de la reprise d'une session, on peut envoyer des données applicatives (chiffrées et intègres) dès le premier message. Cela a un coût : on perd la confidentialité persistante (car les données sont chiffrées avec la clé partagée, PSK, contenue dans le ticket de session) et on se rend vulnérable à un rejeu d'une requête capturée sur le réseau. L'application doit gérer cela… sauf qu'il est très compliqué de différencier une requête non-idempotente (donc problèmatique)… Sinon, le serveur TLS doit conserver un état… ce dont personne veut, toute la reprise d'une session est et a toujours été sans état. Je vois jamais une présentation de l'intérêt du mode 0-RTT : je trouve qu'il est utile entre un reverse proxy et un serveur backend afin d'être certain d'une absence de perte de performance, par exemple, sauf si le réseau entre eux est multi-datacenters / international (auquel cas, un risque de surveillance externe existe, et encore, mieux vaut chiffrer + 0-RTT que de faire du trafic en clair) ;

  • Dans OpenSSL, le mode 0-RTT / early-data est désactivé par défaut, une application doit demander explicitement son activation à la bibliothèque cryptographique qu'elle utilise. « By default the server does not accept early data; a server may indicate support for early data by calling SSL_CTX_set_max_early_data() or SSL_set_max_early_data() to set it for the whole SSL_CTX or an individual SSL object respectively » (source). Je n'ai pas vérifié le comportement des autres implémentations de TLS.
• Dans TLS < 1.3, un même champ permettait d'indiquer l'algo pour l'échange de clés, celui pour l'authentification (du pair et des messages TLS), celui pour le chiffrement symétrique et éventuellement celui pour garantir l'intégrité. Désormais, il y a trois champs : échange de clés = « supported groups » (anciennement « supported elliptic curves », mais vu qu'on peut aussi faire du DHE, ce nom ne se justifiait plus et il a sauté avec le RFC 7919), auth = « signature algorithms », chiffrement symétrique et intégrité = « cipher suites » (le vieux champ). Les versions précédentes de TLS utilisent aussi les extensions « supported groups » et « signature algorithms », donc TLS 1.3 acte seulement le changement sémantique du champ « cipher suites » ;
  
  
• Il n'y a plus d'ordre imposé dans la chaîne des certificats fournie à un client TLS à l'exception que le certificat du serveur doit être le premier. C'était déjà le cas en pratique, c'est désormais dans la norme ;
  
  
• On note l'apparition d'une extension TLS sympa nommée « certificate_authorities ». Elle indique la liste des autorités de certification connues du client, et elle peut aider le serveur à choisir un certificat qu'il enverra (par exemple en n'envoyant le certificat CAcert que si le client connait cette AC). (j'ai copié cette phrase depuis le blog de tonton Bortz).

La bibliothèque de fonctions cryptographiques OpenSSL implémente TLS v1.3 à partir de sa version 1.1.1. Celle-ci est disponible dans la version Buster (10) de Debian. Donc ma récente mise à jour vers Debian Buster (voir mes notes sur ce qui change et/ou qui pose problème entre Stretch et Buster) m'en ouvre les portes. \o/ Notons que la protection contre le rejeu possible du mode 0-RTT (avec des états côtés serveurs ?) et l'utilisation des groupes finis DHE, entre autres, ne sont pas disponibles dans cette version.

Pour activer TLS 1.3, il y a rien à faire, ni côté client, ni côté serveur, puisque la version de TLS est négociée lors de l'établissement d'une communication chiffrée afin d'en retenir la plus élevée.

Néanmoins, attention aux configurations de serveurs applicatifs qui listent explicitement les versions de TLS utilisables. Exemples : un serveur d'emails Postfix configuré avec smtpd_tls_protocols = !SSLv2, !SSLv3 utilisera automatiquement TLS 1.3 si le client la prend en charge ; Idem pour un serveur IMAP/POP Dovecot configuré avec ssl_min_protocol = TLSv1.2. En revanche, un Apache httpd configure avec SSLProtocol +TLSv1.1 +TLSv1.2 n'utilisera pas TLSv1.3, il faudra le configurer explicitement (SSLProtocol +TLSv1.1 +TLSv1.2 +TLSv1.3) ou exclure les protocoles non-fiables plutôt que de lister les protocoles fiables (voir l'exemple Postfix ci-dessus).

Comment vérifier qu'un serveur applicatif n'utilise pas le mode 0-RTT / early-data (il est désactivé par défaut, c'est aux serveurs applicatifs de l'activer, lire ci-dessus) ? En testant nous-même. Quand un serveur applicatif accepte le mode 0-RTT, il en informe tout client en positionnant l'extension « early_data » dans un ticket de session TLS. Voyons ça en pratique :

• D'un côté, on monte un serveur TLS : openssl s_server -accept 4433 -cert <chemin_vers_certificat_x509> -key <chemin_vers_clé_privée> ;
  
  
• De l'autre, on se connecte à ce serveur TLS : openssl s_client -connect <nom_serveur>:4433 -tlsv1_3. On remarque la ligne « Max Early Data: 0 » dans la section « New Session Ticket arrived » : 0-RTT n'est pas disponible ;
  
  
• On interrompt (ctrl+c) le serveur TLS et on en monte un avec le mode 0-RTT activé : openssl s_server -accept 4433 -cert <chemin_vers_certificat_x509> -key <chemin_vers_clé_privée> -early_data. On relance le client TLS. Cette fois-ci, on lit « Max Early Data: 16384 », donc 0-RTT est disponible ;
  
  
• On peut ensuite tester tous nos vrais serveurs (Apache httpd, Postfix, Dovecot, etc.) ainsi. Ne pas oublier -starttls <protocole> en fonction du cas. ;)
  
  
• Si l'on a un doute, on peut initier une première connexion TLS en conservant le ticket (-sess_out <nom_fichier_stockage_ticket_TLS>) puis une deuxième en donnant le ticket (-sess_in <nom_fichier_stockage_ticket_TLS>) et en envoyant du contenu (-early_data early_data.txt) qu'il faut créer d'abord (avec echo 'Bonjour' > early_data.txt, par exemple). Si le serveur a accepté nos données utilisateur, OpenSSL affichera « Early data was accepted ». Sinon, il affichera « Early data was not sent ». On peut contrôler tout ça avec Wireshark en déchiffrant l'échange TLS à l'aide de SSLKEYLOGFILE (puisque ces messages TLS sont désormais chiffrés).

On peut aussi désactiver le mode 0-RTT dans les logiciels clients. Pour Firefox et Thunderbird, cela se fait en attribuant la valeur « false » à la clé « security.tls.enable_0rtt_data » dans about:config.

La variable d'environnement « SSLKEYLOGFILE » permet d'indiquer un fichier où seront stockés les secrets cryptographiques (clés de session) échangés par un programme lors de communications TLS.

Ça fonctionne avec la majorité des bibliothèques TLS. J'ai testé avec Firefox (lib = NSS), Chromium (lib = BoringSSL), curl (lib = OpenSSL), wget et ldapsearch (lib = GnuTLS). A priori, ça fonctionne sous GNU/Linux, mais aussi sous winwin et Mac OSX.

C'est logique, car c'est à chaque programme de vérifier l'existence de la variable d'environnement, d'ouvrir le fichier, d'appeler la callback de la bibliothèque TLS, etc. Exemple : le sous-programme s_client d'OpenSSL ne prend pas en charge cette variable, il faut utiliser le paramètre -keylogfile.

On peut utiliser ces secrets afin de déchiffrer une communication avec Wireshark sans recourir à une attaque MitM. Généralement, le programme n'efface pas les secrets consignés lors de sessions précédentes ou par d'autres programmes (il ajoute ses secrets à la fin du fichier) , wireshark sera en mesure de déchiffrer tous les flux chiffrés qu'il a capturés, même si un logiciel a effectué plusieurs connexions chiffrées ou s'il a renégocié les clés.

Vu que j'ai déjà déchiffré des flux avec wireshark, j'ai l'impression de redécouvrir quelque chose que je savais autrefois… Curieuse sensation… Merci à l'article Prise en main de TLS 1.3 avec OpenSSL 1.1.1 pour le rafraîchissement de mémoire.

Lors de l'incrémentation du serial d'une zone DNS, je me trompe. Au lieu de saisir « 2020052205 », je saisis « 20200522050 » (un zéro en trop). Je demande à OpenDNSSEC de signer la zone (DNSSEC). Puis je me rends compte de mon erreur : dig SOA <domaine> affiche « 3020633059 ». Comment faire redescendre ce serial ?

Normalement, il suffit de décrémenter le serial, de redémarrer le serveur de noms (ou de forcer le chargement de la zone sans contrôle du serial) puis de faire de même sur les slaves. Mais, il y a OpenDNSSEC au milieu et, lui, a une mémoire du serial. Si je signe à nouveau la zone après avoir remis le serial comme il faut, le serial passe à 3020633060.

Essayons naïvement de préciser le serial sur la ligne de commande ?

# ods-signer sign guiguishow.info --serial 2020052206
Error: Unable to enforce serial 2020052206 for zone <CENSURE>.
Zone <CENSURE> scheduled for immediate re-sign.

Regardons les dates de modification dans /var/lib/opendnssec. Aucun fichier modifié récemment sauf une sauvegarde du fichier de zone avant sa dernière signature. Après vérification, OpenDNSSEC ne s'en sert pas comme référence pour le serial.

En fait, le serial est lu dans le fichier de zone non signé lors du démarrage du démon signer puis il est conservé en mémoire vive.

Il suffit donc de stopper le signer et l'enforcer (systemctl stop opendnssec-signer.service opendnssec-enforcer.service), puis de mettre le serial désiré dans le fichier de zone non signé puis de démarrer l'enforcer et le signer (systemctl start opendnssec-signer.service opendnssec-enforcer.service). Le journal d'OpenDNSSEC m'informe :

ods-signerd: [namedb] zone <CENSURE> unable to use datecounter as serial: 2020052200 does not increase 2020052206. Serial set to 2020052207
ods-signerd: [STATS] <CENSURE> 2020052207 RR[count=23 time=0(sec)] NSEC[count=14 time=0(sec)] RRSIG[new=37 reused=0 time=0(sec) avg=0(sig/sec)] TOTAL[time=0(sec)] 

« 2020052206 » est le serial que j'ai écrit dans le fichier de zone non signé.

Lors du chargement de la zone par OpenDNSSEC, BIND9 consigne error: zone <CENSURE>/IN: zone serial (2020052207/3020633062) has gone backwards, mais il recharge la zone.

Sur les serveurs DNS slaves, il faudra utiliser nsd-control force_transfer <nom_zone> ou rndc retransfer <nom_zone> afin de forcer le transfert de la zone réparée sans contrôle préalable du serial.

Fin de l'incident.