tls-auth i tls-crypt: què protegeix cadascun a OpenVPN

Totes dues opcions fan servir un fitxer de clau compartit i totes dues fan més difícil falsificar el trànsit de l’establiment de connexió, per això es tracten com dos noms de la mateixa funció. No ho són. Una signa els paquets de control, l’altra també els xifra, i cap de les dues té res a veure amb el xifratge que protegeix la vostra càrrega útil.

Aquesta distinció importa quan un perfil no es pot connectar, quan una revisió de seguretat pregunta què protegeix la clau i quan algú assumeix que el fitxer addicional fa que el túnel estigui xifrat d’alguna manera indefinida.

Què protegeix realment la clau compartida

La clau que fan servir aquestes opcions pertany al canal de control: l’intercanvi que negocia paràmetres, demostra identitats i deriva les claus de dades. És un secret precompartit que tots dos extrems han de tenir abans que l’establiment pugui continuar. Com que se situa abans de les comprovacions d’identitat, una clau incorrecta atura la conversa abans que ho faria una contrasenya incorrecta. Aquest ordre explica per què el mode de fallada és tan silenciós.

tls-auth fa servir aquest secret per calcular un HMAC sobre els paquets de control. Un paquet sense una signatura vàlida es descarta abans d’arribar al processament TLS, més costós, i per això l’opció sovint es descriu com un primer filtre i no com un substitut de TLS.

tls-crypt va més enllà, ja que xifra el trànsit de control protegit a més d’autenticar-lo. El contingut dels certificats, els noms de xifratge negociats i altres detalls de l’establiment ja no són visibles a la xarxa, i un observador sense la clau ni tan sols pot veure quina versió de TLS s’intenta. Per a un desplegament que tem revelar la seva empremta VPN, aquesta propietat és el motiu principal per triar-la. Continua sent un secret de grup, no una credencial per usuari.

Cap dels dos mecanismes no emet identitats. La clau compartida és un secret de grup, i tothom qui la té pot satisfer aquesta capa de la comprovació.

On difereixen les dues opcions

La diferència observable és què veu un observador. Amb tls-auth, l’establiment és visible però no verificable sense la clau. Amb tls-crypt, l’establiment és opac per a qui no té la clau.

La configuració també difereix. tls-auth s’usa amb un valor de direcció, de manera que un costat fa servir una meitat del material de clau i l’altre costat l’altra meitat. tls-crypt fa servir una sola clau en totes dues direccions, així que la directiva de direcció no forma part del seu esquema.

Les dues opcions són mútuament excloents en les versions modernes. Un perfil ha de dur una d’elles, no totes dues, i el servidor i el client han d’acordar quina, amb material de clau idèntic. Mantenir una directiva antiga al costat d’una de nova és un residu habitual de migració. Traieu la inactiva perquè el següent lector sàpiga quina capa és realment vigent.

Una variant més nova, tls-crypt-v2, lliga cada client a la seva pròpia clau embolcallada, de manera que revocar un client no obliga a reemetre la clau de grup. Val la pena conèixer-la, però és una opció diferent i no un sinònim de cap de les dues d’aquí.

Per què una discrepància sembla que no passa res

Quan el material compartit no coincideix, l’altre extrem descarta els paquets sense dir al remitent per què. No hi ha cap error d’autenticació per llegir, perquè el paquet mai no va arribar a la capa que el produiria.

El client torna a intentar-ho, el servidor no diu res i el símptoma sembla un problema de xarxa. Llavors la gent reinicia el servei, torna a escriure la contrasenya del compte o treu la directiva de protecció per «provar-la», cosa que canvia el desplegament en lloc de diagnosticar-lo.

Llegiu al registre del servidor la primera queixa a nivell de paquet, no l’última línia de reintent. Confirmeu que tots dos costats porten la mateixa opció amb material de clau idèntic i que el fitxer de clau no s’ha tornat a generar només en un costat.

Treure la directiva no és una reparació segura. Desactiva una capa de protecció per a cada client, i un túnel que després funcioni només demostra que aquella capa era la discrepància.

Què encara s’ha de configurar per separat

Aquestes opcions no verifiquen qui és l’altre extrem. La validació de certificats, l’àncora de confiança i el nom de servidor esperat continuen sent requisits separats, i cap d’ells no esdevé opcional pel fet que hi hagi una clau compartida.

Tampoc no trien el xifratge de dades. Això és una negociació separada que controlen els paràmetres del canal de dades als dos extrems, i un túnel protegit amb tls-crypt encara pot usar un xifratge que no volíeu.

Finalment, la mateixa clau compartida necessita atenció. Tracteu-la com un secret, distribuïu-la per un canal aprovat i substituïu-la quan marxi algú que la tingués. Com que és compartida, la seva exposició és l’exposició de cada extrem que la fa servir.