Welke OpenVPN-pakketten beschermt de auth-digest?
De optie auth dekt minder dan een profiel suggereert. Loop het kanaal, het AEAD-geval en de bescherming van het besturingskanaal na voordat u een digestbeleid vaststelt.
De meeste discussies over OpenVPN-digests beginnen bij het verkeerde pakket. auth SHA256 lezen als ‘accepteer alleen peers die SHA256 bieden’ is het eerste dat u moet afleren. De optie benoemt een digest voor bepaalde pakketten, en welke pakketten dat zijn hangt af van het kanaal en van of dat kanaal AEAD is. Werk de vier vragen hieronder in volgorde door; elk ervan vernauwt wat de instelling in uw uitrol kan betekenen.
Benoem het kanaal dat de instelling moet beschermen
OpenVPN heeft een besturingskanaal dat TLS-handshakeverkeer draagt en een datakanaal dat de tunnelpayload draagt. De auth-digest speelt in beide een rol, maar niet dezelfde, en het profiel maakt het verschil zelden zichtbaar. Schrijf op welke van de twee u probeert te beperken voordat u een configuratiebestand aanraakt.
De tabel hieronder is de korte versie van hoe dezelfde optie in elke context terechtkomt.
| 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 |
Controleer of het datakanaal AEAD is voordat u erop vertrouwt
Als de onderhandelde datacijfer AES-GCM of CHACHA20-POLY1305 is, authenticeert het datakanaal zichzelf en doet de aparte digest niet het werk dat u zich misschien voorstelt. Beide zijn AEAD-constructies, dus integriteit ontstaat door dezelfde bewerking die de payload versleutelt. Dat is geen verslechtering, maar het betekent wel dat een beleid dat als ‘elk datapakket is HMAC-SHA256’ wordt gerechtvaardigd op die tunnel feitelijk onjuist is. Bevestig de onderhandelde waarde in het serverlog of de statusuitvoer van de client voordat u het beleid herschrijft.
Onderzoek de cijfer die daadwerkelijk is onderhandeld in plaats van de lijst in het profiel, want de onderhandeling kan op een ander lid van de set uitkomen. data-ciphers AES-256-GCM:AES-128-GCM is een onderhandelingslijst, en beide vermeldingen zijn AEAD, dus geen van beide verbruikt de auth-digest voor payloadbescherming.
Behandel de bescherming van het besturingskanaal als een eigen beslissing
tls-auth voegt een HMAC toe aan pakketten van het besturingskanaal en neemt zijn digest uit de auth-instelling, waardoor een AEAD-tunnel nog steeds een betekenisvolle digest kan hebben. tls-crypt is een andere ordening met eigen vaste bescherming, dus ga er niet van uit dat die elke tls-auth-eigenschap erft. Lees de documentatie voor het mechanisme dat u koos in plaats van aannames ertussen over te dragen.
De twee peers moeten het ook eens zijn over de ordening en over de sleutelrichting. Een digest die klopt maar een sleutelbestand dat in de verkeerde richting wordt gebruikt, levert een handshake op die mislukt om redenen die de digestinstelling niet kan verklaren.
Houd auth gescheiden van cijferonderhandeling en certificaten
Drie instellingen worden voortdurend verward: de auth-digest, de lijst met datacijfers en het handtekeningalgoritme van het certificaat. De eerste wijzigen geeft geen certificaat opnieuw uit, selecteert niet zijn handtekeningdigest en maakt geen gebruikersnaam-wachtwoordmethode. De protocoloptiedefinities in de OpenVPN 2.6-bronnen beschrijven elk in een eigen sectie, wat een nuttige herinnering is dat het onafhankelijke knoppen zijn.
Wanneer een peer na een digestwijziging weigert te verbinden, is de oorzaak meestal een mismatch in een van de andere twee instellingen. Lees beide kanten voordat u een van beide wijzigt.
Schrijf het beleid op en vergelijk het met draaiende configuraties
Een uitspraak op vlootniveau moet de toegestane datakanaalmodi en de gekozen bescherming van het besturingskanaal uitdrukkelijk in dezelfde zin noemen. Die zin is toetsbaar; ‘wij gebruiken SHA256’ niet. Vergelijk hem daarna met effectieve server- en clientprofielen in plaats van met een sjabloon in een repository.
Sluit af met vast te leggen wat elke tunnel werkelijk heeft onderhandeld en welk mechanisme de pakketten heeft geauthenticeerd. Een zichtbare auth-regel in een profiel is alleen bewijs van configuratie-intentie, en intentie is het goedkoopste deel van de controle.