Per què AES-256 no descriu un conjunt de xifratge VPN

Pregunteu quin xifratge fa servir una VPN i la resposta sol arribar en una paraula: AES-256, o ChaCha20, o potser WireGuard. Aquesta resposta anomena un component d’una capa, mentre que allò que realment protegeix la connexió és un conjunt d’algorismes que omplen quatre papers diferents. Confondre el component amb l’ordenació és l’error més comú en aquestes converses i produeix comparacions que no es poden resoldre.

Quatre feines dins d’una connexió

El xifratge massiu converteix el text pla en text xifrat per al canal de dades, i la seva clau es deriva en lloc de transmetre’s. La protecció d’integritat detecta modificacions, una feina separada encara que una sola construcció faci les dues coses. L’establiment de claus produeix el material compartit de trànsit, i l’autenticació del parell decideix qui hi ha a l’altre extrem. Si en falta una, la connexió no és segura, per fort que sigui la peça que queda.

Alguns dissenys ajunten dos papers en un. AES-GCM i ChaCha20-Poly1305 són construccions de xifratge autenticat, així que la confidencialitat i la integritat arriben juntes; AES-CBC no ho és i necessita un codi d’autenticació de missatge separat amb la seva pròpia clau. Per tant, llegir una proposta com un sac de nombres independents llegeix malament els que es van dissenyar com a parelles.

Els papers també seuen en capes diferents, i per això la mateixa paraula pot significar coses diferents en dos productes. Un xifratge de bloc dins d’ESP i un xifratge de bloc dins de TLS són la mateixa primitiva en negociacions diferents amb requisits diferents. Per això citar una primitiva sense el seu mode i la seva capa pot ser pitjor que no citar res.

Per què un nom de xifratge gairebé no diu res

Preneu la frase AES-256 de debò un moment: identifica un xifratge de bloc i una mida de clau. No diu res sobre el mode d’operació, si es proporciona integritat, com es van establir les claus o com es va autenticar el parell. Dos productes poden anunciar tots dos AES-256 i diferir en tota la resta, inclòs un que l’emparella amb un mode no autenticat i un altre que fa servir un mode AEAD amb intercanvi de claus modern.

TLS 1.3 va portar aquesta separació a l’estàndard, cosa que és una correcció útil per a qui va aprendre el vocabulari més antic. Les seves suites de xifratge només anomenen l’AEAD i el hash, mentre que els grups d’intercanvi de claus i els algorismes de signatura es negocien com a paràmetres separats. Per tant, un nom de suite TLS 1.3 no és comparable amb un nom de suite TLS 1.2 en igualtat de condicions, tot i que tots dos apareixen al mateix camp d’un fitxer de configuració. Un auditor que compara les dues cadenes directament treu una conclusió que el protocol no sosté. Llegiu també el grup negociat i els paràmetres de signatura, o la comparació queda incompleta.

WireGuard tria el camí oposat i elimina la negociació gairebé del tot: el protocol especifica un conjunt fix d’algorismes, així que dues implementacions o interoperen o no. És una elecció de disseny legítima, i també vol dir que la pregunta quina suite negocia WireGuard no té una resposta que valgui la pena comparar. Si l’auditeu, llegiu l’especificació un cop i després auditeu la gestió de claus al seu voltant en lloc de la negociació.

La capa decideix el vocabulari

Un desplegament IPsec negocia dues vegades: una proposta IKE per al canal de control i una transformació ESP per a les dades, i les dues poden diferir legítimament. Llegir la primera i suposar que descriu la segona és una font habitual de confusió durant una auditoria, perquè el fitxer de configuració esmenta totes dues i la interessant és la segona.

Un nom disponible en una biblioteca no s’implementa automàticament per a un altre camí de dades. Per això l’afirmació que el nostre producte admet AES-256 és més feble del que sembla, i per això un problema d’interoperabilitat se sol resoldre trobant la intersecció mantinguda en lloc d’activar tots els algorismes antics als dos costats.

L’especificació de TLS 1.3 és l’exemple publicat més clar de la separació, perquè defineix la suite com una parella i mou la resta a la seva pròpia negociació. Un cop aquesta forma és familiar, la proposta IPsec i l’únic conjunt fix de WireGuard es llegeixen com a variants de la mateixa idea.

Llegiu el resultat negociat i atureu-vos

Una proposta configurada no és prova del que han triat dos parells. La sessió viva porta la resposta, i qualsevol implementació habitual la pot reportar sense capturar paquets.

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

A la sortida llegiu els algorismes triats en lloc de la llista oferta. Si la resposta és més feble del que pretenia la política, la correcció pertany a la configuració de la proposta en un costat o l’altre, i una discrepància es mostra habitualment en implementacions modernes com una negociació fallida i no com una rebaixa silenciosa.

Després recordeu què no cobreix la suite. Rutes, permisos d’aplicacions, registre i retenció són decisions separades amb la seva pròpia revisió, i una ordenació criptogràfica compatible no diu res sobre cap d’elles. La discussió sobre el xifratge val la pena, però respon una pregunta més estreta que la que la majoria de la gent fa realment.

Manteniu el vocabulari precís i l’argument s’escurça. Una suite és un conjunt de papers en una capa, un xifratge és un component, i el resultat negociat és l’única cosa que descriu la connexió que teniu de debò. La resta de la comparació és decoració.