GuiGui's Show

« J'ai suivi les 2ème Rencontres Parlementaires de la Cybersécurité via Twitter (hashtag #RPCyber)

[...]

Premier constat: le cyber est aux mains des militaires. La première édition se déroulait au siège de la Gendarmerie, la deuxième édition à l'école militaire. Toute la fine fleur des industriels "de confiance" était là (Thales, Airbus ex-Cassidian, Sogeti, …) au côté des amiraux et des députés. Pas de représentants de la société civile, sauf les sponsors.

Quant au contenu des tables rondes: cyber-criminalité, cyber-guerre, cyber-espionnage (dit APT).

Bref, on n'était pas là pour faire de la philosophie comparée entre le Java et le OCaml, mais plutôt pour dézinguer du cyber-terroriste. Ca va filer droit et sécuriser sec.

[...]

La cyberguerre: il sera temps de la faire quand elle arrivera.

[...]

La sensibilisation: ça ne marche pas.

[...]

La formation: ça ne marche pas.

Mais le fond du problème, c'est que "la cyber" n'intéresse personne. Au lieu de se retrouver contractuel dans l'administration ou consultant en SSII/ESN/whatever à réinstaller des postes compromis pendant ses week-ends, le jeune qui maitrise un minimum son sujet va plutôt monter un réseau social ou un site de rencontres (c'est pareil) et le revendre dans la Silicon Valley.

Le peu de gens qui se sont quand même lancés dans la cyber-aventure se sont vite lassés … absence de reconnaissance morale et financière, structures étouffantes, impact nul (refaire le même pentest année après année pour le même client, avec les mêmes résultats ?), absence de perspectives à moyen terme … certains de nos meilleurs experts ont fini dans des trous à rat d'où ils attendent la retraite, les autres sont partis faire autre chose.

[...]

Les PME innovantes en cyber-sécurité: ça n'a aucun intérêt.

Le fond du problème, c'est donc le statut du développeur logiciel: grouillot boutonneux en France, star dans la Silicon Valley. Une fois que le logiciel et les services en ligne fonctionneront sans subventions en France, l'intendance suivra.

Et pour cela, il faut que l'informatique trouve la place qu'elle mérite dans les entreprises … et dans le cœur des gens.

[...]

Les problèmes: ils sont devant nous, et personne n'y a encore touché.

J'ai du mal à partager l'optimisme général sur les progrès fabuleux réalisés dans le domaine de la sécurité informatique, sans vouloir minorer le volontarisme de l'Etat.

Vu de l'extérieur de la cyber-bulle, rien n'a changé: les gens se font voler leur mot de passe et parfois même leur identité numérique, les fraudes sont de plus en plus nombreuses, les entreprises se font pirater et racketter en masse (la fraude au président connaît un succès qui ne se dément pas – tout comme les APT), le dépôt de plainte relève du chemin de croix, les enquêtes ne débouchent sur rien, personne n'est responsable de la situation.

[...]

Pour conclure, je crois qu'il faut arrêter avec le (ou la ? Peut-être The) cyber.

Utiliser un iPhone pour téléphoner à son pote le dealer n'est pas une cyber-attaque.

[...]

La "cybernétique", c'est la science du gouvernement, devenue la science des systèmes complexes. Un mot déjà désuet à l'époque d'Ampère.

Le reste c'est de la délinquance, de l'espionnage ou de la guerre - pratiqué avec des outils modernes. »

Très bon billet qui vise juste comme d'habitude. Dommage de taper large (exemple parmi d'autres : la *version* de Java installée/requise est un faux problème soyons honnêtes, les vraies questions c'est a-t-on besoin de faire telle action en ligne (voter en l'occurence) et si oui, comment le faire sans Java mais avec des technos web normalisées qui juste marchent  ...)

« Pourtant, quand Niklas reçoit un message l’invitant à rejoindre une équipe d’ingénieurs chez Google, il a le front de décliner, dans une lettre ouverte où il explique ses raisons.

