Chiffrement, compression : révisons nos configurations OpenVPN

Sa gratuité et sa simplicité d’utilisation ont fait son succès. Son code source fourni sous licence GPL V2, fait qu’OpenVPN est également l’épine dorsale de plusieurs solutions commerciales.

Même si Wireguard apparaît comme LA technologie qui remplacera prochainement IPSec et OpenVPN selon plusieurs experts, Wireguard reste une solution jeune (apparue en 2015) et encore peu maîtrisée des administrateurs réseaux, qui on fait le choix de la facilité, s’en remettre à des technologies plus matures, et surtout qu’ils maîtrisent, ou plutôt, connaissent !

En effet, pour en revenir à la solution OpenVPN, elle fêtera ses 18 ans au mois de mai prochain.
Si c’est une solution qui est toujours présente dans vos SIH, directement ou indirectement via des solutions commerciales, avant de fêter son entrée à l’age de la majorité, un petit check-up s’impose.

#CHIFFREMENT

Le chiffrement proposé par OpenVPN repose sur le protocole SSL / TLS. La version 1.0 de TLS reste la version active par défaut, alors qu’elle est aujourd’hui dépréciée et que les éditeurs des principaux navigateurs Web ont annoncé qu’ils ne supporteraient plus les versions 1.0 et 1.1 de TLS dès 2020 [2].
Alors, activer TLS 1.2 (disponible depuis la version 2.3.3) peut s’avérer judicieux pour augmenter le niveau de sécurité de ses connexions. Une action, qui au bas mot, prend deux minutes, temps d’authentification sur la machine, de paramétrage et de redémarrage du service inclus.

Il suffit d’ajouter dans le fichier de configuration du serveur la ligne suivante :

tls-version-min 1.2

À noter également, la version 1.3 de TLS est implémentée dans OpenVPN depuis la version 2.4.5 [3]. Malgré son haut niveau de sécurité, il est peut être préférable d’attendre encore quelques mois avant de l’activer, afin de conserver une rétro-compatibilité avec les clients d’une version inférieure, encore présents dans les dépôts de versions stables de certaines distributions Linux.

#COMPRESSION

Par défaut, OpenVPN utilise le mécanisme de compression LZO, un mécanisme dont l’extrême vulnérabilité (VORACLE) a été démontrée cet été lors de la dernière édition de la Def Con par le chercheur Nafeez (@skeptic_fx) [4]. Une vulnérabilité qui permet de déchiffrer le trafic non chiffré à l’intérieur du tunnel, comme ici avec le cas d’une connexion HTTP à l’intérieur d’un tunnel VPN :

Dans un communiqué daté du 29 septembre [5], OpenVPN recommande la désactivation de la compression LZO pour les versions de la branche 2.3.X et l’utilisation de l’algorithme de compression  stub-v2 pour les versions de la branche 2.4.X afin d’éviter toute interception de données non chiffrées transitant dans le tunnel.
Là encore deux lignes à insérer dans le fichier de configuration du serveur suffisent à corriger ce problème :

Pour les versions 2.3.X : 

comp-lzo no

• push "comp-lzo no"

Pour les versions 2.4.X :

compress stub-v2

• push "compress stub-v2

Afin de s’assurer que la compression LZO est bien désactivée, il faut que dans les logs du serveur OpenVPN, la variable LZO soit égale à 1 :

lzo = 1

La simplicité d’amélioration de la sécurité est tellement « enfantine », qu’il serait vraiment dommage de s’en priver.

[1] https://www.wireguard.com

[2] https://www.forum-sih.fr/viewtopic.php?f=78&t=1139#p4159

[3] https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn24#OpenVPN2.4.5

[4] https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf

[5] https://community.openvpn.net/openvpn/wiki/VORACLE