OpenVPN-log: styrekanalens cipher kontra datakanalens cipher

En loglinje, der nævner DHE-RSA-AES256-SHA, er ikke et resume af hele forbindelsen. Den hører til TLS-handshaket, som beskytter styrekanalen, og trafikken inde i tunnelen kan være krypteret med noget helt andet. At rapportere den som VPN'ens datacipher er den fejl, man skal undgå.

To resultater betyder noget, og de besvarer forskellige spørgsmål. Det ene er den forhandlede TLS-suite til styrekanalen; det andet er datacipheren til de pakker, tunnelen bærer.

To resultater, to spørgsmål

Styrekanalen bærer handshaket og styremeddelelserne mellem parterne. Dens cipher vælges af TLS-stakken, så navnet følger TLS-konventionerne. Datakanalen bærer brugertrafikken og konfigureres af OpenVPNs egen cipherforhandling.

Afgør, hvilket spørgsmål du besvarer, før du læser nogen af de to linjer. Om tunnelen er krypteret, og om handshaket er stærkt, er ikke det samme spørgsmål.

Et loguddrag, der viser begge linjer, er det brugbare. Læs styrelinjen for TLS-version og -suite, og datalinjen for den algoritme, der faktisk beskytter payloaden.

Afkod TLS-suitenavnet i sin egen kontekst

I et historisk OpenSSL-navn som DHE-RSA-AES256-SHA beskriver hver komponent en anden beslutning. DHE er den efemere Diffie-Hellman-nøgleaftale, RSA er godkendelsesmetoden, AES256 er AES-256 i CBC-tilstand til TLS-poster, og SHA er post-MAC'en baseret på SHA-1.

Den sidste komponent er ikke et certifikatfingeraftryk, og at læse den som et er en almindelig fejl. Navnet angiver heller ikke protokolversionen alene, fordi TLS 1.3 bruger et helt andet navngivningsskema. TLS_AES_256_GCM_SHA384 følger den nyere form, hvor den afsluttende hash er en del af suiteopbygningen og ikke et MAC-valg. Anvend kun komponentlæsningen på den ældre navngivningsstil.

OpenSSL-suitereferencen knytter disse navne til deres definitioner, hvis en komponent er ukendt.

Læs datakanalens resultat for den bårede trafik

For den bårede trafik læses datakanalens linje fra samme session. En data-ciphers-liste i konfigurationen er et tilladt sæt, ikke bevis for, at en bestemt algoritme blev forhandlet. Loggen registrerer valget; konfigurationen angiver menuen.

En AEAD-cipher som AES-GCM har sin egen integritetskontrol, så en separat datakanal-HMAC er ikke en del af den vej.

Direktivet auth opgraderer ikke TLS, certifikater eller datacipheren. Det vælger en digest til de dele af protokollen, der stadig bruger en, og med en AEAD-datacipher er der ingen separat data-HMAC at konfigurere.

Hold identitetskontroller ude af cipherresultatet

Certifikatets signaturalgoritme, validering af tillidskæden og verifikation af partens navn er tre egenskaber mere, som et ciphernavn intet siger om. Et udløbet certifikat fejler, uanset hvor stærk suiten er. Et servernavn, der ikke stemmer, fejler på samme måde. At rette en digestindstilling i profilen reparerer ingen af dem.

Hold disse kontroller i revisionsnoterne ved siden af cipherresultatet, ikke sammenflettet med det.

Registrér de forhandlede resultater fra den aktuelle session

Tag resultaterne fra den aktuelle forbindelse og registrér klient- og serverversionerne sammen med dem. En log, der kun tilføjes, kan indeholde en ældre sessions linje, og at citere den som aktuel er måden, hvorpå et løst problem ser ud til at bestå.

Til en politikgennemgang skal du give konfigurationsejeren den forhandlede TLS-version og -suite, den valgte datacipher og indstillingerne for certifikatvalidering samlet. Ændr det lag og læs derefter en ny log for at bekræfte de nye forhandlede værdier.