OpenVPN : architecture de VPN fondée sur TLS

OpenVPN utilise deux canaux distincts : le canal de contrôle et le canal de données. Le canal de contrôle gère l’authentification, l’établissement de la session et l’échange de la configuration au moyen de TLS. Le canal de données transporte le trafic VPN proprement dit, chiffré avec un chiffrement symétrique négocié par l’intermédiaire du canal de contrôle. Cette séparation permet à OpenVPN de tirer parti de l’ensemble de l’écosystème TLS pour la gestion des clés.

Le canal de contrôle d’OpenVPN exécute une session TLS complète. Les deux parties s’authentifient au moyen de certificats X.509 signés par une autorité de certification commune (CA). TLS fournit l’échange de clés, la validation des certificats et la négociation des paramètres de chiffrement du canal de données. Comme TLS prend en charge ECDHE, le canal de contrôle fournit une confidentialité persistante parfaite : les clés du canal de données ne peuvent pas être récupérées à partir d’une session interceptée, même avec la clé de la CA.

Le chiffrement du canal de données est négocié par l’intermédiaire du canal de contrôle TLS. OpenVPN 2.4 et les versions ultérieures utilisent par défaut AES-256-GCM, un chiffrement AEAD qui fournit à la fois la confidentialité et l’intégrité en une seule opération. Les versions antérieures utilisaient AES-256-CBC avec HMAC-SHA256 séparément. Les modes AEAD sont préférés, car ils éliminent le besoin d’une vérification MAC distincte et résistent aux attaques par oracle de bourrage.

L’option tls-crypt enveloppe l’intégralité de la session TLS, y compris le message ClientHello, dans une enveloppe symétrique authentifiée par HMAC au moyen d’une clé prépartagée. Ainsi, les clients non authentifiés ne peuvent même pas commencer un échange initial TLS ; leurs premiers paquets sont silencieusement rejetés. Cette protection défend le serveur OpenVPN contre les attaques DDoS par amplification fondées sur TLS et dissimule le fait qu’un serveur VPN est en fonctionnement.

L’ancienne option tls-auth ajoute une balise HMAC aux paquets du canal de contrôle TLS, mais ne les chiffre pas. Elle empêche l’injection de paquets, tout en laissant l’échange initial TLS visible pour les observateurs. tls-crypt chiffre et authentifie l’enveloppe du canal de contrôle, fournissant à la fois une protection contre les attaques par déni de service et une résistance à l’analyse du trafic. tls-crypt est l’option moderne recommandée ; tls-auth est obsolète au profit de tls-crypt-v2.

OpenVPN authentifie les clients au moyen de certificats X.509 signés par l’autorité de certification du VPN. Chaque client reçoit un certificat et une clé privée uniques. Le serveur vérifie la chaîne de certificats et peut éventuellement consulter une liste de révocation des certificats (CRL) afin de rejeter les certificats révoqués. La révocation d’un certificat supprime immédiatement l’accès d’un client, contrairement aux systèmes fondés sur PSK, dans lesquels la modification d’une clé affecte tous les clients.

OpenVPN peut fonctionner sur UDP (par défaut et recommandé) ou sur TCP. UDP évite le problème de TCP sur TCP, dans lequel la perte de paquets entraîne une double retransmission, à la fois au niveau de TCP et au niveau de l’application VPN, ce qui dégrade fortement les performances. Toutefois, certains réseaux bloquent UDP. Exécuter OpenVPN sur le port TCP 443 peut contourner les pare-feu qui n’autorisent que le trafic HTTPS, au prix d’une dégradation des performances lorsque des paquets sont perdus.

OpenVPN fonctionne en mode tun (routage) ou en mode tap (pont). Le mode tun crée une interface réseau IP point à point qui achemine les paquets IP entre le client et le réseau VPN. Le mode tap crée une interface pont Ethernet qui transmet les trames Ethernet, y compris les diffusions et les protocoles non IP. Le mode tun est plus efficace et convient à la plupart des cas d’utilisation des VPN ; le mode tap est nécessaire pour relier des segments réseau ou utiliser des protocoles non IP.

Les serveurs OpenVPN peuvent envoyer automatiquement des directives de configuration aux clients qui se connectent. Parmi les directives courantes figurent push "route 10.0.0.0 255.0.0.0" (ajouter une route sur le client), push "dhcp-option DNS 10.0.0.1" (définir le serveur DNS) et push "redirect-gateway def1" (acheminer tout le trafic du client via le VPN). Cela centralise la gestion de la configuration des clients sans modifier les fichiers de configuration individuels des clients.

OpenVPN assure une confidentialité persistante parfaite grâce à TLS ECDHE (Diffie-Hellman éphémère sur courbe elliptique) dans le canal de contrôle. Une nouvelle paire de clés éphémères est utilisée pour chaque session TLS ; la clé de session ne peut donc pas être dérivée de la clé privée du certificat à long terme du serveur. Intercepter aujourd’hui du trafic chiffré et obtenir ultérieurement le certificat du serveur ne permet toujours pas de déchiffrer les sessions passées.

OpenVPN 2.5 a rendu obsolète le chiffrement Blowfish (BF-CBC), qui était historiquement utilisé par défaut. BF-CBC utilise une taille de bloc de 64 bits vulnérable aux attaques par anniversaire SWEET32 lors des sessions longues. Les versions modernes d’OpenVPN utilisent par défaut AES-256-GCM. OpenVPN 2.5 a également rendu obsolètes les chiffrements non-AEAD du canal de données et renforcé les exigences relatives à la version minimale de TLS, en supprimant la prise en charge de TLS 1.0 et 1.1.

Quelle est la fonction principale du canal de contrôle d’OpenVPN ?

Récapitulatif d’OpenVPN : le canal de contrôle utilise TLS pour l’authentification et la négociation des chiffrements, le canal de données utilise un chiffrement AEAD négocié (AES-256-GCM par défaut), tls-crypt enveloppe TLS pour empêcher les échanges initiaux non authentifiés, ECDHE fournit la confidentialité persistante, l’authentification des clients repose sur des certificats avec révocation par CRL, UDP est préféré à TCP pour les performances et le mode tun est privilégié pour les cas d’utilisation du routage IP.