OpenVPN tls-ciphersuites pret tls-version-min: ko katrs uzspiež

Trīs dažādi fakti tiek saspiesti vienā rindā lielākajā daļā OpenVPN TLS diskusiju: ko var jūsu klienta būvējums, ko pieļauj profils un par ko sesija faktiski vienojās. Īss TLS 1.3 komplektu saraksts atbild tikai uz pusi uz vidējo jautājumu un neko nepasaka par protokola versijas apakšējo robežu. Izpildiet tālāk minētās pārbaudes secībā un apstājieties pie pirmās, kas neiztur, jo katra nākamā pārbaude pieņem, ka iepriekšējās jau ir sakārtotas.

Pārbaudiet būvējumu pirms jebkura saraksta lasīšanas

Konfigurācijas direktīva nevar pievienot protokola atbalstu binārajai datnei, kurai tā nav. Sāciet ar versijas reklāmjoslu, kas nosauc kompilēto kriptogrāfijas bibliotēku:

openvpn --version

2.6 būvējums, kas saistīts ar OpenSSL, pieņem gan tls-cipher, gan tls-ciphersuites. Būvējums ar mbed TLS vispār nav TLS 1.3 komplektu izvēles, un 2.6 rokasgrāmata atzīmē tls-ciphersuites kā OpenSSL opciju. Ja serveris tiek pārbūvēts ar citu backend, tas pats profils var mainīt uzvedību, nemainot nevienu konfigurācijas rindu.

Kamēr esat šeit, palaidiet openvpn --show-tls un saglabājiet izvadi. Tas ir uzskaitījums, ar ko vēlāk salīdzināsit, un to ir lēti fiksēt, pirms kāds sāk rediģēt profilus.

Ierakstiet reklāmjoslu un sarakstu izmaiņu biļetenā, nevis tērzēšanas logā. Kad divi cilvēki strīdas, vai klients pēc sešām nedēļām varēs piedāvāt komplektu, fiksētā izvade to atrisina vienā rindā.

Turiet versiju robežas atsevišķi no šifru sarakstiem

2.6 rokasgrāmatā tie ir trīs vadības elementi, nevis viens:

• tls-cipher nosaka šifru politiku TLS 1.2 un vecākām versijām, un to nodod OpenSSL šifru sarakstam;
• tls-ciphersuites izvēlas TLS 1.3 komplektus;
• tls-version-min un tls-version-max ierobežo protokola versijas, ko savienojums drīkst izmantot.

Tātad rūpīgi apgriezts TLS 1.3 komplektu saraksts neko nepierāda par to, ka vecāka versija joprojām ir atļauta. Ja prasība ir «tikai TLS 1.3», to nes versijas apakšējā robeža, un komplektu saraksts tikai sašaurina izvēles šīs robežas ietvaros:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Šis pāris veic divus darbus. Dzēšot vienu no rindām, otra uzspiež mazāk, nekā jūs domājat, un tieši tas ir tas bojājums, kura dēļ visa šī pārbaude pastāv.

Datu kanāls ir ceturtais vadības elements. data-ciphers pārrunā simetrisko šifru tuneļa iekšienē, un tā rezultāts neko nepasaka par vadības kanāla TLS versiju. AES-256-GCM redzēšana sesijas kopsavilkumā nav TLS 1.3 pierādījums nevienā virzienā.

Lasiet show-tls kā vietēju uzskaitījumu

--show-tls uzskaita komplektus, ko atbalsta kriptogrāfijas bibliotēka, ar kuru šī binārā datne ir saistīta, prioritātes secībā. Tas nav pārskats no vārtejas. Rokasgrāmata skaidri saka, ka saraksts nāk no vietējās bibliotēkas, kas nozīmē, ka klēpjdators ar OpenSSL 3.x un maršrutētājs ar vecāku būvējumu izdrukās atšķirīgus sarakstus, runājot ar to pašu serveri.