C’est cet échange de courrier que nous avons traduit pour vous. Notez que cette fois-ci c’est Google qui est sur la sellette (parce qu’il le vaut bien) mais ce pourrait être tout autant un des autres géants du Net centralisateurs et prédateurs de nos données…

[...]

Mon père s’en est vite rendu compte et nous avons eu une longue discussion sur ce qui est important dans la vie. Il m’a dit de ne pas être imprudent sinon le monde de demain consisterait en une tyrannie d’une part et des gens dépourvus de pouvoir de l’autre. Il m’a dit que, dans le futur, la répartition des pouvoirs dans le monde dépendrait beaucoup de ceux que je considère aujourd’hui comme des cypherpunks ou des hackers.
J’ai l’impression que l’avenir que mon père me décrivait quand j’étais enfant est aujourd’hui notre présent. Google dit « ne rien faire de mal » d’une part, mais de l’autre Google lit aussi le contenu des messages électroniques de ses utilisateurs et piste leur comportement sur Internet — deux choses que je décrirais clairement comme « le mal ». Google lit les courriels que ma mère écrit et piste ce que mes amis achètent. À des fins publicitaires, prétend Google… mais nous n’en avons découvert les véritables conséquences que plus tard, quand Edward Snowden a lancé l’alerte.

[...]

Je me vois mal développer un jour les outils tyranniques indispensables à Google pour continuer sa course. Je suis de l’autre bord. J’ai conçu le projet que vous saluez, panic_bcast, pour que les services de sécurité aient davantage de difficultés à récolter des informations sur des militants politiques au moyen d’attaques du type « démarrage à froid ». Ce qui motive ma participation à d’autres projets de ce genre est ma conviction de la nécessité d’une circulation libre et sans contraintes de l’information sur l’Internet public. »

Via http://sebsauvage.net/links/?3dGUiA

Bien utile quand un shell interactif (shell Oracle, MySQL, ...) n'implémente pas les fonctionnalités de base comme l'historique des commandes et les raccourcis clavier : ledit (line editor) agit comme un wrapper et implémente ces fonctionnalités essentielles.

ÉDIT DU 12/07/2015 à 11h05 : Benvii me signale que rlwrap est quand même plus mieux meilleur vu qu'il fonctionne aussi via telnet. FIN DE L'ÉDIT.

« Ainsi, l’étude Data Miles, réalisée à partir d’un sondage organisé en août 2014 sur la plate-forme communautaire Tonula auprès de 4000 personnes (dont 1000 en France) utilisant les transports en commun, révèle que chaque employé quitte son bureau avec 470 Go de données en moyenne. Soit mille fois plus que le volume qu’il échange sur Internet dans le même laps de temps, selon le rapport prévisionnel Cisco VNI 2013-2018. A titre d’exemple, chaque jour, pas moins de 350 pétaoctets de données (350 millions de Go) transitent physiquement par la seule ville de Paris qui reste bien modeste en regard des 1,4 exaoctets (1400 Po) de New York. Le métro parisien en transporte à lui seul 138 Po quotidiennement.

Des volumes impressionnants qui resteraient anecdotiques si les risques qui accompagnent leur circulation physique ne constituaient pas un réel problème. De fait, l’étude estime que 41% des utilisateurs ont perdu un appareil contenant des données de l’entreprise au cours des 12 derniers mois. « D’énormes quantités de données professionnelles sont en péril aux heures de pointe », note l’étude un brin alarmiste. En région parisienne, c’est sur le RER A, entre Cergy (Val d’Oise) et Paris, que la densité de données qui empruntent les transports en commun est la plus soutenue (45 Po). »

Ces chiffres sont intéressants en eux-mêmes mais à prendre avec des pincettes : « Mozy la solution de sauvegarde en ligne simple, automatique et sécurisé pour les entreprises et particuliers. » ... Le côté alarmiste de cette étude en prend un coup.

