auth-nocache avec un fichier d’identifiants : utile ou dangereux ?

OpenVPN imprime au démarrage un avertissement qui suggère auth-nocache, et la réponse tentante est d’ajouter l’option et de regarder la ligne disparaître. Ce conseil suppose une connexion interactive. Dès que le nom d’utilisateur et le mot de passe vivent dans un fichier, la comparaison change : l’option cesse de protéger la copie durable, et sur un client qui abandonne ses privilèges, elle peut casser la renégociation plus tard. Deux modèles de stockage valent d’être tenus à part avant de modifier un profil.

Deux façons de répondre à la demande d’identifiants

Le premier modèle est une personne qui saisit les identifiants dans un terminal, ou une interface d’administration qui les garde pour la session. OpenVPN conserve cette copie pour pouvoir répondre à la renégociation suivante sans redemander, et c’est exactement l’objet de l’avertissement. Rien sur le disque n’est en jeu, donc la seule chose à protéger est le processus qui détient la valeur. Fermez le client et la copie disparaît avec lui.

Le second modèle est auth-user-pass pointant vers un fichier, où le fichier est le magasin et le client le lit quand une valeur est nécessaire. L’exposition qui compte ici n’est pas la mémoire du processus mais les permissions et le propriétaire de ce fichier. L’avertissement de démarrage vient des directives de la configuration, non d’une inspection de la façon dont vous fournissez le mot de passe, il apparaît donc dans les deux modèles et ne désigne ni l’un ni l’autre.

Le reste de cette comparaison découle de cette séparation : gestion de la mémoire pour un modèle, gestion du fichier et identité du processus pour l’autre.

Ce que auth-nocache jette réellement

Avec une connexion interactive, --auth-nocache retire la copie stockée de la mémoire après qu’elle a servi. Le coût est une nouvelle demande à chaque intervalle de renégociation, car le tour suivant ne peut pas réutiliser ce qui a été jeté.

Avec une connexion adossée à un fichier, le client peut relire le fichier, donc le rejet est surtout invisible. Il devient visible au seul endroit où les gens ne l’attendent pas : après que le démon a abandonné ses privilèges, si le fichier d’identifiants n’est pas lisible par le compte sous lequel il tourne désormais.

Ajoutez l’option parce que vous comprenez ce compromis, pas parce qu’un avertissement est apparu. Une option ajoutée pour rendre un journal plus silencieux est une option dont personne n’a mesuré l’effet.

Où le chemin adossé à un fichier casse

Un client qui démarre en root pour ouvrir le périphérique tunnel puis bascule vers user et group lit le fichier d’identifiants deux fois : une fois avant le basculement, une fois à la renégociation qui suit. Si le fichier est en mode 600 et appartient à root, la seconde lecture échoue, et la panne apparaît une heure plus tard comme une erreur d’authentification qui ressemble à un problème de serveur. Vérifiez le journal du client autour de l’intervalle de renégociation, puis vérifiez le compte et le fichier ensemble.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Les deux lignes comptent. La première vous dit qui peut lire le fichier, la seconde vous dit qui est réellement le démon en cours d’exécution, et un écart entre les deux explique une panne qu’aucune ressaisie du mot de passe ne corrigera.

Les correctifs pratiques manquent de glamour : déplacez le fichier vers un répertoire et un propriétaire que le compte du démon peut lire, ou gardez la lecture privilégiée et confirmez que votre client ne lit qu’une fois. Ne réglez pas cela en rendant le fichier lisible par tous.

Le cas qui veut vraiment l’option

Une connexion portant un code à usage unique veut auth-nocache pour une autre raison. Un code à usage unique est consommé par la première authentification, donc une copie en cache est inutile à la renégociation suivante et une valeur périmée pourrait même être rejouée.

C’est une question sur le type d’identifiant, pas sur l’endroit où il est stocké. Un mot de passe statique dans un fichier protégé a le profil inverse : il doit être lisible à chaque renégociation, et la protection nécessaire porte sur le fichier.

Gardez ces deux raisons séparées dans les commentaires du profil, sinon le prochain administrateur supposera que l’option est là pour la raison qu’il aurait choisie.

La comparaison en une décision

Choisissez le modèle interactif quand une personne est présente et que la fraîcheur compte, et acceptez la demande répétée comme son coût. Choisissez le modèle fichier quand le client tourne sans surveillance, et consacrez l’effort au propriétaire, au mode et à l’abandon des privilèges.

Aucun des deux modèles ne rend un mot de passe stocké sûr à lui seul, et aucun ne rend l’avertissement de démarrage significatif.

Si l’avertissement est la seule raison pour laquelle vous avez ouvert le profil, consignez la décision plutôt qu’une option inexpliquée : les identifiants viennent d’un fichier lisible par le compte du démon, une renégociation a été vue réussir, et la section du manuel OpenVPN 2.6 sur la renégociation a été lue avant de changer son intervalle. Cette note survit à n’importe quel indicateur isolé.