Vai RSA sertifikāts var darboties ar dh none OpenVPN?

Lūk, servera konfigurācija, kas blakus sertifikātam ar RSA norāda dh none, turklāt nomācošas aizdomas, ka vienam no tiem jābūt nepareizam. Nekas nav nepareizi. Sertifikāts paraksta un autentificē; atslēgu apmaiņa izveido kopīgu noslēpumu. Tie ir divi dažādi darbi vienā rokasspiedienā, un TLS ļauj RSA sertifikātam autentificēt rokasspiedienu, kas izmanto īslaicīgu elipses līknes vienošanos.

Apjukums parasti nāk kopā ar migrācijas rokasgrāmatu. Tā saka aizstāt DH parametru failu ar dh none, lasītājs pamana, ka sertifikāts nav elipses līknes sertifikāts, un abi fakti tiek uztverti kā pretruna.

Kāpēc abi iestatījumi šķiet saistīti

Vecākā OpenVPN konfigurācija prasīja DH parametru failu, jo galīgā lauka Diffie-Hellman nepieciešami domēna parametri, par kuriem abas puses vienojas. dh direktīva norādīja uz šo failu. Kad izvietojums pāriet uz ECDH, parametri nāk no nosauktas līknes, un fails vairs nav vajadzīgs, ko izsaka dh none.

Sertifikāti ir atsevišķa ass. Tie nes publisko atslēgu un parakstu, kas pierāda servera identitāti, un šī atslēga var būt RSA vai elipses līkne neatkarīgi no tā, kā tiek vienots sesijas atslēga. Rokasspiediens, kas izmanto ECDHE atslēgu vienošanai un RSA autentifikācijai, ir parasts un plaši izvietots.

Nosaukšana pastiprina pārklāšanos. Elipses līkne parādās gan ECDHE, gan ECDSA komplektu nosaukumos, tāpēc ir viegli pieņemt, ka jebkuram savienojumam, kas piemin līkni, jāietver līknes sertifikāts. Tā nav.

Kā pareizi lasīt TLS 1.2 komplekta nosaukumu

Ņemiet ECDHE-RSA-AES256-GCM-SHA384. Pirmais marķieris ir atslēgu apmaiņas saime: īslaicīgs elipses līknes Diffie-Hellman. Otrais ir autentifikācijas saime: RSA. Pārējais apraksta ierakstu aizsardzību un rokasspiedienā izmantoto jaucējfunkciju.

ECDHE-ECDSA komplekts izmanto to pašu atslēgu apmaiņas saimi ar citu autentifikācijas metodi, tāpēc tam nepieciešams elipses līknes sertifikāts. DHE-RSA komplekts izmanto galīgā lauka īslaicīgu Diffie-Hellman ar RSA autentifikāciju, un tam tiešām nepieciešami DH parametri.

Lasiet komplekta nosaukumu no kreisās uz labo un piešķiriet katru daļu tās darbam. Kad marķieri ir atdalīti, jautājums mainās no «vai mans sertifikāts atbilst dh none» uz «vai mans serveris atļauj komplektu, kura atslēgu apmaiņai nav vajadzīgs DH fails».

Ko dh none patiesībā izslēdz

dh none liek serverim neielādēt galīgā lauka DH parametru failu. Tas neizslēdz autentifikāciju, sertifikātu validāciju vai pašu TLS. Tomēr tas prasa, lai saskaņotā atslēgu apmaiņa būtu tāda, kurai nav vajadzīgi šie parametri, kas praksē nozīmē ECDHE komplektu vai TLS 1.3 rokasspiedienu.

Tieši no šīs prasības rodas sabrukums. Ja servera TLS šifru politika ir ierobežota ar DHE komplektiem vai klients piedāvā tikai tos, parametru faila noņemšana neatstāj nevienu lietojamu atslēgu apmaiņas metodi un rokasspiediens neizdodas. Kļūda parasti parādās vadības kanāla rokasspiediena laikā, pirms jebkādas lietotāja autentifikācijas. Izlasiet šifru sarakstu, pirms vainojat trūkstošo failu.

Elipses līknes pusē līkni izvēlas servera TLS konfigurācija, un OpenVPN vecākos zaros piedāvā iespēju to izvēlēties. TLS 1.3 apstrādā grupas sarunas protokola iekšienē un vispār neaplūko DH failu.

dh none pats par sevi nav drošības pazeminājums. Apmaiņas stiprums tad ir atkarīgs no līknes un komplekta, par kuriem faktiski vienojas, tāpēc nākamais solis ir skatīties, ko izvēlējās puses, nevis trūkstošo failu.

Apstiprināt sarunas pirms rediģēšanas

Palieliniet servera un klienta detalizāciju un izlasiet vadības kanāla rindu, ko OpenVPN izdrukā pēc savienojuma. Tā nosauc TLS versiju un saskaņoto šifru un ziņo par partnera sertifikāta atslēgas tipu. Šī vienīgā rinda atbild uz jautājumu, ko konfigurācijas fails tikai netieši norāda.

Ja tā rāda TLS 1.2 ar ECDHE-RSA komplektu un RSA sertifikātu, kombinācija ir tieši tā, ko gaida dh none, un nekas nav jālabo. Ja tā rāda DHE komplektu vai rokasspiediena neveiksmi bez kopīga šifra, labojums ir šifru politikā vai klienta iespējās, nevis sertifikātā.

Pārbaudiet vecāko klientu, kuru plānojat atbalstīt, jo pašreizējais klients var vienoties par TLS 1.3, kamēr vecāks ir ierobežots ar TLS 1.2 komplektiem. Ja vecākajam klientam nav pārklāšanās, vai nu paplašiniet atļautos komplektus, vai jauniniet šo galapunktu.

Neizslēdziet sertifikātu pārbaudi, lai apietu rokasspiediena neveiksmi. Neveiksme jums saka, ka puses nevarēja vienoties par atslēgu apmaiņu, un pārbaudes izslēgšana noņem identitātes garantiju, neatrisinot vienošanos.

Kontrolsaraksts: vai sertifikāts ir RSA, vai ECDHE komplekts ir atļauts, vai žurnālā redzams šis komplekts un vai vecākais atbalstītais klients arī to vienojas? Ja visas četras atbildes ir jā, dh none dara savu darbu.