Rastrejar paquets de control d’OpenVPN: tls-auth abans de TLS

Un error de tls-auth normalment es presenta com un problema d’apretada de mans, i mai no ho ha estat. L’HMAC es comprova al paquet de control abans que passi cap processament TLS, així que una clau o una direcció desajustada produeix un error que sembla un problema de certificat i es decideix dues capes abans. Tractar l’embolcall com un objecte propi fa curta la diagnosi: llegeix els camps, confirma que la comprovació s’activa aviat i després compara les tres coses en què els dos extrems s’han de posar d’acord.

Llegeix l’embolcall en l’ordre en què es construeix

Un paquet de control porta un identificador de sessió, l’HMAC opcional de tls-auth, informació de reenviament i reconeixement, i un identificador de missatge fiable, i després ve la càrrega del tipus de missatge. Quan el missatge és un missatge d’apretada de mans, la càrrega resulta ser text xifrat TLS. Aquesta és tota la relació: el material TLS viatja dins d’un missatge que l’embolcall ja protegeix. La referència del protocol de xarxa d’OpenVPN llista els camps del canal de control en aquest ordre.

La capa de fiabilitat es confon fàcilment amb criptografia. Els reconeixements, la retransmissió i l’identificador de missatge existeixen perquè els missatges de control arribin una vegada i en ordre per un transport no fiable. No són autenticació, i un identificador de missatge correcte no demostra res sobre qui va enviar el paquet.

Mantingues aquesta agrupació com a concepte. No és un diagrama d’ordre de bytes i no n’hi ha prou per calcular una etiqueta, perquè els camps que entren a l’HMAC depenen de la implementació, la versió i el mode.

Demostra que la comprovació s’activa abans de l’apretada de mans

Un receptor que té la clau compartida pot verificar l’HMAC i descartar un paquet falsificat immediatament, sense assignar estat d’apretada de mans ni fer feina de clau pública. La protecció cobreix també els paquets inicials de l’apretada de mans, i per això mateix una clau incorrecta apareix com una connexió fallida i no com un error d’autenticació tardà.

Augmenta la verbositat del dimoni i observa el canal de control en lloc del dispositiu tun:

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

El que busques és un error de verificació HMAC del canal de control informat a nivell de paquet, abans de qualsevol alerta TLS. Una alerta TLS al registre vol dir que l’embolcall es va acceptar i que l’error s’ha mogut cap endins, cosa que és una altra investigació amb una altra solució.

La gestió de la direcció també és aquí. Quan s’usa un fitxer de clau estàtica amb tls-auth, els dos extrems prenen direccions de clau oposades, i el protocol usa aquesta divisió perquè un paquet capturat no es pugui reflectir de tornada al seu emissor. Invertir la direcció manté la clau idèntica i tot i així fa fallar cada paquet. Canvia un extrem alhora i després reinicia els dos dimonis perquè la parella es carregui juntament.

Fes coincidir clau, direcció i digest als dos extrems

Tres valors han de coincidir i només un d’ells és el fitxer. El contingut de la clau estàtica ha de ser idèntic als dos extrems, la direcció ha de ser oposada i el digest usat per a l’HMAC ha de coincidir. Comprova la configuració abans de tocar el material de clau, perquè una sola direcció invertida explica més errors que un fitxer malmès:

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

Genera el secret compartit amb l’eina i no amb un editor, i mantén els permisos estrets:

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

Les versions antigues acceptaven un ordre d’opcions lleugerament diferent per generar claus, i els perfils escrits per a aquelles versions encara circulen. El fitxer generat és el mateix tipus d’objecte en tots dos casos, així que la comprovació és si els dos extrems tenen bytes idèntics, no quina escriptura els va produir.

No confonguis tls-auth amb tls-crypt. Tots dos protegeixen el canal de control, però tls-crypt també el xifra i amaga l’apretada de mans dels observadors, i substitueix la divisió de direccions per la seva pròpia gestió de claus. Un perfil que en fa servir un no interoperarà amb un company configurat per a l’altre, i cap ajust de digest no tanca aquesta escletxa.

Reprodueix una etiqueta només a partir del format real

La reproducció exacta a nivell de byte és una tasca separada de fer funcionar una VPN, i només funciona amb les entrades reals: la implementació i la versió que van construir el paquet, el digest seleccionat, la direcció i els bytes reals, incloent-hi l’identificador de sessió i la matriu de reconeixement. Una representació textual de la llista de camps no són aquests bytes.

La longitud de l’etiqueta es deriva del digest, així que un supòsit de longitud fixa es trenca en el moment que algú la canvia. Calcula el hash del paquet com ho fa la implementació, no com ho presenta una taula en una entrada de blog, i compara amb una captura presa del mateix company i no amb una expectativa que hagis deduït a mà.

Mantén aquest exercici lluny dels perfils de producció. Res de reproduir una etiqueta no et diu si un desplegament hauria d’activar la protecció.

Desfés un desajustament sense treure la protecció

La prova temptadora és esborrar tls-auth, veure que la connexió funciona i concloure que la clau era incorrecta. Aquesta resposta et costa la protecció i no ensenya res sobre quin dels tres valors discrepava. En lloc d’això, obtén la configuració coincident aprovada del costat del servidor i compara-la amb la teva.

Prepara el canvi perquè sigui reversible. Conserva la configuració i el fitxer de clau anteriors del servidor, aplica la parella corregida, verifica que un client completa l’apretada de mans i només llavors elimina la còpia de seguretat. Si els clients fallen després del canvi, restaura els fitxers anteriors en lloc d’improvisar una tercera variant durant una caiguda. La restauració hauria de ser una ordre que ja coneguis abans de començar.

Finalment, recorda què significa una comprovació superada. Demostra que el company té la clau compartida, no que el seu certificat o compte estigui autoritzat, i no diu res sobre el xifratge negociat del canal de dades. L’autorització i la protecció de dades s’estableixen més tard, així que una comprovació neta de l’embolcall és un punt de partida i no un veredicte.