Aling mga packet ng OpenVPN ang pinoprotektahan ng digest ng auth?
Ang opsyong auth ay sumasaklaw nang mas kaunti kaysa ipinahihiwatig ng profile. Suriin ang channel, ang kaso ng AEAD at ang proteksyon ng control channel bago magtakda ng patakaran sa digest.
Karamihan ng pagtatalo tungkol sa mga digest ng OpenVPN ay nagsisimula sa maling packet. Ang basahin ang auth SHA256 bilang “tanggapin lamang ang mga peer na nag-aalok ng SHA256” ang unang bagay na dapat kalimutan. Pinapangalanan ng opsyong ito ang isang digest para sa mga partikular na packet, at kung aling mga packet iyon ay depende sa channel at sa kung ang channel na iyon ay AEAD. Suriin ang apat na tanong sa ibaba sa pagkakasunod-sunod; bawat isa ay nagpapaliit sa maaaring ibig sabihin ng setting sa iyong deployment.
Pangalanan ang channel na dapat protektahan ng setting
OpenVPN ay may control channel na nagdadala ng trapiko ng pakikipagkamay ng TLS at data channel na nagdadala ng payload ng tunnel. May papel ang digest ng auth sa pareho, ngunit hindi pareho, at bihirang gawin ng profile na makita ang pagkakaiba. Isulat kung alin sa dalawa ang sinusubukan mong limitahan bago hawakan ang file ng configuration.
Ang talahanayan sa ibaba ay ang maikling bersyon kung paano napupunta ang parehong opsyon sa bawat konteksto.
| 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 |
Tingnan kung ang data channel ay AEAD bago umasa rito
Kung ang napagkasunduang data cipher ay AES-GCM o CHACHA20-POLY1305, ang data channel ay nagpapatunay sa sarili nito at ang hiwalay na digest ay hindi gumagawa ng trabahong maaaring iniisip mo. Pareho silang konstruksyon ng AEAD, kaya ang integridad ay nagmumula sa parehong operasyong nag-e-encrypt ng payload. Hindi ito pagbaba ng antas, ngunit nangangahulugan itong ang patakarang pinangangatwiranan bilang “bawat data packet ay HMAC-SHA256” ay talagang mali sa tunnel na iyon. Kumpirmahin ang napagkasunduang halaga sa log ng server o output ng status ng client bago muling isulat ang patakaran.
Suriin ang cipher na talagang napagkasunduan sa halip na ang listahan sa profile, dahil ang negosasyon ay maaaring mapunta sa ibang miyembro ng set. data-ciphers AES-256-GCM:AES-128-GCM ay listahan ng negosasyon, at parehong AEAD ang dalawang entry, kaya wala sa kanila ang gumagamit ng digest ng auth para sa proteksyon ng payload.
Ituring ang proteksyon ng control channel bilang hiwalay na desisyon
Ang tls-auth ay nagdadagdag ng HMAC sa mga packet ng control channel at kinukuha ang digest nito mula sa setting ng auth, kaya ang isang AEAD tunnel ay maaari pa ring magkaroon ng makabuluhang digest na naka-configure. Ang tls-crypt ay ibang kaayusan na may sariling nakapirming proteksyon, kaya huwag ipagpalagay na namamana nito ang bawat katangian ng tls-auth. Basahin ang dokumentasyon para sa mekanismong pinili mo sa halip na ilipat ang mga palagay sa pagitan nila.
Dapat ding magkasundo ang dalawang peer sa kaayusan at sa direksyon ng key. Ang digest na tugma ngunit ang file ng key na ginamit sa maling direksyon ay gumagawa ng pakikipagkamay na nabigo dahil sa mga dahilang hindi maipaliwanag ng setting ng digest.
Panatilihing hiwalay ang auth sa negosasyon ng cipher at sa mga sertipiko
Tatlong setting ang laging pinaghahalo: ang digest ng auth, ang listahan ng data cipher at ang algorithm ng lagda ng sertipiko. Ang pagbabago sa una ay hindi naglalabas muli ng sertipiko, hindi pumipili ng digest ng lagda nito at hindi gumagawa ng paraang user-password. Ang mga depinisyon ng opsyon ng protocol sa mga source ng OpenVPN 2.6 ay inilalarawan ang bawat isa sa sariling seksyon, na isang kapaki-pakinabang na paalala na sila ay magkakahiwalay na knob.
Kapag tumanggi ang peer na kumonekta pagkatapos ng pagbabago ng digest, ang dahilan ay karaniwang hindi pagkakatugma sa isa sa iba pang dalawang setting. Basahin ang parehong dulo bago baguhin ang alinman.
Isulat ang patakaran at ihambing ito sa mga tumatakbong configuration
Ang pahayag sa antas ng fleet ay dapat na tahasang banggitin ang mga pinapayagang mode ng data channel at ang napiling proteksyon ng control channel, sa parehong pangungusap. Nabe-verify ang pangungusap na iyon; ang “gumagamit kami ng SHA256” ay hindi. Pagkatapos ay ihambing ito sa mga epektibong profile ng server at client sa halip na sa isang template sa isang repository.
Tapusin sa pamamagitan ng pagtatala kung ano ang aktwal na napagkasunduan ng bawat tunnel at aling mekanismo ang nagpatunay sa mga packet nito. Ang nakikitang linya ng auth sa isang profile ay patunay lamang ng intensyon ng configuration, at ang intensyon ang pinakamurang bahagi ng pagsusuri.