Kuras OpenVPN paketes aizsargā auth digest?
Opcija auth aptver mazāk, nekā liecina profils. Pārskatiet kanālu, AEAD gadījumu un vadības kanāla aizsardzību pirms digest politikas noteikšanas.
Lielākā daļa diskusiju par OpenVPN digest sākas ar nepareizo paketi. Lasīt auth SHA256 kā “pieņem tikai tos partnerus, kas piedāvā SHA256” ir pirmā lieta, no kā jāatrodas. Opcija nosauc digest konkrētām paketēm, un tas, kuras paketes tās ir, ir atkarīgs no kanāla un no tā, vai šis kanāls ir AEAD. Izskatiet četrus jautājumus zemāk pēc kārtas; katrs sašaurina, ko iestatījums var nozīmēt jūsu izvietojumā.
Nosauciet kanālu, kuru iestatījumam jāaizsargā
OpenVPN ir vadības kanāls, kas pārvadā TLS rokasspiediena datplūsmu, un datu kanāls, kas pārvadā tuneļa lietderīgo slodzi. auth digestam ir loma abos, bet ne tā pati, un profils reti padara atšķirību redzamu. Pierakstiet, kuru no diviem jūs mēģināt ierobežot, pirms pieskaraties konfigurācijas failam.
Zemāk esošā tabula ir īsā versija par to, kā viena un tā pati opcija nonāk katrā kontekstā.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Pirms paļaujaties, pārbaudiet, vai datu kanāls ir AEAD
Ja saskaņotais datu šifrs ir AES-GCM vai CHACHA20-POLY1305, datu kanāls autentificē pats sevi, un atsevišķais digest neveic darbu, ko jūs varbūt iedomājaties. Abi ir AEAD konstrukcijas, tāpēc integritāti rada tā pati darbība, kas šifrē slodzi. Tas nav līmeņa pazeminājums, bet nozīmē, ka politika, kas pamatota kā “katra datu pakete ir HMAC-SHA256”, šajā tunelī faktiski ir nepareiza. Pirms politikas pārrakstīšanas apstipriniet saskaņoto vērtību servera žurnālā vai klienta statusa izvadē.
Pārbaudiet šifru, kas faktiski tika saskaņots, nevis sarakstu profilā, jo sarunas var nonākt pie cita kopas elementa. data-ciphers AES-256-GCM:AES-128-GCM ir sarunu saraksts, un abi ieraksti ir AEAD, tāpēc neviens no tiem netērē auth digestu slodzes aizsardzībai.
Uztveriet vadības kanāla aizsardzību kā atsevišķu lēmumu
tls-auth pievieno HMAC vadības kanāla paketēm un ņem savu digestu no auth iestatījuma, tāpēc AEAD tunelī joprojām var būt jēgpilns digest konfigurēts. tls-crypt ir cita kārtība ar savu fiksēto aizsardzību, tāpēc nepieņemiet, ka tā manto katru tls-auth īpašību. Lasiet izvēlētā mehānisma dokumentāciju, nevis pārnest pieņēmumus starp tiem.
Abiem partneriem jāvienojas arī par kārtību un par atslēgas virzienu. Saskanojošs digest, bet nepareizā virzienā izmantots atslēgas fails rada rokasspiedienu, kas neizdodas tādu iemeslu dēļ, kurus digest iestatījums nevar izskaidrot.
Turiet auth atsevišķi no šifru sarunām un sertifikātiem
Trīs iestatījumi tiek pastāvīgi sajaukti: auth digest, datu šifru saraksts un sertifikāta paraksta algoritms. Pirmā maiņa neizsniedz sertifikātu no jauna, neizvēlas tā paraksta digestu un neveido lietotājvārda-paroles metodi. Protokola opciju definīcijas OpenVPN 2.6 avotos apraksta katru savā sadaļā, kas ir noderīgs atgādinājums, ka tie ir neatkarīgi regulatori.
Kad partneris pēc digest maiņas atsakās savienoties, iemesls parasti ir neatbilstība vienā no pārējiem diviem iestatījumiem. Izlasiet abus galus pirms jebkura maiņas.
Pierakstiet politiku un salīdziniet to ar darbojošām konfigurācijām
Flotes līmeņa paziņojumam tajā pašā teikumā skaidri jānosauc atļautie datu kanāla režīmi un izvēlētā vadības kanāla aizsardzība. Šis teikums ir pārbaudāms; “mēs izmantojam SHA256” nav. Pēc tam salīdziniet to ar faktiskajiem servera un klienta profiliem, nevis ar veidni repozitorijā.
Pabeidziet, pierakstot, par ko katrs tunelis faktiski vienojās un kurš mehānisms autentificēja tā paketes. Redzama auth rinda profilā ir tikai konfigurācijas nodoma pierādījums, un nodoms ir lētākā pārbaudes daļa.