OpenVPN-logg: styrkanalens chiffer kontra datakanalens chiffer

En loggrada som namnger DHE-RSA-AES256-SHA är ingen sammanfattning av hela anslutningen. Den hör till TLS-handskakningen som skyddar styrkanalen, och trafiken inuti tunneln kan vara krypterad med något helt annat. Att rapportera den som VPN:ens datachiffer är misstaget att undvika.

Två resultat spelar roll, och de svarar på olika frågor. Det ena är den förhandlade TLS-sviten för styrkanalen; det andra är datachiffret för de paket som tunneln bär.

Två resultat, två frågor

Styrkanalen bär handskakningen och hanteringsmeddelandena mellan parterna. Dess chiffer väljs av TLS-stacken, så namnet följer TLS-konventionerna. Datakanalen bär användartrafiken och konfigureras av OpenVPN:s egen chifferförhandling.

Avgör vilken fråga du besvarar innan du läser någon av raderna. Om tunneln är krypterad och om handskakningen är stark är inte samma fråga.

Ett loggutdrag som visar båda raderna är det användbara. Läs styrraden för TLS-version och -svit, och dataraden för den algoritm som faktiskt skyddar nyttolasten.

Avkoda TLS-svitens namn i dess egen kontext

I ett historiskt OpenSSL-namn som DHE-RSA-AES256-SHA beskriver varje komponent ett annat beslut. DHE är den efemära Diffie-Hellman-nyckelöverenskommelsen, RSA är autentiseringsmetoden, AES256 är AES-256 i CBC-läge för TLS-poster, och SHA är post-MAC:en baserad på SHA-1.

Den sista komponenten är inte ett certifikatfingeravtryck, och att läsa den som ett är ett vanligt fel. Namnet anger inte heller protokollversionen i sig, eftersom TLS 1.3 använder ett helt annat namngivningsschema. TLS_AES_256_GCM_SHA384 följer den nyare formen, där den avslutande hashen är en del av svitens uppbyggnad och inte ett MAC-val. Tillämpa komponentläsningen bara på den äldre namngivningsstilen.

OpenSSL-svitreferensen kopplar dessa namn till deras definitioner om en komponent är obekant.

Läs datakanalens resultat för den burna trafiken

För den burna trafiken läser du datakanalens rad från samma session. En data-ciphers-lista i konfigurationen är en tillåten uppsättning, inte ett bevis på att en viss algoritm förhandlades. Loggen registrerar valet; konfigurationen förtecknar menyn.

Ett AEAD-chiffer som AES-GCM har sin egen integritetskontroll, så en separat datakanal-HMAC ingår inte i den vägen.

Direktivet auth uppgraderar inte TLS, certifikat eller datachiffret. Det väljer en digest för de delar av protokollet som fortfarande använder en, och med ett AEAD-datachiffer finns ingen separat data-HMAC att konfigurera.

Håll identitetskontroller utanför chifferresultatet

Certifikatets signaturalgoritm, validering av tillitskedjan och verifiering av partens namn är tre egenskaper till som ett chiffernamn inte säger något om. Ett utgånget certifikat misslyckas, hur stark sviten än är. Ett servernamn som inte stämmer misslyckas på samma sätt. Att rätta en digestinställning i profilen reparerar ingendera.

Behåll dessa kontroller i granskningsanteckningarna bredvid chifferresultatet, inte sammanslagna med det.

Registrera de förhandlade resultaten från den aktuella sessionen

Ta resultaten från den aktuella anslutningen och registrera klient- och serverversionerna tillsammans med dem. En logg som bara läggs till kan innehålla en äldre sessions rad, och att citera den som aktuell är hur ett åtgärdat problem ser ut att kvarstå.

För en policygranskning ska du ge konfigurationsägaren den förhandlade TLS-versionen och -sviten, det valda datachiffret och inställningarna för certifikatvalidering tillsammans. Ändra det lagret och läs sedan en ny logg för att bekräfta de nya förhandlade värdena.