Via : http://seenthis.net/messages/308652

« The Name Service Switch (NSS) configuration file, /etc/nsswitch.conf, is used by the GNU C Library to determine the sources from which to obtain name-service information in a range of categories, and in what order. Each category of information is identified by a database name. »

Pour bypasser le fichier /etc/hosts (sauf localhost ;) ), il faut indiquer « hosts: dns » dans ce fichier en lieu et place de « hosts: files dns ».

Pour bypasser /etc/services, « services: db » au lieu de « services: db files ». Même chose pour /etc/protocols.

« Le raid matériel est très performant, les contrôleurs sont très chers, les groupes raid créés ne sont pas “portables” sur un autre type de contrôleur (en cas de panne, de changement de matériel…). Le raid matériel est totalement transparent pour l'utilisateur et le système. Le “fake raid” n'a aucun avantage sur le raid logiciel, il est même moins souple et pas plus performant. Son seul atout pourrait-être une relative “transparence” pour l'utilisateur. »

+ une liste des commandes utiles et indispensables.

Il y a tellement de mises en prod' le vendredi à 16h un peu partout que ça ne veut plus rien dire le "ho noooon on ne met rien en prod' le vendredi". M'enfin bref ...

« J'utilise ici le terme “hacking” dans son sens noble: Comprendre le fonctionnement et modifier pour l'adapter à ses besoins.

Je vais donc décrire ici la manière d'examiner et modifier une application Android (fichier .apk). La motivation est double:
    - S'amuser à bidouiller et comprendre le fonctionnement des applications (en particulier le code machine Dalvik d'Android).
    - Protéger sa vie privée en coupant certaines fonctionnalités des applications (géolocalisation, etc.) »

« Multiple security issues have been found in Iceweasel, Debian's version of the Mozilla Firefox web browser: Multiple memory safety errors, buffer overflows, use-after-frees and other implementation errors may lead to the execution of arbitrary code, denial of service, the bypass of the same-origin policy or a loss of privacy.

[...]

In addition, this update also disables SSLv3. »

Jusque là c'est parfaitement légitime.

« This update updates Iceweasel to the ESR31 series of Firefox. The new release introduces a new user interface. »

WTF ?! Pardon ?! O_O Depuis quand une security update s'occupe d'autre chose que de sécurité ?! Une mise à jour de sécurité doit corriger les failles détectées, un point c'est tout. C'est ça pour moi, l'une des qualités de Debian stable : la production ne pète pas à la tronche de l'adminsys ! Quand bien même c'est l'interface graphique d'un des logiciels que j'utilise le plus sur mes machines hors prod'. Que j'apprécie ou pas l'interface Australis de Firefox n'entre pas en ligne de compte dans cette histoire. J'imagine qu'il y a une raison derrière (comme par exemple que la team Debian Security avait annoncé qu'elle n'allait plus s'occuper des navigateurs web car c'trop le bordel) mais quand même, je suis très déçu de voir ça.


ÉDIT du 01/11/2014 à 16h25 : même chose aujourd'hui avec le DSA 3061-1 sur Icedove :
« Multiple security issues have been found in Icedove

[...]

This update updates Iceweasel to the ESR31 series of Thunderbird. In addition Enigmail was updated to version 1.7.2-1~deb7u1 to ensure compatibility with the new upstream release.

Mozilla implemented TLS 1.2 in NSS version 3.15.1 and Thunderbird 31.0 uses this as the default. It won't fall back to older protocol versions.

This means every connection from Thunderbird/Icedove to a mail server will using TLS 1.2 with no fall back if you have configured TLS/SSL or STARTTLS for your connections. »

