Quels paquets OpenVPN le digest auth protège-t-il ?
L'option auth couvre moins que ce qu'un profil suggère. Parcourez le canal, le cas AEAD et la protection du canal de contrôle avant de définir une politique de digest.
La plupart des débats sur les digests OpenVPN partent du mauvais paquet. Lire auth SHA256 comme « n'accepte que les pairs qui proposent SHA256 » est la première chose à désapprendre. L'option nomme un digest pour des paquets précis, et quels paquets c'est dépend du canal et du fait que ce canal soit AEAD. Parcourez les quatre questions ci-dessous dans l'ordre ; chacune resserre ce que le réglage peut signifier dans votre déploiement.
Nommez le canal que le réglage est censé protéger
OpenVPN possède un canal de contrôle qui transporte le trafic de la poignée de main TLS et un canal de données qui transporte la charge utile du tunnel. Le digest auth joue un rôle dans les deux, mais pas le même, et le profil rend rarement la différence visible. Notez lequel des deux vous cherchez à restreindre avant de toucher un fichier de configuration.
Le tableau ci-dessous est la version courte de la façon dont la même option atterrit dans chaque contexte.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Vérifiez si le canal de données est AEAD avant de vous y fier
Si le chiffrement de données négocié est AES-GCM ou CHACHA20-POLY1305, le canal de données s'authentifie lui-même et le digest séparé ne fait pas le travail que vous imaginez peut-être. Les deux sont des constructions AEAD, l'intégrité est donc produite par la même opération qui chiffre la charge utile. Ce n'est pas une régression, mais cela signifie qu'une politique justifiée comme « chaque paquet de données est HMAC-SHA256 » est factuellement fausse sur ce tunnel. Confirmez la valeur négociée dans le journal du serveur ou la sortie d'état du client avant de réécrire la politique.
Inspectez le chiffrement réellement négocié plutôt que la liste du profil, car la négociation peut tomber sur un autre membre de l'ensemble. data-ciphers AES-256-GCM:AES-128-GCM est une liste de négociation, et les deux entrées sont AEAD, donc aucune des deux ne consomme le digest auth pour la protection de la charge utile.
Traitez la protection du canal de contrôle comme une décision à part
tls-auth ajoute un HMAC aux paquets du canal de contrôle et tire son digest du réglage auth, c'est pourquoi un tunnel AEAD peut encore avoir un digest significatif configuré. tls-crypt est un autre agencement avec sa propre protection fixe, alors ne supposez pas qu'il hérite de chaque propriété de tls-auth. Lisez la documentation du mécanisme choisi au lieu de transférer des hypothèses entre eux.
Les deux pairs doivent aussi s'accorder sur l'agencement et sur le sens de la clé. Un digest qui correspond mais un fichier de clé utilisé dans le mauvais sens produit une poignée de main qui échoue pour des raisons que le réglage du digest ne peut pas expliquer.
Gardez auth séparé de la négociation de chiffrement et des certificats
Trois réglages sont constamment confondus : le digest auth, la liste des chiffrements de données et l'algorithme de signature du certificat. Changer le premier ne réémet pas de certificat, ne sélectionne pas son digest de signature et ne crée pas de méthode utilisateur-mot de passe. Les définitions des options de protocole dans les sources OpenVPN 2.6 décrivent chacune dans sa propre section, ce qui rappelle utilement qu'il s'agit de réglages indépendants.
Quand un pair refuse de se connecter après un changement de digest, la cause est généralement une divergence dans l'un des deux autres réglages. Lisez les deux extrémités avant de changer l'un ou l'autre.
Écrivez la politique et comparez-la aux configurations en cours
Une déclaration au niveau de la flotte devrait nommer explicitement les modes de canal de données autorisés et la protection du canal de contrôle choisie, dans la même phrase. Cette phrase est vérifiable ; « nous utilisons SHA256 » ne l'est pas. Comparez-la ensuite aux profils effectifs du serveur et du client plutôt qu'à un modèle dans un dépôt.
Terminez en consignant ce que chaque tunnel a réellement négocié et quel mécanisme a authentifié ses paquets. Une ligne auth visible dans un profil n'est qu'une preuve d'intention de configuration, et l'intention est la partie la moins coûteuse du contrôle.