tls-auth fronte a tls-crypt: que protexe cada un en OpenVPN

Ambas opcións usan un ficheiro de clave compartida e ambas dificultan a falsificación do tráfico do saúdo, por iso se tratan como dous nomes da mesma función. Non o son. Unha asina os paquetes de control, a outra tamén os cifra, e ningunha ten relación co cifrado que protexe os teus datos.

Esa distinción importa cando un perfil non consegue conectarse, cando unha revisión de seguridade pregunta que protexe a clave e cando alguén supón que o ficheiro adicional fai que o túnel estea cifrado dalgunha forma indefinida.

Que protexe realmente a clave compartida

A clave que usan estas opcións pertence á canle de control: o intercambio que negocia parámetros, demostra identidades e deriva as claves de datos. É un segredo precompartido que ambos extremos deben ter antes de que o saúdo poida continuar. Como se sitúa antes das comprobacións de identidade, unha clave incorrecta detén a conversación antes do que o faría un contrasinal incorrecto. Esa orde explica por que o modo de fallo é tan silencioso.

tls-auth usa ese segredo para calcular un HMAC sobre os paquetes de control. Un paquete sen unha sinatura válida descártase antes de chegar ao procesamento TLS, máis custoso, e por iso a opción se describe a miúdo como un primeiro filtro e non como un substituto de TLS.

tls-crypt vai máis alá ao cifrar o tráfico de control protexido ademais de autenticalo. O contido dos certificados, os nomes de cifrado negociados e outros detalles do saúdo xa non son visibles na rede, e un observador sen a clave nin sequera pode ver que versión de TLS se está a tentar. Para unha implantación preocupada por revelar a súa pegada VPN, esa propiedade é o motivo principal para elixilo. Segue a ser un segredo de grupo, non unha credencial por usuario.

Ningún dos mecanismos emite identidades. A clave compartida é un segredo de grupo, e calquera que a teña pode satisfacer esa capa da comprobación.

Onde difiren as dúas opcións

A diferenza observable é o que ve un observador. Con tls-auth o saúdo é visible pero non verificable sen a clave. Con tls-crypt o saúdo é opaco para quen non teña a clave.

A configuración tamén difire. tls-auth úsase cun valor de dirección, así que un lado usa unha metade do material de clave e o outro lado usa a outra metade. tls-crypt usa unha soa clave en ambas direccións, polo que a directiva de dirección non forma parte do seu esquema.

As dúas opcións son mutuamente excluíntes nas versións modernas. Un perfil debe levar unha delas, non ambas, e o servidor e o cliente deben acordar cal, con material de clave idéntico. Manter unha directiva antiga xunto a unha nova é un residuo habitual de migración. Elimina a inactiva para que o seguinte lector saiba que capa está realmente vixente.

Unha variante máis recente, tls-crypt-v2, vincula cada cliente coa súa propia clave envolta, de modo que revogar un cliente non esixe reemitir a clave de grupo. Paga a pena coñecela, pero é unha opción distinta e non un sinónimo de ningunha das dúas de aquí.

Por que un desaxuste parece que non pasa nada

Cando o material compartido non coincide, o outro extremo descarta os paquetes sen dicir ao remitente por que. Non hai ningún erro de autenticación que ler, porque o paquete nunca chegou á capa que o produciría.

O cliente reintenta, o servidor non di nada e o síntoma parece un problema de rede. Entón a xente reinicia o servizo, volve escribir o contrasinal da conta ou retira a directiva de protección para «probala», o que cambia a implantación en lugar de diagnosticala.

Le no rexistro do servidor a primeira queixa a nivel de paquete en lugar da última liña de reintento. Confirma que ambos lados levan a mesma opción con material de clave idéntico e que o ficheiro de clave non se rexerou só nun lado.

Retirar a directiva non é unha reparación segura. Desactiva unha capa de protección para cada cliente, e un túnel que funcione despois só demostra que esa capa era o desaxuste.

Que aínda hai que configurar por separado

Estas opcións non verifican quen é o outro extremo. A validación de certificados, a áncora de confianza e o nome de servidor esperado seguen sendo requisitos separados, e ningún se volve opcional porque haxa unha clave compartida.

Tampouco elixen o cifrado de datos. Iso é unha negociación separada controlada polos axustes da canle de datos en ambos extremos, e un túnel protexido con tls-crypt pode seguir usando un cifrado que non pretendías.

Por último, a propia clave compartida necesita manexo. Trátaa como un segredo, distribúea por unha canle aprobada e substitúea cando se vaia calquera que a tivese. Como é compartida, a súa exposición é a exposición de cada extremo que a usa.