Urmărirea pachetelor de control OpenVPN: tls-auth înainte de TLS

O defecțiune tls-auth este de obicei raportată ca problemă de strângere de mână, deși nu a fost niciodată una. HMAC-ul este verificat pe pachetul de control înainte de orice procesare TLS, așa că o cheie sau o direcție nepotrivită produce o defecțiune care arată ca o problemă de certificat și este decisă cu două straturi mai devreme. Tratarea plicului ca obiect propriu scurtează diagnosticul: citiți câmpurile, confirmați că verificarea are loc devreme, apoi comparați cele trei lucruri asupra cărora ambele capete trebuie să cadă de acord.

Citiți plicul în ordinea în care este construit

Un pachet de control transportă un identificator de sesiune, HMAC-ul tls-auth opțional, informații de reluare și confirmare și un identificator de mesaj de încredere, iar după aceea urmează încărcătura tipului de mesaj. Când mesajul este un mesaj de strângere de mână, încărcătura este din întâmplare text cifrat TLS. Aceasta este întreaga relație: materialul TLS călătorește în interiorul unui mesaj pe care plicul îl protejează deja. Consultați referința protocolului de rețea OpenVPN care enumeră câmpurile canalului de control în această ordine.

Stratul de fiabilitate este ușor de confundat cu criptografia. Confirmările, retransmiterea și identificatorul de mesaj există pentru ca mesajele de control să ajungă o singură dată și în ordine pe un transport nesigur. Nu sunt autentificare, iar un identificator de mesaj corect nu dovedește nimic despre cine a trimis pachetul.

Păstrați această grupare ca noțiune. Nu este o diagramă a ordinii octeților și nu este suficientă pentru a calcula o etichetă, deoarece câmpurile care intră în HMAC depind de implementare, versiune și mod.

Arătați că verificarea are loc înainte de strângerea de mână

Un receptor care deține cheia partajată poate verifica HMAC-ul și poate arunca imediat un pachet falsificat, fără a aloca stare de strângere de mână sau a face muncă cu cheie publică. Protecția acoperă și primele pachete ale strângerii de mână, și exact de aceea o cheie greșită apare ca o conexiune eșuată și nu ca o eroare de autentificare târzie.

Creșteți verbositatea demonului și urmăriți canalul de control în locul dispozitivului tun:

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

Ceea ce căutați este o defecțiune de verificare HMAC a canalului de control raportată la nivel de pachet, înainte de orice alertă TLS. O alertă TLS în jurnal înseamnă că plicul a fost acceptat și defecțiunea s-a mutat spre interior, ceea ce este altă anchetă cu altă soluție.

Gestionarea direcției se află și ea aici. Când un fișier de cheie statică este folosit cu tls-auth, cele două capete iau direcții de cheie opuse, iar protocolul folosește această diviziune pentru ca un pachet capturat să nu poată fi reflectat înapoi la expeditor. Inversarea direcției păstrează cheia identică și totuși fiecare pachet eșuează. Schimbați un singur capăt o dată, apoi reporniți ambele demonuri pentru ca perechea să fie încărcată împreună.

Potriviți cheia, direcția și digest la ambele capete

Trei valori trebuie să coincidă și doar una dintre ele este fișierul. Conținutul cheii statice trebuie să fie identic la ambele capete, direcția trebuie să fie opusă, iar digestul folosit pentru HMAC trebuie să corespundă. Verificați configurația înainte de a atinge materialul cheii, deoarece o singură direcție inversată explică mai multe eșecuri decât un fișier corupt:

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

Generați secretul partajat cu instrumentul și nu cu un editor, și păstrați permisiunile strânse:

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

Versiunile mai vechi acceptau o ordine a opțiunilor ușor diferită pentru generarea cheilor, iar profilurile scrise pentru acele versiuni încă circulă. Fișierul generat este același tip de obiect în ambele cazuri, așa că verificarea este dacă ambele capete dețin octeți identici, nu care ortografie i-a produs.

Nu confundați tls-auth cu tls-crypt. Ambele protejează canalul de control, dar tls-crypt îl și criptează și ascunde strângerea de mână de observatori, și înlocuiește diviziunea direcțiilor cu propria gestionare a cheilor. Un profil care folosește unul nu va interopera cu un partener configurat pentru celălalt, și nicio reglare a digestului nu închide acel decalaj.

Reproduceți o etichetă doar din formatul real

Reproducerea exactă la nivel de octet este o sarcină separată de rularea unui VPN și funcționează doar cu intrările reale: implementarea și versiunea care au construit pachetul, digestul ales, direcția și octeții efectivi, inclusiv identificatorul de sesiune și matricea de confirmări. O reprezentare textuală a listei de câmpuri nu sunt acei octeți.

Lungimea etichetei derivă din digest, așa că presupunerea unei lungimi fixe se rupe în momentul în care cineva o schimbă. Hașurați pachetul așa cum face implementarea, nu cum îl prezintă un tabel într-o postare de blog, și comparați cu o captură luată de la același partener, nu cu o așteptare dedusă manual.

Țineți acest exercițiu departe de profilurile de producție. Nimic din reproducerea unei etichete nu vă spune dacă o implementare ar trebui să activeze protecția.

Reveniți asupra unei nepotriviri fără a elimina protecția

Testul tentant este să ștergeți tls-auth, să vedeți conexiunea reușind și să concluzionați că cheia era greșită. Acel răspuns vă costă protecția și nu vă învață nimic despre care dintre cele trei valori nu se potrivea. În schimb, obțineți configurația potrivită aprobată din partea serverului și comparați cu ea.

Pregătiți schimbarea astfel încât să fie reversibilă. Păstrați configurația și fișierul de cheie anterioare ale serverului, aplicați perechea corectată, verificați că un client finalizează strângerea de mână și abia apoi eliminați copia de siguranță. Dacă clienții eșuează după schimbare, restaurați fișierele anterioare în loc să improvizați o a treia variantă în timpul unei întreruperi. Restaurarea ar trebui să fie o singură comandă pe care o știți deja înainte de a începe.

În final, amintiți-vă ce înseamnă o verificare trecută. Demonstrează că partenerul deține cheia partajată, nu că certificatul sau contul său este autorizat, și nu spune nimic despre cifrul negociat al canalului de date. Autorizarea și protecția datelor sunt stabilite mai târziu, așa că o verificare curată a plicului este un punct de plecare, nu o sentință.