OpenVPN-protokolo: ĉifrado de la rega kanalo kontraŭ ĉifrado de la datuma kanalo

Protokola linio, kiu nomas DHE-RSA-AES256-SHA, ne estas resumo de la tuta konekto. Ĝi apartenas al la TLS-manpremo, kiu protektas la regkanalon, kaj la trafiko ene de la tunelo povas esti ĉifrita tute alie. Prezenti ĝin kiel la datuman ĉifradon de la VPN estas la eraro evitebla.

Gravas du rezultoj, kaj ili respondas al malsamaj demandoj. Unu estas la intertraktita TLS-suito por la regkanalo; la alia estas la datuma ĉifrado por la pakaĵoj, kiujn la tunelo portas.

Du rezultoj, du demandoj

La regkanalo portas la manpremon kaj la administrajn mesaĝojn inter la partioj. Ĝian ĉifradon elektas la TLS-stako, do la nomo sekvas la TLS-konvenciojn. La datuma kanalo portas uzulan trafikon kaj estas agordata de la propra ĉifrada intertraktado de OpenVPN.

Decidu, al kiu demando vi respondas, antaŭ ol legi iun ajn el la du linioj. Ĉu la tunelo estas ĉifrita kaj ĉu la manpremo estas forta ne estas la sama demando.

Protokola eltiraĵo, kiu montras ambaŭ liniojn, estas la utila. Legu la regan linion por la TLS-versio kaj -suito, kaj la datuman linion por la algoritmo, kiu vere protektas la utilan ŝarĝon.

Malĉifru la TLS-suitan nomon en sia propra kunteksto

En historia OpenSSL-stila nomo kiel DHE-RSA-AES256-SHA, ĉiu komponanto priskribas alian decidon. DHE estas la efemera Diffie-Hellman-ŝlosilinterkonsento, RSA estas la aŭtentiga metodo, AES256 estas AES-256 en CBC-reĝimo por TLS-rikordoj, kaj SHA estas la rikorda MAC bazita sur SHA-1.

La lasta komponanto ne estas fingrospuro de atestilo, kaj legi ĝin kiel tian estas ofta eraro. La nomo ankaŭ ne indikas la protokolan version memstare, ĉar TLS 1.3 uzas tute alian nomigan skemon. TLS_AES_256_GCM_SHA384 sekvas tiun pli novan formon, kie la fina haketo estas parto de la konstruo de la suito, ne elekto de MAC. Apliku la komponentan legadon nur al la pli malnova nomiga stilo.

OpenSSL-suita referenco ligas ĉi tiujn nomojn al iliaj difinoj, se iu komponanto estas nekonata.

Legu la rezulton de la datuma kanalo por la portata trafiko

Por la portata trafiko, legu la linion de la datuma kanalo el la sama sesio. data-ciphers-listo en la agordo estas permesita aro, ne pruvo, ke certa algoritmo estis intertraktita. La protokolo registras la elekton; la agordo listigas la menuon.

AEAD-ĉifrado kiel AES-GCM portas sian propran integrecan kontrolon, do aparta datuma kanala HMAC ne estas parto de tiu vojo.

La direktivo auth ne plibonigas TLS, atestilojn aŭ la datuman ĉifradon. Ĝi elektas resumon por tiuj partoj de la protokolo, kiuj ankoraŭ uzas unu, kaj kun AEAD-datuma ĉifrado ne ekzistas aparta datuma HMAC por agordi.

Tenu identecajn kontrolojn ekster la ĉifrada rezulto

La subskriba algoritmo de la atestilo, la validigo de la fidoĉeno kaj la kontrolo de la partnera nomo estas tri pliaj ecoj, pri kiuj ĉifrada nomo diras nenion. Eksvalidiĝinta atestilo malsukcesas, kiom ajn forta estas la suito. Neakorda servila nomo malsukcesas same. Korekti resuman agordon en la profilo ne riparas neniun el la du.

Tenu tiujn kontrolojn en la reviziaj notoj apud la ĉifrada rezulto, ne kunfanditaj kun ĝi.

Registru la intertraktitajn rezultojn de la nuna sesio

Prenu la rezultojn de la nuna konekto kaj registru la klientajn kaj servilajn versiojn kun ili. Protokolo nur aldonema povas enhavi la linion de pli malnova sesio, kaj citi ĝin kiel nunan estas la maniero, kiel riparita problemo ŝajnas daŭri.

Por politika revizio, transdonu al la agorda posedanto la intertraktitajn TLS-version kaj -suiton, la elektitan datuman ĉifradon kaj la atestilvalidigajn agordojn kune. Ŝanĝu tiun tavolon kaj poste legu novan protokolon por konfirmi la novajn intertraktitajn valorojn.