Un certificat VPN personnalisé n’est pas une couche de chiffrement supplémentaire

Installer un certificat personnalisé sur un point de terminaison VPN donne l’impression d’ajouter une protection, parce que certificats et chiffrement apparaissent partout ensemble. En pratique, cela change deux choses : l’identité que présente le point de terminaison et l’émetteur auquel son pair accepte de faire confiance. Ni l’une ni l’autre n’enveloppe vos données une seconde fois. Si le besoin réel est un second canal protégé, il vous faut un second canal avec ses propres points de terminaison, pas un autre certificat.

Trois tâches distinctes dans une poignée de main TLS 1.3

RFC 8446 garde ces éléments séparés, et cette séparation est toute la réponse. Le message Certificate transporte la chaîne de certificats du point de terminaison. CertificateVerify prouve la possession de la clé privée correspondante et lie la transcription de la poignée de main. La couche d’enregistrement protège le trafic avec les clés de trafic négociées.

Remplacez le certificat et les deux premiers éléments changent. La protection des enregistrements ne s’exécute pas deux fois et ne devient pas plus forte parce que l’émetteur est désormais privé.

Ce qu’une CA privée apporte réellement

Elle apporte un système d’identité maîtrisé : vous décidez qui est émis, vous décidez quels émetteurs les pairs acceptent, et vous pouvez révoquer selon votre propre calendrier. C’est vraiment utile lorsque vous exploitez les deux extrémités.

Elle importe aussi des obligations. La confiance doit être distribuée délibérément, la vérification du pair doit rester active et le cycle de vie des identifiants doit avoir un responsable. Une CA privée n’est un raccourci autour d’aucune de ces trois choses.

Quand un second canal est la bonne réponse

Supposons qu’une application ouvre un HTTPS vérifié vers son propre service alors que ses paquets passent aussi par un VPN. Cette conception a deux frontières aux points de terminaison potentiellement différents, et c’est à cela que ressemble un second canal protégé.

La distinction compte à la passerelle. Si la session TLS de l’application se termine à la passerelle VPN plutôt qu’à l’application, la protection que vous croyiez avoir au-delà du tunnel n’est pas là. Notez qui termine chaque canal avant de revendiquer la propriété.

Demandez ce que l’installation change

Une demande d’installation de certificat peut signifier trois choses différentes. Elle peut changer l’identité du client lui-même, une ancre de confiance propre à une application, ou la confiance à l’échelle de la plateforme pour tout ce qui est sur l’appareil. Ce n’est pas équivalent, et seule la dernière affecte des logiciels sans rapport.

Demandez laquelle des trois est visée, puis ce qu’elle est censée accomplir. Si la réponse est plus de chiffrement, la proposition vise le mauvais mécanisme.

Écrivez les frontières

Pour chaque canal, notez les points de terminaison, l’identité que chaque côté vérifie et ce que l’opérateur au milieu peut voir. Notez ensuite le comportement en cas d’échec : ce qui se passe quand la vérification échoue et ce qui se passe quand le canal est refusé.

Deux lignes sur une page tranchent généralement un débat qu’une rotation de certificat ne peut pas trancher.

Décidez avec trois questions

Le problème est-il qui le point de terminaison prétend être, ou ce qui arrive aux données ? La protection doit-elle se poursuivre au-delà de la passerelle VPN jusqu’à une application précise ? Et pouvez-vous nommer les deux points de terminaison qui termineraient un second canal ?

Si la première question est la bonne, corrigez l’identité et la confiance. Si c’est la deuxième ou la troisième, concevez le second canal et laissez le certificat là où il doit être.