Pieņemsim, ka klients atbalsta komplektus A, B un C un viena sesija izvēlas B. Tas neko nenorāda par to, vai serveris pieļauj A vai C, nedz arī par to, vai B ir tā vienīgā atļautā izvēle. Turiet trīs rindas atsevišķi, un lielākā daļa mulsinošo TLS pavedienu atrisināsies paši.

Uzskaitījumu tomēr ir vērts saglabāt. Kad sesija neizdodas, bibliotēkas saraksta salīdzināšana ar profila sarakstu parāda, vai klientam vispār bija iespēja piedāvāt to, ko serveris gribēja. Tas arī parāda, vai backend izmaiņa klusi nav noņēmusi TLS_CHACHA20_POLY1305_SHA256 no kopas, uz kuru paļaujas vecāki klienti — tāda veida regresija, kas izpaužas kā saujiņa lietotāju, kuri nevar pieslēgties, kamēr visi pārējie neko nepamana.

Jautājiet vārtejai kaut ko tādu, uz ko tā var atbildēt

Ja jūs pārvaldāt pakalpojumu, pārbaudiet darbojošās instances faktisko konfigurāciju, nevis datni diskā. OpenVPN varēja tikt palaists ar citu --config ceļu, var ietvert iekļāvumus un var nebūt restartēts kopš labojuma. Klienti sastopas ar darbojošā dēmona politiku.

Ja jūs to nepārvaldāt, lūdziet operatoram atbalstītās klienta prasības vai ierobežotu pieņemšanas testu. Noraidīts mēģinājums nav automātiski noraidīts komplekts: versijas apakšējā robeža, sertifikāta identitātes pārbaudes, piemēram, remote-cert-tls, vai neatbilstība starp tls-auth un tls-crypt var izbeigt apmaiņu, pirms komplekta izvēlei vispār ir nozīme. Izlasiet servera kļūdu pirms klienta saraksta maiņas, jo «handshake failed» aptver četrus dažādus cēloņus, un tikai viens no tiem ir šifra neatbilstība.

openssl s_client vēršana uz VPN portu arī neatkārto jautājumu. Vadības kanāls darbojas OpenVPN paša ietvarā, tāpēc neapstrādāts TLS zonds pārbauda citu protokolu portā, kas gaida ko citu. Jebkurš no tā izdarītais secinājums attiecas uz zondējumu, nevis tuneli.

Reģistrējiet divus rezultātus un turiet tos atsevišķi

Svaiga atļauta sesija rada vadības kanāla rindu, kurā nosaukta protokola versija un izvēlētais šifrs, un atsevišķu datu kanāla rindu, kurā nosaukts tuneļa šifrs. Fiksējiet abas ar klienta versiju un profila nosaukumu, un pierakstiet, kura servera instance atbildēja:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Pēc tam lasiet abas rindas no šīs datnes, nevis no atmiņas. Pāris ir pierādījums; komplekta nosaukums vien ir izvēle, un versijas robeža ir atsevišķs apgalvojums par to, ko serveris atsaka.

Veiciet pārbaudes šādā secībā. Apstipriniet būvējumu un backend ar --version. Fiksējiet --show-tls pirms kaut ko maināt. Nosauciet nepieciešamo versijas apakšējo robežu atsevišķi no komplektu saraksta. Apstipriniet darbojošās instances faktisko politiku ar tās īpašnieku. Novērojiet vienu atļautu sesiju un, ja plāns atļauj, vienu noraidītu mēģinājumu ar vecāku versiju. Reģistrējiet vadības un datu kanāla rezultātus kā atsevišķus konstatējumus.

Ja nepieciešamais klients nevar izpildīt jaunu minimumu, pieņemiet šo migrācijas vai izņēmuma lēmumu skaidri, tā vietā lai klusi pazeminātu nesaistītu pieņemšanas noteikumu, lai izvēršana izskatītos pabeigta.