Ce n'est pas le passage à Jessie lui-même qui va durcir vos configs TLS mais le fait que des logiciels serveur y sont présents dans une version qui ouvre de nouveaux horizons. Il s'agit d'Apache httpd, d'ejabberd et de dovecot. Je repars des configurations que j'ai donné dans un autre shaarli (à la fin) :
http://shaarli.guiguishow.info/?GPqmpA
Commençons par Dovecot :
* La directive de configuration « ssl_prefer_server_ciphers = yes » permet de forcer les clients à respecter l'ordre du serveur dans le choix de la suite cryptographique à utiliser parmi toutes celles supportées des deux côtés. Cette directive évite le choix d'une suite cryptographique sous-optimale (bug ou attaque par repli afin de choisir une suite que l'attaquant sait cassable facilement). Voir
https://www.howtoforge.com/tutorial/how-to-protect-your-debian-and-ubuntu-server-against-the-logjam-attack/
* La génération des paramètres de Diffie-Hellman a complètement changé depuis la branche 2.1 : « When Dovecot starts up for the first time, it generates new 512bit and 1024bit Diffie Hellman parameters and saves them into <prefix>/var/lib/dovecot/ssl-parameters.dat. Dovecot v2.1.x and older regenerated them every week by default, but because the extra security gained by the regeneration is quite small, Dovecot v2.2 disabled the regeneration feature completely. » (source :
http://wiki.dovecot.org/SSL/DovecotConfiguration ). Avec ce changement, rien de nous empêche de générer des paramètres de Diffie-Hellman plus robustes, même sur un tout petit serveur genre OlinuXino ou Raspberry Pi avec « ssl_dh_parameters_length = 4096 », par exemple. J'ai mis 4096 bits dans cet exemple car c'est la taille de la clé dans le certificat x509 utilisé par ce serveur. Je rappelle que l'ANSSI recommande 3072 bits et que la NSA dit 3072 bits minimum (voir
http://shaarli.guiguishow.info/?r6npkg ). ;) Après l'ajout de cette directive de configuration, Dovecot générera les paramètres de Diffie-Hellman au prochain reload/restart. :)
Continuons avec Apache httpd :
* « Beginning with version 2.4.7, mod_ssl makes use of standardized DH parameters with prime lengths of 2048, 3072 and 4096 bits and with additional prime lengths of 6144 and 8192 bits beginning with version 2.4.10 (from RFC 3526), and hands them out to clients based on the length of the certificate's RSA/DSA key. » (source :
https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatefile ). C'est déjà une excellente nouvelle : on gagne en sécurité sans avoir quoi que ce soit à configurer.
* On voudrait aussi pouvoir utiliser des paramètres de Diffie-Hellman personnalisés afin d'être sûrs de leur unicité (pour éviter les attaques par pré-calcul) et/ou de leur bonne génération (utiliser un bon générateur de nombre pseudo-aléatoires). Pour cela, on peut utiliser la directive de configuration « SSLOpenSSLConfCmd » (voir
https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslopensslconfcmd ). Exemple : « SSLOpenSSLConfCmd DHParameters "/etc/apache2/ssl/dh_4096.pem" » (voir
http://shaarli.guiguishow.info/?hCgBYQ pour apprendre à générer des dhparam). L'ennui, c'est qu'il faut avoir OpenSSL >= 1.0.2 alors que nous avons uniquement la version 1.0.1 dans Jessie... Une autre idée est de chaîner le fichier contenant les paramètres DH au fichier contenant votre certificat x509 (pour ce faire : cat moncert.pem dh_4096.pem > cert+dh.pem) et de donner ce chaînage à manger à « SSLCertificateFile ». Perso, je ne fais pas ça car je factorise un même fichier certificat entre tous mes logiciels serveur car j'ai la flemme de changer X fichiers à chaque renouvellement de certificat. J'attendrais donc OpenSSL 1.0.2
Terminons avec ejabberd :
* Ejabberd permet enfin de définir la liste des suites cryptographiques que l'on souhaite utiliser ! C'est la directive de configuration « ciphers » dans un listener c2s et la directive « s2s_ciphers » pour la liste à utiliser lors des communications s2s (entre deux serveurs XMPP). On peut utiliser une liste plus robuste comme celles que je donne à l'adresse suivante :
http://shaarli.guiguishow.info/?YddWtQ . Exemple : « ciphers: "EDH+aRSA EECDH+aRSA aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !SEED !CAMELLIA" »
Attention : il y a un comportement totalement incompréhensible : « ciphers » devrait agir uniquement sur la connexion entre mon client XMPP et mon serveur. Or, si je sélectionne uniquement des suites cryptos supportant la confidentialité persistante (parce que je sais que mon client, Gajim, supporte les algos PFS), booom, la plupart de mes contacts deviennent injoignables (remote-server-not-found). Une capture réseau côté serveur montre que mon serveur initie des connexions mais que les négociations TLS échouent et les connexions sont clôturées. Aucun problème avec les contacts qui utilisent, comme moi, un ejabberd et un gajim venant de Jessie ET (et c'est important), qui ont défini une liste de suites cryptos moins moisie que celle par défaut dans leur config ejabberd. Aucun problème si, dans ma config ejabberd, je mets uniquement des suites cryptos PFS dans s2s_ciphers et des suites PFS mais pas seulement dans ciphers... Oui, ça n'a aucun sens, il y a clairement un os quelque part...
* On a également à notre disposition la directive de configuration « protocol_options » (et son amie « s2s_protocol_options » ;) ) qui va nous permettre de virer SSLv3 et de forcer les clients à respecter l'ordre du serveur dans le choix de la suite cryptographique à utiliser. Les autres options possibles sont consultables à l'adresse suivante :
https://github.com/processone/tls/blob/master/c_src/options.h (oui, code is doc, certainement :S ). Ça donne donc ceci :
« s2s_protocol_options:
- "no_sslv2"
- "no_sslv3"
- "cipher_server_preference" »
Et « protocol_options:
- "no_sslv2"
- "no_sslv3"
- "cipher_server_preference" »
* On n'oublie pas de préciser « starttls_required: true » dans le listener c2s. Ça évite que la communication passe en clair si, pour X raisons (bug, attaque par repli par un Homme du Milieu), la négociation TLS échoue. Je rappelle que sur la connexion c2s, il y a votre roster (liste de contacts) qui passe + l'état de vos contacts (absent puis disponible puis absent puis déconnecté,... ;) ) + le contenu des communications par la suite. Vous devriez également préciser « s2s_use_starttls: required » mais là, ça dépend des serveurs de vos contacts... Google ne supporte pas TLS par exemple donc si vous faites ça, vous vous privez de parler à ces personnes-là. :(
* Par défaut, ejabberd génère des paramètres de Diffie-Hellman de 1024 bits ce qui est clairement trop faible de nos jours (logjam tout ça, voir
http://shaarli.guiguishow.info/?S2CJMg ). On peut générer des dhparam plus robustes (voir apache httpd ci-dessus) et les utiliser avec les directives de config « dhfile » et « s2s_dhfile» (voir
https://blog.process-one.net/securing-ejabberd-against-logjam-attacks-and-future-threats/ ) mais... ces directives de configuration arrivent avec la version 15.06 alors que nous avons la 14.07 dans Debian Jessie. :( Upgrader la lib erlang-p1-tls (qui apporte les fonctionnalités TLS) indépendamment ne sert à rien. On peut utiliser la version (de ejabberd ET de erlang-p1-tls) présente dans les backports mais ça sera sans moi : la team security de Debian ne s'occupe pas des backports donc pas question sur un serveur.
* Enfin, cette nouvelle version d'ejabberd, de par les options précédentes, re-ouvre les portes de MUC (discussion à plusieurs sur XMPP, voir
http://shaarli.guiguishow.info/?fBKCuA) sur des serveurs configurés un peu durement niveau crypto comme jabber.ccc.de. \o/