Un certificat RSA peut-il fonctionner avec dh none dans OpenVPN ?

Voici une configuration serveur qui indique dh none à côté d'un certificat qui indique RSA, avec le soupçon tenace que l'un des deux doit être faux. Rien n'est faux. Le certificat signe et authentifie ; l'échange de clés établit un secret partagé. Ce sont deux tâches différentes dans la même poignée de main, et TLS permet à un certificat RSA d'authentifier une poignée de main qui utilise un accord éphémère sur courbe elliptique.

La confusion arrive généralement avec un guide de migration. Il dit de remplacer le fichier de paramètres DH par dh none, le lecteur remarque que le certificat n'est pas un certificat de courbe elliptique, et les deux faits sont traités comme une contradiction.

Pourquoi les deux réglages semblent liés

L'ancienne configuration d'OpenVPN demandait un fichier de paramètres DH parce que Diffie-Hellman sur corps fini a besoin de paramètres de domaine sur lesquels les deux côtés s'accordent. La directive dh pointait vers ce fichier. Quand un déploiement passe à ECDH, les paramètres proviennent plutôt d'une courbe nommée, et le fichier n'est plus nécessaire, ce qu'exprime dh none.

Les certificats sont un axe séparé. Ils portent une clé publique et une signature qui prouvent l'identité du serveur, et cette clé peut être RSA ou courbe elliptique indépendamment de la manière dont la clé de session est convenue. Une poignée de main qui utilise ECDHE pour l'accord de clé et RSA pour l'authentification est courante et largement déployée.

Le nommage aggrave le chevauchement. La courbe elliptique apparaît dans les noms de suites ECDHE et ECDSA, il est donc facile de supposer que toute connexion mentionnant une courbe doit impliquer un certificat de courbe. Ce n'est pas le cas.

Lire correctement un nom de suite TLS 1.2

Prenez ECDHE-RSA-AES256-GCM-SHA384. Le premier jeton est la famille d'échange de clés : Diffie-Hellman éphémère sur courbe elliptique. Le second est la famille d'authentification : RSA. Le reste décrit la protection des enregistrements et le hachage utilisé dans la poignée de main.

Une suite ECDHE-ECDSA utilise la même famille d'échange de clés avec une méthode d'authentification différente, elle a donc besoin d'un certificat de courbe elliptique. Une suite DHE-RSA utilise Diffie-Hellman éphémère sur corps fini avec authentification RSA, et celle-là a bien besoin de paramètres DH.

Lisez un nom de suite de gauche à droite et affectez chaque partie à sa tâche. Une fois les jetons séparés, la question passe de « mon certificat correspond-il à dh none » à « mon serveur autorise-t-il une suite dont l'échange de clés n'a pas besoin d'un fichier DH ».

Ce que dh none désactive réellement

dh none indique au serveur de ne pas charger de fichier de paramètres DH sur corps fini. Il ne désactive ni l'authentification, ni la validation des certificats, ni TLS lui-même. Il exige en revanche que l'échange de clés négocié n'ait pas besoin de ces paramètres, ce qui signifie en pratique une suite ECDHE ou une poignée de main TLS 1.3.

C'est de cette exigence que vient la panne. Si la politique de chiffrement TLS du serveur est limitée aux suites DHE, ou si un client ne propose que celles-ci, retirer le fichier de paramètres ne laisse aucune méthode d'échange de clés utilisable et la poignée de main échoue. L'erreur apparaît généralement pendant la poignée de main du canal de contrôle, avant toute authentification d'utilisateur. Lisez la liste des chiffrements avant d'accuser le fichier manquant.

Du côté de la courbe elliptique, la courbe est choisie par la configuration TLS du serveur, et OpenVPN propose une option pour la choisir sur les anciennes branches. TLS 1.3 gère la négociation du groupe à l'intérieur du protocole et ne consulte pas du tout le fichier DH.

dh none n'est pas en soi une baisse de sécurité. La force de l'échange dépend alors de la courbe et de la suite réellement négociées, c'est pourquoi l'étape suivante consiste à regarder ce que les pairs ont choisi plutôt que le fichier absent.

Confirmer la négociation avant de modifier

Augmentez la verbosité du serveur et du client et lisez la ligne du canal de contrôle qu'OpenVPN imprime après une connexion. Elle nomme la version de TLS et le chiffrement négocié, et indique le type de clé du certificat du pair. Cette seule ligne répond à la question que le fichier de configuration ne fait qu'impliquer.

Si elle montre TLS 1.2 avec une suite ECDHE-RSA et un certificat RSA, la combinaison est exactement ce qu'attend dh none, et il n'y a rien à réparer. Si elle montre une suite DHE ou un échec de poignée de main sans chiffrement commun, le correctif se trouve dans la politique de chiffrement ou les capacités du client, pas dans le certificat.

Testez le client le plus ancien que vous comptez prendre en charge, car un client actuel peut négocier TLS 1.3 tandis qu'un plus ancien est limité aux suites TLS 1.2. Si le plus ancien client n'a aucun chevauchement, élargissez les suites autorisées ou mettez ce point de terminaison à niveau.

Ne désactivez pas la vérification des certificats pour contourner un échec de poignée de main. L'échec vous dit que les pairs n'ont pas pu s'accorder sur un échange de clés, et désactiver la vérification supprime la garantie d'identité sans résoudre l'accord.

Liste de contrôle : le certificat est-il RSA, une suite ECDHE est-elle autorisée, le journal montre-t-il cette suite, et le client pris en charge le plus ancien la négocie-t-il aussi ? Si les quatre réponses sont oui, dh none fait son travail.