GuiGui's Show

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