Kiujn OpenVPN-paketojn protektas la haŝo auth?
La opcio auth kovras malpli ol profilo sugestas. Trairu la kanalon, la AEAD-kazon kaj la protekton de la regkanalo antaŭ ol vi starigos haŝan politikon.
Plej multaj debatoj pri OpenVPN-haŝoj komenciĝas ĉe la malĝusta paketo. Legi auth SHA256 kiel «akcepti nur kunulojn, kiuj proponas SHA256» estas la unua afero mallernenda. La opcio nomas haŝon por difinitaj paketoj, kaj kiuj paketoj estas tiaj dependas de la kanalo kaj de tio, ĉu tiu kanalo estas AEAD. Trairu la kvar demandojn sube laŭorde; ĉiu mallarĝigas, kion la agordo povas signifi en via deplojo.
Nomu la kanalon, kiun la agordo celas protekti
OpenVPN havas regkanalon, kiu portas TLS-manpreman trafikon, kaj datkanalon, kiu portas la tunelan utilŝarĝon. La haŝo auth ludas rolon en ambaŭ, sed ne la saman, kaj la profilo malofte videbligas la diferencon. Skribu, kiun el la du vi provas limigi, antaŭ ol tuŝi agordan dosieron.
La suba tabelo estas la mallonga versio de tio, kiel la sama opcio lokiĝas en ĉiu kunteksto.
| 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 |
Kontrolu, ĉu la datkanalo estas AEAD, antaŭ ol vi fidos ĝin
Se la intertraktita datĉifro estas AES-GCM aŭ CHACHA20-POLY1305, la datkanalo mem aŭtentikigas sin kaj la aparta haŝo ne faras la laboron, kiun vi eble imagas. Ambaŭ estas AEAD-konstruaĵoj, do integreco produktiĝas per la sama operacio, kiu ĉifras la utilŝarĝon. Tio ne estas malaltigo, sed ĝi signifas, ke politiko pravigita kiel «ĉiu datpaketo estas HMAC-SHA256» estas fakte malĝusta sur tiu tunelo. Konfirmu la intertraktitan valoron en la servila protokolo aŭ la klienta statussignalo antaŭ ol reskribi la politikon.
Ekzamenu la ĉifron, kiun oni fakte intertraktis, anstataŭ la liston en la profilo, ĉar intertraktado povas surteriĝi sur alian membron de la aro. data-ciphers AES-256-GCM:AES-128-GCM estas intertraktada listo, kaj ambaŭ eroj estas AEAD, do neniu el ili konsumas la haŝon auth por utilŝarĝa protekto.
Traktu la protekton de la regkanalo kiel propran decidon
tls-auth aldonas HMAC al la paketoj de la regkanalo kaj prenas sian haŝon el la agordo auth, tial AEAD-tunelo ankoraŭ povas havi senchavan haŝon agorditan. tls-crypt estas alia aranĝo kun propra fiksa protekto, do ne supozu, ke ĝi heredas ĉiun econ de tls-auth. Legu la dokumentaron por la mekanismo, kiun vi elektis, anstataŭ transigi supozojn inter ili.
La du kunuloj ankaŭ devas interkonsenti pri la aranĝo kaj pri la ŝlosila direkto. Haŝo, kiu kongruas, sed ŝlosildosiero uzata en la malĝusta direkto, produktas manpremon, kiu malsukcesas pro kialoj, kiujn la haŝa agordo ne povas klarigi.
Tenu auth aparte de ĉifra intertraktado kaj atestiloj
Tri agordoj konstante konfuziĝas: la haŝo auth, la listo de datĉifroj kaj la subskriba algoritmo de la atestilo. Ŝanĝi la unuan ne reeldonas atestilon, ne elektas ĝian subskriban haŝon kaj ne kreas metodon uzantnomo-pasvorto. La protokolopciaj difinoj en la fontoj de OpenVPN 2.6 priskribas ĉiun en propra sekcio, kio estas utila memorigo, ke ili estas sendependaj butonoj.
Kiam kunulo rifuzas konektiĝi post haŝa ŝanĝo, la kaŭzo kutime estas malkongruo en unu el la du aliaj agordoj. Legu ambaŭ finaĵojn antaŭ ol ŝanĝi ajnan el ili.
Skribu la politikon kaj komparu ĝin kun funkciantaj agordoj
Deklaro je flota nivelo devus eksplicite nomi la permesitajn datkanalajn reĝimojn kaj la elektitan regkanalan protekton, en la sama frazo. Tiu frazo estas testebla; «ni uzas SHA256» ne estas. Poste komparu ĝin kun efektivaj servilaj kaj klientaj profiloj anstataŭ kun ŝablono en deponejo.
Finu registrante, kion ĉiu tunelo fakte intertraktis kaj kiu mekanismo aŭtentikigis ĝiajn paketojn. Videbla auth-linio en profilo estas pruvo nur de agorda intenco, kaj intenco estas la plej malmultekosta parto de la kontrolo.