ça m'intéresse aussi

Si j'ai bien compris — ce qui est loin d'être certain :) — voilà ce que j'en sais. TLS permet de sécuriser un canal de communication par le chiffrement du contenu et l'authentification des interlocuteurs. C'est un processus basé sur un système de clefs publiques et privées — on parle de chiffrement asymétrique (algorithme RSA, par exemple) — et un certificat d'authentification.

Le problème du chiffrement asymétrique et qu'il est assez gourmand en ressources. Ainsi, après s'être authentifiés et avoir mis en place un canal sécurisé, les interlocuteurs vont se mettre d'accord sur un secret commun afin de pouvoir communiquer via un chiffrement symétrique (algorithme AES, par exemple). Au cas où la communication était écoutée — malgré le chiffrement asymétrique mis en place — le secret commun ne va pas être échangé en clair. L'échange de clés Diffie-Hellman — le fameux dhparam — permet de s'échanger un tel secret sans qu'une tierce personne, même à l'écoute, puisse le connaître.

Voir la page Wikipédia : https://fr.wikipedia.org/wiki/%C3%89change_de_cl%C3%A9s_Diffie-Hellman

Pas mieux.

okay ! Merci Cypouz !
Une dernière question, j'ai bien compris le principe maintenant, mais qu'est-ce que l'on génère quand on fait cette commande :
openssl dhparam -out /etc/prosody/certs/dh-2048.pem 2048

et pourquoi ça prend tant de temps ?

Cette commande génère les paramètres de Diffie-Hellman utiles à l'échange sécurisé du secret commun.

Quant au temps que cela met... on ne se représente même pas la difficulté de calculer de tels paramètres ! Le processeur peut être à 100 % pendant un bon petit moment. Je n'ose imaginer ce que cela doit donner sur un RPi :)

L'ordinateur cherche à trouver de très grands nombre premiers « sûrs ». Pour OpenSSL, cela signifie un nombre premier dont le nombre précédent divisé par deux est également premier. Voici ce qu'en dit un gars sur StackExchange :

A "safe prime" is a prime p such that (p-1)/2 is also a prime. This allows the use of any integer in the 2..p-2 range to be used as generator g, in particular g = 2, which yields a slight performance advantage. On the other hand, producing a safe prime is challenging: roughly speaking, when dealing with 1024-bit integers, only 1/1000th of them are prime, and only 1/1000th of these primes are "safe primes", hence a search loop which tries a million potential values.

Et ça, c'est pour du 1024 bits... Alors que toi tu génères une clef de 2048 bits ! Ne soyons pas trop pressés que la NSA nous oblige à générer des dhparam de 4096 bits ou plus... :) Va falloir s'acheter des ordinateurs quantiques !

Cf. https://security.stackexchange.com/questions/56214/what-are-the-openssl-standard-diffie-hellmann-parameters-primes/56218#56218

Ok, merci beaucoup pour ces explications très claires ! J'aime bien savoir exactement ce que je met en place :-)
Ça n'a finalement pris qu'une demi-heure, ça va pour un Rasp ^^

Y'a pas un truc avec l'entropie aussi ?

@Cypouz : perso je génère déjà des clefs de 4096 bits. Ça me laisse du temps avant de devoir tout regénérer quand on considérera que 2048 bits n'est plus assez sécurisé. Vous avez dit « Parano » ? C'est pas parce qu'on est parano qu'on n'a pas de bonnes raisons de l'être :D

@Stanislas : oui, la génération de la clé consomme de l'entropie, du coup si l'ordi ne fout rien, ça prend plus de temps que quand il fait autre chose (car une autre action, si possible "aléatoire" comme jouer à un jeu, génère de l'entropie)

Pour la génération de nombres « aléatoires », oui. Mais je ne crois pas que cela concerne les dhparam, plus directement le chiffrement asymétrique.

Pour l'entropie, d'un coté, si tu ne fais rien ça prend plus de temps. Mais d'un autre, si tu joues en même temps tu consommes de la charge processeur... et la génération de clefs prend plus de temps. Dur dilemme ;)

@Framasky : pour les clefs 4096 bits, tu parles des clefs asymétriques ou des paramètres de D.-H. ? Parce que c'est pas vraiment le même délai de génération...

Si si : https://mta.openssl.org/pipermail/openssl-users/2015-January/000254.html

OK.

Je parlais des paramètres DH.

16384 bits ! :)))) Il est complètement ravagé :D Son ordi a tourné pendant 3 semaines dans un des cas ! J'imagine même pas la tête de la pâte thermique :D

Et tu te disais parano ? Petit joueur, va :D

Le mec de la mailing list a dit "testing purpose" hein.

Pas sûr qu'un navigateur accepte des paramètres aussi gros ;-)