Rastrexar paquetes de control de OpenVPN: tls-auth antes de TLS

Un fallo de tls-auth adoita notificarse como un problema de handshake, e nunca o foi. O HMAC compróbase no paquete de control antes de que ocorra calquera procesamento TLS, así que unha clave ou unha dirección desaxustada produce un fallo que parece un problema de certificado e decídese dúas capas antes. Tratar a envoltura como un obxecto propio acurta o diagnóstico: lea os campos, confirme que a comprobación se dispara cedo e despois compare as tres cousas que ambos extremos deben acordar.

Lea a envoltura na orde en que se constrúe

Un paquete de control leva un identificador de sesión, o HMAC opcional de tls-auth, información de repetición e acuse de recibo, e un identificador de mensaxe fiable, e despois vén a carga do tipo de mensaxe. Cando a mensaxe é unha mensaxe de handshake, a carga resulta ser texto cifrado TLS. Esa é toda a relación: o material TLS viaxa dentro dunha mensaxe que a envoltura xa protexe. A referencia do protocolo de rede de OpenVPN enumera os campos da canle de control nesa orde.

A capa de fiabilidade confúndese facilmente con criptografía. Os acuses de recibo, a retransmisión e o identificador de mensaxe existen para que as mensaxes de control cheguen unha vez e en orde por un transporte non fiable. Non son autenticación, e un identificador de mensaxe correcto non demostra nada sobre quen enviou o paquete.

Manteña esta agrupación como concepto. Non é un diagrama de orde de bytes e non abonda para calcular unha etiqueta, porque os campos que entran no HMAC dependen da implementación, a versión e o modo.

Demostre que a comprobación se dispara antes do handshake

Un receptor que ten a clave compartida pode verificar o HMAC e descartar un paquete falsificado de inmediato, sen asignar estado de handshake nin facer traballo de clave pública. A protección cobre tamén os paquetes iniciais do handshake, e por iso mesmo unha clave incorrecta aparece como unha conexión fallida e non como un erro de autenticación tardío.

Suba a verbosidade do daemon e observe a canle de control en lugar do dispositivo tun:

openvpn --config /etc/openvpn/server.conf --verb 6

O que busca é un fallo de verificación HMAC da canle de control notificado a nivel de paquete, antes de calquera alerta TLS. Unha alerta TLS no rexistro significa que a envoltura se aceptou e o fallo se desprazou cara a dentro, o que é outra investigación con outra solución.

O manexo da dirección tamén está aquí. Cando se usa un ficheiro de clave estática con tls-auth, os dous extremos toman direccións de clave opostas, e o protocolo usa esa división para que un paquete capturado non se poida reflectir de volta ao seu emisor. Inverter a dirección mantén a clave idéntica e aínda así fai fallar cada paquete. Cambie un extremo cada vez e despois reinicie ambos daemons para que a parella se cargue xunta.

Axuste clave, dirección e digest en ambos extremos

Tres valores deben coincidir e só un deles é o ficheiro. O contido da clave estática debe ser idéntico en ambos extremos, a dirección debe ser oposta e o digest usado para o HMAC debe coincidir. Comprobe a configuración antes de tocar o material de clave, porque unha soa dirección invertida explica máis fallos que un ficheiro danado:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Xere o segredo compartido coa ferramenta e non cun editor, e manteña os permisos estritos:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

As versións antigas aceptaban unha orde de opcións lixeiramente distinta para xerar claves, e os perfís escritos para esas versións aínda circulan. O ficheiro xerado é o mesmo tipo de obxecto en ambos casos, así que a comprobación é se ambos extremos teñen bytes idénticos, non que ortografía os produciu.

Non confunda tls-auth con tls-crypt. Ambos protexen a canle de control, pero tls-crypt tamén a cifra e oculta o handshake aos observadores, e substitúe a división de direccións polo seu propio manexo de claves. Un perfil que usa un non interoperará cun par configurado para o outro, e ningún axuste de digest pecha esa fenda.

Reproduza unha etiqueta só a partir do formato real

A reprodución exacta a nivel de byte é unha tarefa distinta de executar unha VPN, e só funciona coas entradas reais: a implementación e a versión que construíron o paquete, o digest seleccionado, a dirección e os bytes reais, incluídos o identificador de sesión e a matriz de acuse de recibo. Unha representación textual da lista de campos non son eses bytes.

A lonxitude da etiqueta derívase do digest, así que unha suposición de lonxitude fixa rompe no momento en que alguén a cambia. Calcule o hash do paquete como o fai a implementación, non como o presenta unha táboa nunha entrada de blog, e compare cunha captura tomada do mesmo par en lugar de cunha expectativa deducida a man.

Manteña ese exercicio lonxe dos perfís de produción. Nada de reproducir unha etiqueta lle di se un despregamento debería activar a protección.

Reverta un desaxuste sen retirar a protección

A proba tentadora é borrar tls-auth, ver que a conexión funciona e concluír que a clave era incorrecta. Esa resposta cóstalle a protección e non ensina nada sobre cal dos tres valores discrepaba. No seu lugar, obteña a configuración coincidente aprobada do lado do servidor e compare con ela.

Prepare o cambio para que sexa reversible. Conserve a configuración e o ficheiro de clave anteriores do servidor, aplique a parella corrixida, verifique que un cliente completa o handshake e só entón elimine a copia de seguridade. Se os clientes fallan despois do cambio, restaure os ficheiros anteriores en lugar de improvisar unha terceira variante durante unha caída. A restauración debería ser unha orde que xa coñeza antes de comezar.

Por último, lembre que significa unha comprobación superada. Demostra que o par ten a clave compartida, non que o seu certificado ou conta estea autorizado, e non di nada sobre o cifrado negociado da canle de datos. A autorización e a protección de datos establécense máis tarde, así que unha comprobación limpa da envoltura é un punto de partida e non un veredicto.