Perso je suis contre l'introduction de multiples couches crypto au dessus de la couche TCP (SSL, TLS, et maintenant SSH) ...
Je pense que la crypto à plutôt sa place en couche 3, au niveau IPSec, ça la rends vraiment indépendante de l'appli
Au fait, comment fonctionne IPSec lorsqu'il est en mode non connecté ? L'échange des clés publiques, l'envoi d'une clé de session symétrique, tout ça ça nécessite une mémoire d'état, donc plutôt un protocole connecté.
Peut-être, il y a t'il une sorte de cache, qui négocie une clé privée pour chaque nouvelle IP, la mémorise puis l'utilise pour tout les paquets destinée à cette IP (quel que soit le port) jusqu'à expiration ...
ca évite de mettre en place un VPN IPSEC.
Oui, c'est vrai que pour l'instant IPSec c'est VPN-only, mais sur le long terme (Ipv6) ça devrait être implémenté au niveau hôte.
Et là exit les bidouillages style SSH port forwarding, l'IP spoofing (le noyau authentifie chaque IP via une clé publique, enfin je crois ?) ...
[^] # Re: cool... mais
Posté par Stephane JUTIN . En réponse à la dépêche NFS chiffré avec OpenSSH et Linux. Évalué à 6.
Je pense que la crypto à plutôt sa place en couche 3, au niveau IPSec, ça la rends vraiment indépendante de l'appli
Au fait, comment fonctionne IPSec lorsqu'il est en mode non connecté ? L'échange des clés publiques, l'envoi d'une clé de session symétrique, tout ça ça nécessite une mémoire d'état, donc plutôt un protocole connecté.
Peut-être, il y a t'il une sorte de cache, qui négocie une clé privée pour chaque nouvelle IP, la mémorise puis l'utilise pour tout les paquets destinée à cette IP (quel que soit le port) jusqu'à expiration ...
ca évite de mettre en place un VPN IPSEC.
Oui, c'est vrai que pour l'instant IPSec c'est VPN-only, mais sur le long terme (Ipv6) ça devrait être implémenté au niveau hôte.
Et là exit les bidouillages style SSH port forwarding, l'IP spoofing (le noyau authentifie chaque IP via une clé publique, enfin je crois ?) ...