D'après mes tests, ce n'est pas aussi disruptif que ça en a l'air : en désactivant TLSv1.2 dans smtpd de Postfix, Icedove (configuré pour utiliser STARTTLS) accepte de négocier TLSv1.1 (cf le log Postfix :  « TLS connection established from <lala>: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) »). En désactivant TLSv1.2 et TLSv1.1, Icedove accepte de négocier TLSv1.0 . Je n'ai pas pu tester la partie IMAP/STARTTLS puisque Dovecot permet seulement de désactiver SSLv2, SSLv3 et TLSv1.  FIN DE L'ÉDIT.


ÉDIT du 08/12/2014 à 20h25 : même chose aujourd'hui avec Icedove qui ne supporte plus SSLv3 : « Due to the  BEAST vulnerability Icedove does not support SSLv3 encrypted connections by default any longer. ». C'est une bonne chose en soi mais est-ce à une màj de sécurité annoncée pour autre chose (cf le DSA ne parle pas de cette désactivation de SSLv3) de faire ce choix ? Par ailleurs, BEAST concerne aussi TLSv1.0 quand des ciphers CBC sont utilisés donc l'argument est un peu moisi ...  FIN DE L'ÉDIT.

POODLE, tout comme Heartbleed en son temps, fait couler beaucoup d'octets dans les internets ces derniers jours. Je vais donner mon avis sur ce que je pense être un effet de mode et surtout, une précipitation.

Disclaimer :
    1) Je ne suis pas un security guru.
    2) Ce que je vais dire s'applique dans le cadre de petits serveurs (auto-hébergés ou non) sans trop de trafic et sans contrainte. J'veux dire que je ne tiendrais pas le même discours s'il s'agissait du site web d'une banque ou d'un site web d'e-commerce ou d'un site web à très fort trafic (sur la partie ECDSA versus RSA). On constate d'ailleurs que, dans ces contextes-là, la réalité est toute autre que celle que je vais décrire car il y a le côté opérationnel à prendre en compte : https://imirhil.fr/ssl.html ;)


