Por que AES-256 non describe un conxunto de cifrado VPN

Pregunte que cifrado usa unha VPN e a resposta adoita chegar nunha palabra: AES-256, ou ChaCha20, ou quizais WireGuard. Esa resposta nomea un compoñente dunha capa, mentres que o que realmente protexe a conexión é un conxunto de algoritmos que cobren catro papeis distintos. Confundir o compoñente coa disposición é o erro máis común nestas conversas e produce comparacións que non se poden resolver.

Catro traballos dentro dunha conexión

O cifrado masivo converte o texto claro en texto cifrado para a canle de datos, e a súa chave derívase en lugar de transmitirse. A protección de integridade detecta modificacións, que é un traballo aparte aínda que unha soa construción faga ambas as cousas. O establecemento de chaves produce o material compartido de tráfico, e a autenticación do par decide quen está ao outro lado. Se falta calquera deles, a conexión non é segura, por forte que sexa a peza restante.

Algúns deseños funden dous papeis nun. AES-GCM e ChaCha20-Poly1305 son construcións de cifrado autenticado, así que a confidencialidade e a integridade chegan xuntas; AES-CBC non o é e necesita un código de autenticación de mensaxe aparte coa súa propia chave. Por iso ler unha proposta como un saco de números independentes le mal os que se deseñaron como parellas.

Os papeis tamén se sitúan en capas distintas, e por iso a mesma palabra pode significar cousas diferentes en dous produtos. Un cifrado de bloque dentro de ESP e un cifrado de bloque dentro de TLS son a mesma primitiva en negociacións distintas con requisitos distintos. Por iso citar unha primitiva sen o seu modo e a súa capa pode ser peor que non citar nada.

Por que o nome dun cifrado case non di nada

Tome a frase AES-256 en serio un momento: identifica un cifrado de bloque e un tamaño de chave. Non di nada sobre o modo de operación, sobre se se achega integridade, nin sobre como se estableceron as chaves ou como se autenticou o par. Dous produtos poden anunciar ambos AES-256 e diferir en todo o demais, incluído un que o emparellan cun modo non autenticado e outro que usa un modo AEAD con intercambio de chaves moderno.

TLS 1.3 levou esta separación ao estándar, o que é unha corrección útil para quen aprendeu o vocabulario anterior. As súas suites de cifrado só nomean o AEAD e o hash, mentres que os grupos de intercambio de chaves e os algoritmos de sinatura se negocian como parámetros aparte. Por iso un nome de suite TLS 1.3 non é comparable cun nome de suite TLS 1.2 en igualdade de condicións, aínda que ambos aparezan no mesmo campo dun ficheiro de configuración. Un auditor que compara as dúas cadeas directamente saca unha conclusión que o protocolo non respalda. Lea tamén o grupo negociado e os parámetros de sinatura, ou a comparación queda incompleta.

WireGuard elixe o camiño oposto e elimina a negociación case por completo: o protocolo fixa un conxunto de algoritmos, así que dúas implementacións interoperan ou non. É unha elección de deseño lexítima, e tamén significa que a pregunta de que suite negocia WireGuard non ten unha resposta que mereza comparación. Se o audita, lea a especificación unha vez e despois audite a xestión de chaves ao seu redor en lugar da negociación.

A capa decide o vocabulario

Un despregamento de IPsec negocia dúas veces: unha proposta IKE para a canle de control e unha transformación ESP para os datos, e as dúas poden diferir lexitimamente. Ler a primeira e supor que describe a segunda é unha fonte habitual de confusión durante unha auditoría, porque o ficheiro de configuración menciona ambas e a interesante é a segunda.

Un nome dispoñible nunha biblioteca non se implementa automaticamente para outra ruta de datos. Por iso a afirmación de que o noso produto admite AES-256 é máis feble do que soa, e por iso un problema de interoperabilidade adoita resolverse atopando a intersección mantida en lugar de habilitar todos os algoritmos antigos en ambos os lados.

A especificación de TLS 1.3 é o exemplo publicado máis claro da separación, porque define a suite como unha parella e traslada o resto á súa propia negociación. Unha vez que esa forma resulta familiar, a proposta de IPsec e o único conxunto fixo de WireGuard lese como variantes da mesma idea.

Lea o resultado negociado e logo detéñase

Unha proposta configurada non é proba do que elixiron dous pares. A sesión viva leva a resposta, e calquera implementación habitual pode informala sen capturar paquetes.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

Na saída lea os algoritmos seleccionados en lugar da lista ofrecida. Se a resposta é máis feble do que pretendía a política, a corrección corresponde á configuración da proposta nun ou noutro lado, e unha discrepancia adoita aparecer en implementacións modernas como unha negociación fallida e non como unha rebaixa silenciosa.

Despois lembre que non cobre a suite. Rutas, permisos de aplicacións, rexistro e retención son decisións aparte coa súa propia revisión, e unha disposición criptográfica compatible non di nada sobre elas. A discusión sobre o cifrado merece a pena, pero responde a unha pregunta máis estreita que a que a maioría expón en realidade.

Manteña o vocabulario preciso e o argumento acúrtase. Unha suite é un conxunto de papeis nunha capa, un cifrado é un compoñente, e o resultado negociado é o único que describe a conexión que realmente ten. Todo o demais na comparación é decoración.