Un peer vechi forțează TLS 1.0: limitează excepția, nu gazda

Apare un dispozitiv vechi, nu se poate conecta, iar reparația care pare cea mai rapidă este să slăbești întreaga gazdă până când conexiunea reușește. Acel schimb este invizibil în moment și permanent în practică, pentru că nimeni nu elimină un prag care în sfârșit funcționează. Presiunea este creată de două defecte foarte diferite, iar doar unul dintre ele ține de cifruri. Sortează mai întâi defectul, apoi pune excepția unde nu se poate răspândi.

Împarte defectul în două înainte de a modifica o directivă

O linie de jurnal a serverului despre lipsa unei cifre comune, sau despre o versiune de protocol neacceptată, vine din canalul de control: cele două capete nu au reușit să cadă de acord cum să protejeze negocierea în sine. O linie a clientului care spune că nicio metodă de verificare a certificatului serverului nu este activată vine dintr-un cu totul alt loc, pentru că acel client nu verifică deloc cine a răspuns. Schimbarea unei cifre de date nu ajută în al doilea caz, iar adăugarea unei verificări de rol nu ajută în primul.

Ia prima linie eșuată de pe fiecare parte, nu ultima dinaintea deconectării, pentru că ultima este de obicei o consecință. Apoi stabilește ce fișier a deschis de fapt clientul: un profil importat există adesea de două ori sub nume afișate diferite, iar editarea copiei pe care nu o citește nimeni produce o absență convingătoare a schimbării. Un proces care rulează păstrează setările cu care a pornit, deci un fișier salvat nu este un fișier încărcat. Comenzile de mai jos arată negocierea clientului lângă vederea serverului asupra aceleiași încercări.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Un al doilea listener este locul onest pentru un prag mai slab

Când dispozitivul se oprește la TLS 1.0 cu un canal de date dinainte de 2.5, serverul trebuie să ofere un prag mai jos pentru canalul de control și o cifră de date pe care clientul vechi o recunoaște. Directiva de fallback există exact pentru acel peer, în timp ce lista de cifruri ține clienții moderni pe suite moderne. Ambele directive aparțin listenerului, nu unui utilizator sau unei conexiuni, iar nicio opțiune per client nu le restrânge ulterior. De aceea un singur dispozitiv vechi pe portul principal este o decizie despre fiecare peer care împarte acel port.

Unde platforma permite, rulează listenerul vechi ca instanță proprie pe un port separat, permite acel port doar din adresa dispozitivului și lasă serviciul principal în pace. Notează de ce există al doilea listener, în fișierul care îi conține configurația, pentru că altfel o curățenie viitoare îl va citi ca rest. Separarea merită doar dacă pragul mai slab se termină acolo unde se termină dispozitivul.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Ce strică de fapt un certificat vechi al furnizorului

Eroarea de verificare este o legătură de rol lipsă: fără ea clientul acceptă orice certificat care se înlănțuie la o CA de încredere, indiferent dacă a fost emis pentru un server. Leagă certificatul de rolul deserver mai întâi și tratează legătura ca pe o cerință, nu ca pe un buton de reglaj. Doar un profil care tot eșuează după acel pas are o problemă reală de certificat.

Un certificat vechi al furnizorului a cărui dimensiune a cheii sau algoritm de semnătură nu mai satisface politica implicită OpenSSL este cazul unei schimbări limitate a nivelului de securitate pe canalul de control. Coborârea nivelului acolo nu oprește verificarea și nu trebuie combinată niciodată cu o CA goală, o verificare dezactivată sau un nume de gazdă neverificat. Ține linia în singurul profil care are nevoie de ea; exportarea globală a unei configurații OpenSSL relaxate ar oferi aceeași relaxare fiecărui program de pe mașină.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Citește valorile negociate, nu bannerul

La verbosity 4 ambele capete afișează versiunea TLS și cifra canalului de control asupra cărora au căzut de acord, și cifra de date a sesiunii. Citește acele linii, nu bannerul de inițializare, care raportează succesul și nu termenii lui. Apoi reconectează un client modern la listenerul principal și confirmă că ajunge tot pe o suită modernă, pentru că o excepție scursă în configurația partajată se vede aici prima. Valorile pe care le copiezi devin baza pentru următoarea revizuire.

Testează dispozitivul vechi singur: ar trebui să se conecteze și ar trebui să fie singura sesiune din jurnale care arată parametrii mai slabi. Dacă un al doilea peer negociază și el suita veche, excepția este mai largă decât s-a intenționat, iar separarea listenerelor nu a avut loc cu adevărat. Notează ambele observații, nu doar concluzia.

Fiecare excepție are nevoie de un proprietar și o dată

O excepție fără condiție de eliminare devine încet implicită, așa că pune dispozitivul, proprietarul, motivul și data la care dispare lângă configurația pe care o justifică. Fără acea linie, pragul mai slab supraviețuiește hardware-ului care avea nevoie de el.

Înlocuirea clientului, sau cererea unui profil actual de la furnizor, este rezultatul spre care trebuie să tindeți; excepția este o amânare, nu un proiect. Când dispozitivul este retras, elimină listenerul și profilul în aceeași modificare, astfel încât niciuna dintre jumătăți să nu mai ruleze. Nimic din toate acestea nu face parametrii vechi siguri, doar împiedică limita unui singur dispozitiv să devină baza tuturor.