Commençons par POODLE (voir, entre autres http://seenthis.net/messages/302666) : il s'agit d'une faille dans le protocole SSLv3, pas d'un bug dans une implémentation particulière (comme OpenSSL). Ça m'en touche une sans faire bouger l'autre dans le sens où TLSv1.0 c'est so 1999 et que SSL est déprécié depuis fort longtemps. C'est un problème humain (adminsys consciencieux) et opérationnel (gérer les vieux clients dans certains contextes comme banques/e-commerce, frilosité au changement, ...). Sur nos petits serveurs persos, ça devrait être désactivé sans soucis à moins que les parts de marché d'IE6, 3,8 % au niveau mondial et 0.8 % en France en septembre 2014 revendiquées par Microsoft (https://www.modern.ie/en-us/ie6countdown), la réalité doit être légèrement supérieure ainsi que des appliances/automates proprios désuets ne vous intéressent. Après si le raffut inutile de ces derniers jours permet des  prises de conscience, pourquoi pas ...




L'ennui, c'est que je vois, principalement sur IRC, des adminsys se questionner sur la conf' TLS de leurs logiciels serveurs, ce qui est une bonne chose comme je viens de le dire, mais en poussant le vice trop loin. Mon plus grand conseil sera le suivant : gardez la raison, ne faites pas n'importe quoi, n'affaiblissez pas vos confs en croyant les renforcer. La sécurité dans l'urgence ne marche jamais. N'écoutez pas aveuglément toutes les ressources sur le web, n'écoutez pas aveuglément un validateur quand bien même il est aussi bien foutu que celui de ssllabs (https://www.ssllabs.com/ssltest/) ! À ce sujet, voir, par exemple, l'illustration avec BEAST : https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat - « Unfortunately, the only way to mitigate the BEAST attack is to enforce the use of RC4 suites whenever TLS 1.0 and earlier protocols are used (which is most of the time at this point). I say "unfortunately", because very shortly after we had started requiring server-side mitigations, new research about RC4 came out and we found out that this cipher was much weaker than previously thought. The weaknesses were not of immediate concern, but it was clear that RC4 was on the way out. » :)


Parmi ces questionnements, on retrouve les questions liées au résultat du test (ssllabs ou autre) et des débats plus profonds : ECDSA ou RSA ? SHA-1 ou SHA256 pour condenser mon certificat ? Quelle liste d'algorithmes cryptographiques autoriser ? Je déploie DANE, HSTS et compagnie ? ... C'est un vice de raisonnement, à mon humble avis. La priorité, ce n'est pas de passer en ECDSA comme si RSA vivait ses derniers instants ou de passer immédiatement à SHA256 pour condenser son certificat ou de passer à RSA 4096 bits au lieu de 2048 bits parce qu'un validateur vous l'a *conseillé* (« When renewing, ensure [...] »). L'important à l'heure actuelle, à mon humble avis, et ça sera mon deuxième grand conseil, c'est de garder la confiance et pour ça, de ne pas générer d'erreurs du côté de l'utilisateur et pour ça, de ne pas casser vos certificats x509 et les configurations de vos logiciels serveurs. On corrige donc les failles bien actuelles comme Poddle et, si l'on en a la motivation, on durcit la conf' TLS de ses logiciels serveurs en douceur.


Je vais quand même donner mon avis sur ces questionnements, ça serait idiot de dénigrer au lieu de guider.
    - Courbes elliptiques (ECDSA) versus RSA : c'est un débat théorique qui amuse les cryptologues mais ça n'a aucune réalité pratique. Les limites de la cryptographie interviennent sur des choses beaucoup plus connes et concrètes (générateur de nombres pseudos aléatoires pas assez aléatoires, bug logiciel, cryptographie mal utilisée (de la crypto avec IE6 sous XP, comment dire ...), ...) Les deux procédés sont toujours d'actualité. Le seul argument de plus en faveur des courbes elliptiques est leur faible taille (à niveau de sécurité jugé équivalent) et des temps de traitement plus courts donc une montée en charge des sessions TLS avec de nombreux clients facilitée. Les algos ECDHE-* sont moins gourmands que leurs homologues DHE-*. Sur des serveurs persos, ce gain n'a pas d'intérêt. Ce n'est pas pour autant que je crache sur ECDSA. Quant à utiliser les courbes elliptiques dans les certificats x509, le gain est encore moins évident : la validation du certificat se fait au début de la session TLS, pas en continu et sur le client (usage standard). Ne cassez pas vos certificats actuels parce qu'on vous a dit que RSA c'est fini à cause de POODLE, ça serait contre-productif !


    - SHA-1 / SHA256 comme fonction de condensation dans les certificats x509. SHA-1 sera peut-être dans les prochains algos cryptographiques à tomber donc il faut préparer la migration vers mieux (SHA256) mais, pour l'instant, on n'a aucune attaque efficace et imminente contre SHA-1.  Alors oui, je sais, le méchant Google a annoncé qu'ils vont favoriser de pas beaucoup les sites web accessibles en HTTPS puis qu'ils vont virer SHA-1 à eux tous seuls (voir : http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html) ... Tout ça pour se racheter suite aux révélations de Snowden, ce qu'il ne faut pas faire. :)

        1) On ne panique pas et je ne suis pas seul à tenir ce discours :  https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know . De plus, Google vont pénaliser d'abord les certificats auto-signés, ne nous faisons pas d'illusions donc SHA-1 versus SHA256, ça se place là dans l'ordre des priorités quoi.
        2) Google est-il vraiment indispensable pour la survie de nos sites web persos pas monétisés ?
        3) On regarde les certificats des AC (oui, toute la chaîne de confiance doit être SHA256, pas que les certificats finaux, sinon c'est stupide) présents dans le magasin de certificats Debian (ça serait pareil avec celui de Mozilla, juste ce check s'automatise bien) et on voit que la messe est dite :
                Total : 960 - 100 %
                        md5 (/!\ depuis le temps que MD5 est *mort* ce qui n'est même pas encore le cas de SHA-1)  : 66 - ~ 7 %
                        sha1 : 744 - 77,5 %
                        sha256 : 114 - ~ 12 %
                        sha384 : 36 - 3,75 %

        Donc, passer à SHA256 lors du prochain renouvellement normal de votre certificat (car il va expirer), c'est une bonne idée, bien sûr. Dans le contexte actuel, crise/peur (avérée ou imaginée, ça revient au même), c'est une mauvaise idée pour si peu : maintenir la confiance est primordiale (surtout avec les certificats autosignés ou AC autosignée) comme je l'ai écrit plus haut.


    - Je pense le plus grand bien de DANE (voir http://shaarli.guiguishow.info/?y6WIyg) mais déployons déjà DNSSEC (qui est un pré-requis) convenablement, avec des procédures (roulement des clés) éprouvées et on pourra ensuite se mettre à DANE. Il n'y a aucun serveur/client dans sa branche stable (au sens Debian, lala :D) qui utilise ces enregistrements donc rien ne presse : le gain de sécurité ne sera pas imminent. Mais là encore, ajouter ça sur sa TODO des choses à faire à moyen terme est une bonne idée.


    - HSTS (voir : http://www.bortzmeyer.org/6797.html) est encore une bonne idée. Mais réfléchissez bien avant de déployer : la configuration doit être parfaite car la moindre erreur est bloquante et mise en cache quand on active HSTS ! Par ailleurs, les certificats autosignés génèrent des erreurs donc ça va plutôt mal se passer avec HSTS.


    - Faut-il tuner le cache des sessions TLS ? S'il n'y a aucun inconvénient à l'activer, Il faut mesurer le gain d'aller le tuner finement. Sur un service avec 10 connexions (css/images inclues pour un site web) par tranche de 30 mns, bof, le cache va pas servir des masses donc aller tuner ça comme pour un site à fort trafic, c'est sans grand intérêt, àmha, autant se reposer sur les paramètres par défaut des logiciels serveurs. Sur un serveur mail, avec la concentration des acteurs, l'abonnement à des ML, ... ça se justifie déjà plus mais stay relax quand même. :D




Pour les confs TLS de mes logiciels (elles sont disponibles à la fin de ce shaarli et valent ce qu'elles valent), je me base sur ces ressources déjà pointées dans d'autres de mes shaarlis :
    - Conf' « SSL/TLS » par Benjamin Sonntag à Il était une fois Internet. Les configurations présentées après un exposé plus général sont détaillées et expliquées. http://confs.fr/ssltls-benjamin-sonntag/
    - Pour des configurations clé en main de logiciels serveurs courants et une liste d'algorithmes à privilégier (attention, Mozilla, ça peut être biaisé pour garder la compatibilité avec les anciennes versions de Firefox/Thunderbird/autre) : https://wiki.mozilla.org/Security/Server_Side_TLS


Enfin, àmha, la priorité (en général, pas POODLE), ce n'est pas tellement nos petits serveurs web qui servent des sites web à contenu informatif (donc pas e-commerce / banque / dépôt de  données personnelles / contenu "sensible" où sensible se défini du point de vue du visiteur, pas du nôtre). Non, la priorité c'est nos serveurs mails (SMTP *ET* IMAP) et nos serveurs XMPP (C2S et S2S). C'est là qu'est le vrai contenu privé que l'on veut protéger. D'ailleurs, pour tester la conf' TLS votre serveur XMPP, voir : http://shaarli.guiguishow.info/?AKSlXA .

Donc, pour résumer : -SSLv2/-SSLv3, -RC4 (oui, je sais, BEAST mais sur nos petits serveurs persos, je pense qu'on peut ignore l'usage de TLSv1.0), +PFS (Perfect Forward Secrecy, confidentialité persistante, les échanges sécurisés précédant une compromission d'une clé privée ne sont pas eux-mêmes compromis et restent donc secrets. Donc Diffie-Hellman éphémère donc algos DHE-*, ECDHE-*) et on se relaxe. \o/




Les configurations TLS de mes logiciels serveurs :

ÉDIT DU 03/01/2016 À 23H00 : J'ai mis à jour ces configs avec les dernières directives de configuration disponibles dans les versions packagées dans Debian GNU/Linux Jessie. FIN DE L'ÉDIT.

Apache2 :
    SSLEngine on
   
    SSLCertificateFile    /etc/apache2/ssl/viki.crt
    SSLCertificateKeyFile /etc/apache2/ssl/viki.key

    SSLProtocol All -SSLv2 -SSLv3
       
    SSLCipherSuite ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    SSLHonorCipherOrder on

    # Par defaut
    SSLCompression off
    SSLSessionCacheTimeout 300

    # Parametres DH - Ils sont auto generes selon la taille de la cle
    # utilisee. Si l'on veut des dhparam personnalises, cela necessite
    # openssl 1.0.2 pas encore dans Jessie ou de les concat a la fin du
    # fichier contenant le certif x509 aka c'est crade...
    # SSLOpenSSLConfCmd DHParameters "/etc/apache2/ssl/dh_4096.pem"

    # Cache partages des sessions TLS : mod_socache_* sont necessaires
    # mais pas encore dispo dans Debian stable (01/02/2014)
    # Un cache partages des sessions TLS ne se justifie pas ici :
    # contenu simple : pas besoin de plusieurs connexions simultanees
    # et utilisateurs qui ne reviennent pas dans des delais brefs, en majorite




nginx :
    ssl on;

    ssl_certificate /etc/nginx/ssl/pokedex.crt;
    ssl_certificate_key /etc/nginx/ssl/pokedex.key;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_ciphers ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM;
    ssl_prefer_server_ciphers on;

    # Compression TLS desactivee par defaut dans nginx

    # Parametres DH
    ssl_dhparam /etc/nginx/ssl/dh2048.pem;

    # Par defaut
    ssl_session_timeout 5m;

    # Un cache partages des sessions TLS ne se justifie pas ici :
    # contenu simple : pas besoin de plusieurs connexions simultanees
    # et utilisateurs qui ne reviennent pas dans des delais brefs, en majorite




Dovecot :
    ssl = required

    ssl_cert = </etc/postfix/ssl/pokedex.crt
    ssl_key = </etc/postfix/ssl/pokedex.key

    ssl_protocols = !SSLv2 !SSLv3

    ssl_cipher_list = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    ssl_prefer_server_ciphers = yes

    # Parametres DH. 4096 bits dans cet exemple car
    # ca correspond a la taille de ma cle
    ssl_dh_parameters_length = 4096

    # Dovecot ne propose aucune autre option




ejabberd :
    ## c2s (bloc listen)
    -
      port: 5222
      ip: "::"
      module: ejabberd_c2s
      max_stanza_size: 65536
      shaper: c2s_shaper
      access: c2s

      # TLS est obligatoire entre un client XMPP (gajim par ex) et le serveur
      starttls: true
      starttls_required: true

      # attention, il faut chainer le certificat x509 et la cle privee.
      # Exemple : cat pokedex.crt pokedex.key > pokedex.crt+key
      certfile: "/etc/ssl/mycert/pokedex.crt+key"
     
      protocol_options:
        - "no_sslv2"
        - "no_sslv3"
        - "cipher_server_preference"

      ciphers: "ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM"

      # Parametres DH. Pas avant ejabberd 15.06 qui n'est pas dans Debian Jessie
      # J'utilise des parametres de 4096 bits car en accord avec la taille
      # de la cle utilise dans mon certificat x509
      dhfile: "/etc/ejabberd/ssl/dh_4096.pem"

    [...]

    # s2s (pas de bloc specifique)

    # TLS est obligatoire entre deux serveurs XMPP. Attention, beaucoup de
    # serveurs XMPP ne supportent pas TLS (exemple : Google) donc ça peut
    # empecher de parler a des contacts. On peut mettre la valeur a optional
    # dans ce cas
    s2s_use_starttls: required

    # Voir la remarque ci-dessus pour certfile
    s2s_certfile: "/etc/ssl/mycert/pokedex.crt+key"

    # Voir la remarque ci-dessus pour protocol_options
    s2s_protocol_options:
      - "no_sslv2"
      - "no_sslv3"
      - "cipher_server_preference"

    s2s_ciphers: "ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM"

    # Voir la remarque ci-dessus pour dhfile
    s2s_dhfile: "/etc/ejabberd/ssl/dh_4096.pem"




Postfix :

ÉDIT DU 20/06/2020 : cette configuration est erronée. Voir la nouvelle ici : http://shaarli.guiguishow.info/?m68qkQ . FIN DE L'ÉDIT.

    # TLS - serveur
    smtpd_tls_security_level = may

    # On n'accepte pas d'auth si pas de TLS
    smtpd_tls_auth_only = yes

    smtpd_tls_cert_file = /etc/postfix/ssl/pokedex.crt
    smtpd_tls_dcert_file = $smtpd_tls_cert_file
    smtpd_tls_key_file = /etc/postfix/ssl/pokedex.key
    smtpd_tls_dkey_file = $smtpd_tls_key_file

    smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

    smtpd_tls_protocols = !SSLv2, !SSLv3

    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
    tls_preempt_cipherlist = yes

    # Parametres DH. Oui, 1024 -> 4096 ... ça vient de la doc Postfix
    # J'utilise des parametres de 4096 bits car en accord avec la taille
    # de la cle utilise dans mon certificat x509
    smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_4096.pem

    # Cache partages des sessions TLS (expire au bout d'une heure par defaut)
    smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_tls_cache

    smtpd_tls_loglevel = 1


    # TLS - client
    smtp_tls_security_level = $smtpd_tls_security_level

    smtp_tls_cert_file = $smtpd_tls_cert_file
    smtp_tls_dcert_file = $smtpd_tls_dcert_file
    smtp_tls_key_file = $smtpd_tls_key_file
    smtp_tls_dkey_file = $smtpd_tls_dkey_file

    smtp_tls_CAfile = $smtpd_tls_CAfile

    smtp_tls_protocols = $smtpd_tls_protocols

    smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
    smtp_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers

    # Cache partages des sessions TLS (expire au bout d'une heure par defaut)
    smtp_tls_session_cache_database = btree:${data_directory}/smtp_tls_cache

    smtp_tls_loglevel = $smtpd_tls_loglevel




Quelques précisions :
    - Oui, je ne me fais pas chier avec une liste de ciphers longue comme le bras car c'est, àmha, trop chiant à maintenir pour un gain de sécurité pas évident du tout à mesurer par rapport à utiliser les groupements OpenSSL (ou GnuTLS, c'est bien pareil) et à exclure quelques suites d'algos. Du coup, je vire simplement les algos pourris (RC4, 3DES, MD5, ceux classés en LOW dans OpenSSL) ou inexistants (aNULL, eNULL) et j'utilise les algos classés comme HIGH puis comme MEDIUM. L'ordre sera celui du serveur : le client prendra la suite d'algos la plus forte qu'il supporte.

    - Vu que j'ai un seul certificat x509 par machine, les /etc/<logiciel_serveur_>/ssl/lala.(crt|key) sont des liens symboliques vers /etc/ssl/mycert/ . Factorisation toussa.

    - Oui, je ne fais pas encore le chaînage des certificats pour fournir une chaîne de confiance complète à mes visiteurs, c'est sur ma TODO pour le prochain renew des certificats.

    - Rappel des valeurs par défaut dans mes confs c'est juste pour m'en souvenir / retrouver facilement.