Které pakety OpenVPN chrání otisk auth?
Volba auth pokrývá méně, než profil naznačuje. Projděte kanál, případ AEAD a ochranu řídicího kanálu, než nastavíte politiku otisku.
Většina debat o otiscích OpenVPN začíná u špatného paketu. Číst auth SHA256 jako „přijímej jen peery, kteří nabízejí SHA256“ je první věc, kterou je třeba odnaučit. Volba pojmenovává otisk pro určité pakety a které pakety to jsou, závisí na kanálu a na tom, zda je tento kanál AEAD. Projděte čtyři otázky níže v pořadí; každá zužuje, co může nastavení ve vašem nasazení znamenat.
Pojmenujte kanál, který má nastavení chránit
OpenVPN má řídicí kanál, který přenáší provoz TLS handshake, a datový kanál, který přenáší užitečné zatížení tunelu. Otisk auth má roli v obou, ale ne stejnou, a profil rozdíl zřídka zviditelní. Zapište si, který z těch dvou se snažíte omezit, než sáhnete na konfigurační soubor.
Tabulka níže je krátká verze toho, jak stejná volba dopadá v každém kontextu.
| 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 |
Než se na něj spolehnete, ověřte, zda je datový kanál AEAD
Pokud je vyjednaná datová šifra AES-GCM nebo CHACHA20-POLY1305, datový kanál se autentizuje sám a samostatný otisk nedělá práci, kterou si možná představujete. Obě jsou konstrukce AEAD, takže integritu vytváří stejná operace, která šifruje zatížení. To není downgrade, ale znamená to, že politika odůvodněná jako „každý datový paket je HMAC-SHA256“ je na tomto tunelu věcně nesprávná. Potvrďte vyjednanou hodnotu v logu serveru nebo ve výstupu stavu klienta, než politiku přepíšete.
Zkoumejte šifru, která byla skutečně vyjednána, ne seznam v profilu, protože vyjednávání může skončit na jiném členu sady. data-ciphers AES-256-GCM:AES-128-GCM je seznam pro vyjednávání a obě položky jsou AEAD, takže ani jedna nespotřebovává otisk auth na ochranu zatížení.
Berte ochranu řídicího kanálu jako vlastní rozhodnutí
tls-auth přidává HMAC k paketům řídicího kanálu a bere svůj otisk z nastavení auth, proto může mít tunel AEAD stále smysluplně nastavený otisk. tls-crypt je jiné uspořádání s vlastní pevnou ochranou, takže nepředpokládejte, že dědí každou vlastnost tls-auth. Čtěte dokumentaci k mechanismu, který jste zvolili, místo přenášení předpokladů mezi nimi.
Oba peery se také musí shodnout na uspořádání a na směru klíče. Otisk, který sedí, ale soubor klíče použitý ve špatném směru, vede k handshake, který selže z důvodů, jež nastavení otisku nedokáže vysvětlit.
Držte auth oddělené od vyjednávání šifer a certifikátů
Tři nastavení se neustále pletou: otisk auth, seznam datových šifer a podpisový algoritmus certifikátu. Změna prvního certifikát znovu nevydá, nevybere jeho podpisový otisk a nevytvoří metodu uživatel-heslo. Definice protokolových voleb v zdrojích OpenVPN 2.6 popisují každou ve vlastní sekci, což je užitečná připomínka, že jde o nezávislé voliče.
Když peer po změně otisku odmítne připojení, příčinou bývá neshoda v jednom z dalších dvou nastavení. Přečtěte oba konce, než některé z nich změníte.
Zapište politiku a porovnejte ji s běžícími konfiguracemi
Prohlášení na úrovni flotily by mělo výslovně uvést povolené režimy datového kanálu a zvolenou ochranu řídicího kanálu v jedné větě. Ta věta je testovatelná; „používáme SHA256“ ne. Potom ji porovnejte s účinnými profily serveru a klienta, ne se šablonou v repozitáři.
Na závěr zaznamenejte, co každý tunel skutečně vyjednal a který mechanismus autentizoval jeho pakety. Viditelný řádek auth v profilu je pouze dokladem záměru konfigurace a záměr je nejlevnější částí kontroly.