Nouvelle option tls-crypt d'OpenVPN
J'ai lu des nouvelles options tls-crypt Pour OpenVPN 2.4, mais je ne suis pas sûr de bien les comprendre.
J'ai lu les pages de manuel et l'aperçu de la sécurité pour OpenVPN (qui semble manquer l'option tls-crypt) Et c'est ainsi que je l'ai compris.
En mode TLS avec l'utilisation de tls-crypt, La connexion entre les deux pairs est établie, chiffrée et authentifiée à l'aide du fichier de clé défini avec l'option tls-crypt. Ensuite, les certificats sont utilisés pour authentifier les homologues. En cas de succès, les clés HMAC et de chiffrement/déchiffrement sont générées et échangées sur la connexion TLS établie. Tout cela se produit toujours via la connexion chiffrée/authentifiée avec le fichier de clé tls-crypt.
Et la confidentialité et la protection supplémentaires contre l'identification du tunnel OpenVPN sont obtenues car la connexion TLS du canal de contrôle est chiffrée par la clé statique tls-crypt.
Ma compréhension de l'option tls-crypt Est-elle correcte?
La réponse tl; dr est: Oui, votre compréhension est correcte.
En mode TLS, OpenVPN établit une session TLS pour effectuer un échange de clés sur cette session TLS afin d'obtenir les clés utilisées pour chiffrer/authentifier les données de charge utile du tunnel. Il s'agit d'une session TLS normale, comme si vous ouvriez un site Web HTTPS dans votre navigateur, sauf qu'il n'effectuera pas seulement l'authentification du serveur mais également l'authentification du client et que le client aura donc également besoin d'un certificat avec clé privée.
L'échange de session TLS sur lui-même doit être sécurisé, après tout c'est tout ce que vous avez lorsque vous visitez un site de banque en ligne par exemple, mais ce n'est que la théorie. En pratique, chaque protocole a des faiblesses et même si le protocole n'en aurait pas, la mise en œuvre du protocole peut aussi avoir des faiblesses. Pour rendre encore plus difficile pour un attaquant d'utiliser ces faiblesses, vous pouvez utiliser tls-crypt, qui cryptera et authentifiera les paquets TLS à l'aide de clés provenant d'un fichier de clés statique. Désormais, un attaquant devrait également mettre la main sur une copie de ce fichier de clé, sinon il connaîtrait même une attaque utilisable et aurait la possibilité de la supprimer (par exemple, être en mesure de surveiller le trafic ou d'effectuer une connexion homme au milieu). ) ne l'aidera pas.
Avec tls-crypt, toutes les données exécutées sur le "canal TLS" sont cryptées et authentifiées avec les mêmes algorithmes que les données de charge utile du tunnel et avec les clés du fichier de clés statiques. Pour les données de charge utile TLS (authentification utilisateur, échange de clés, configuration push, etc.), cela signifie que ces données sont chiffrées et authentifiées deux fois. Une fois par tls-crypt et une fois par la session TLS elle-même, car une session TLS elle-même est utilisée pour crypter et authentifier les données et, bien sûr, même si tls-crypt n'est pas utilisé, l'authentification de l'utilisateur, l'échange de clés et la configuration Push doit être chiffré et authentifié; sinon, comment l'ensemble du protocole serait-il sécurisé si ce n'était pas le cas?
Malgré l'ajout d'une sécurité supplémentaire pour l'administrateur VPN paranoïaque (bien que, compte tenu des horribles bogues SSL/TLS trouvés ces deux dernières années, ces personnes semblent beaucoup moins paranoïaques qu'auparavant), cela a également un autre effet positif: il empêche certains types de attaques par déni de service. Même si un attaquant ne peut pas pénétrer dans votre VPN, il peut toujours essayer d'ouvrir des milliers de sessions TLS en même temps. N'étant pas en mesure de fournir un certificat valide, toutes ces sessions échoueront à la fin mais jusqu'à ce que ce soit le cas (cela prendra 60 secondes par défaut), un objet de session TLS peut utiliser une quantité importante de ressources de mémoire pour un petit appareil intégré et en ouvrir des milliers peut rapidement faire tomber un tel appareil. Avec tls-crypt, déjà le premier paquet envoyé ne s'authentifiera/décryptera pas correctement et sera donc immédiatement rejeté. Dans ce cas, il n'est même pas nécessaire de créer un objet de session TLS.