La solution choisie par Wireguard est de créer une nouvelle version qui sera incompatible avec la précédente.
Dans l'article Cryptographic Agility and Superior Alternatives l'auteur explique pourquoi l'agilité est une mauvaise chose du point de vu de la sécurité en prenant l'exemple de JWT et qu'elles sont les alternatives possibles. Le cas de Wireguard est évoqué.
Ce que j'en comprend, c'est que la question est : à qui revient la responsabilité de l'algo à utiliser ? A ceux qui conçoivent le protocole, aux développeurs qui vont utiliser une lib (JWT, openSSL) voir même à l'utilisateur (configuration SSL/TSL dans apache par exemple).
J'aurais tendance à accorder ma confiance aux premiers, et donc n'avoir qu'un seul algo possible. Je comprend que cela permet de garder une base de code plus réduite ce qui est un bon point, le problème d'incompatibilité est de toute manière existant avec l'agilité. Quand il a fallu désactiver les vieux algos sur SSL/TLS sur les serveurs web, on s'est rendu incompatible avec certains clients. A l'inverse quand on avait des vieux OS sur les serveurs et que les navigateurs coupaient les vieux algos, cela entrainait aussi des compatibilités.
Mais je vois mal utiliser la méthode choisie par Wireguard pour le web, mais laisser la responsabilité aux administrateurs systèmes n'est pas toujours la bonne solution (j'en suis un). Mais pour le cas d'usage de Wireguard, qui est dans un réseau maîtrisé, ça me semble être une très bonne approche. En tant qu'admin je sais que je dois tenir à jour les versions du logiciel mais pas en plus à connaître les arcanes de la configuration des algos de crypto pour avoir une installation sécurisée.
[^] # Re: Une seule suite crypto ?
Posté par Matthieu Duchemin (site web personnel) . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à 4. Dernière modification le 22 août 2022 à 21:53.
La solution choisie par Wireguard est de créer une nouvelle version qui sera incompatible avec la précédente.
Dans l'article Cryptographic Agility and Superior Alternatives l'auteur explique pourquoi l'agilité est une mauvaise chose du point de vu de la sécurité en prenant l'exemple de JWT et qu'elles sont les alternatives possibles. Le cas de Wireguard est évoqué.
Je ne suis pas assez compétant en sécu pour discuter son point de vue, Bruce Shneier a quant à lui évoqué sa préférence pour l'agilité récemment (https://www.schneier.com/blog/archives/2022/08/nists-post-quantum-cryptography-standards.html).
Ce que j'en comprend, c'est que la question est : à qui revient la responsabilité de l'algo à utiliser ? A ceux qui conçoivent le protocole, aux développeurs qui vont utiliser une lib (JWT, openSSL) voir même à l'utilisateur (configuration SSL/TSL dans apache par exemple).
J'aurais tendance à accorder ma confiance aux premiers, et donc n'avoir qu'un seul algo possible. Je comprend que cela permet de garder une base de code plus réduite ce qui est un bon point, le problème d'incompatibilité est de toute manière existant avec l'agilité. Quand il a fallu désactiver les vieux algos sur SSL/TLS sur les serveurs web, on s'est rendu incompatible avec certains clients. A l'inverse quand on avait des vieux OS sur les serveurs et que les navigateurs coupaient les vieux algos, cela entrainait aussi des compatibilités.
Mais je vois mal utiliser la méthode choisie par Wireguard pour le web, mais laisser la responsabilité aux administrateurs systèmes n'est pas toujours la bonne solution (j'en suis un). Mais pour le cas d'usage de Wireguard, qui est dans un réseau maîtrisé, ça me semble être une très bonne approche. En tant qu'admin je sais que je dois tenir à jour les versions du logiciel mais pas en plus à connaître les arcanes de la configuration des algos de crypto pour avoir une installation sécurisée.