Questions sur les protocoles utilisés

Les protocoles utilisés dépendent bien sûr au moins du type de VPN que l'on met en oeuvre Ici nous prendrons comme cas les VPN légers du type PPP over SSH.

Dans ce paragraphe il est question des protocoles qui font l'objet de la sécurisation (couche OSI $>$2) et non de ceux sous-jacents à un réseaux local.

Sur le papier le fait d'utiliser par exemple RSA en algorithme de chiffrement symétrique pour rendre la clé de session secrète pourrait laisser imaginer que cette phase est sûre or en passant par l'attaque frontale par factorisation de la clé publique RSA (n=pq et PGCD(p,q)=1) à celles basées sur le mauvais choix de l'exposant publique (WIENER, DE WEGER) entre autres ou la simple faille d'implémentation ou de protocole il n'est pas censé de faire confiance en du chiffrement sans se poser de questions.
Par ailleurs GnuPG propose par exemple en plus de leur outil un petit utilitaire dit générateur d'entropie (à décortiquer !) ce qui montre bien que leur seul outil ne peut être en soi une solution à tous les problèmes.

Si gérer les trousseaux de clé de façon non automatique réduit les chances en apparence de voir l'intégrité de ces données compromises il n'en n'est rien. L'administrateur qui envoie ces données par mail par exemple doit s'assurer de la sécurité (confidentialité, intégrité) des connexions générées. En l'occurrence, le fait que le message en clair (données qui suivent la commande DATA du protocole SMTP terminées par un `` . '' final) circule sur parfois plusieurs relais SMTP fait dors et déjà trembler . Quelqu'un pourrait rétorquer qu'il est possible de chiffrer le message avec GnuPG par exemple. Oui mais comment se communiquer les clés publiques ? Le poisson se mort la queue.

L'utilisation de certificats signés (digest) par une autorité de certification comme Verisign oblige d'un part à dépenser de l'argent et d'autre part à faire confiance à un tiers.

En réalité le protocole d'échange des clés dans le cas d'une grosse infrastructure se doit d'être automatisé car personne n'a le temps de gérer cette phase. Des protocoles comme IKE proposent une solution.

root 2004-05-04