OpenVPN-logg: kontrollkanalens chiffer mot datakanalens chiffer

En logglinje som nevner DHE-RSA-AES256-SHA er ikke et sammendrag av hele tilkoblingen. Den hører til TLS-håndtrykket som beskytter kontrollkanalen, og trafikken inne i tunnelen kan være kryptert med noe helt annet. Å rapportere den som VPN-ens datachiffer er feilen du må unngå.

To resultater betyr noe, og de svarer på forskjellige spørsmål. Det ene er den forhandlede TLS-suiten for kontrollkanalen; det andre er datachifferet for pakkene tunnelen bærer.

To resultater, to spørsmål

Kontrollkanalen bærer håndtrykket og administrasjonsmeldingene mellom partene. Chifferet velges av TLS-stakken, så navnet følger TLS-konvensjonene. Datakanalen bærer brukertrafikken og konfigureres av OpenVPNs egen chifferforhandling.

Avgjør hvilket spørsmål du besvarer før du leser noen av linjene. Om tunnelen er kryptert og om håndtrykket er sterkt, er ikke det samme spørsmålet.

Et loggutdrag som viser begge linjene, er det nyttige. Les kontrollinjen for TLS-versjon og -suite, og datalinjen for algoritmen som faktisk beskytter nyttelasten.

Dekod TLS-suitenavnet i sin egen sammenheng

I et historisk OpenSSL-navn som DHE-RSA-AES256-SHA beskriver hver komponent en annen beslutning. DHE er den efemære Diffie-Hellman-nøkkelavtalen, RSA er autentiseringsmetoden, AES256 er AES-256 i CBC-modus for TLS-poster, og SHA er post-MAC-en basert på SHA-1.

Den siste komponenten er ikke et sertifikatfingeravtrykk, og å lese den som ett er en vanlig feil. Navnet oppgir heller ikke protokollversjonen alene, fordi TLS 1.3 bruker et helt annet navngivningsskjema. TLS_AES_256_GCM_SHA384 følger den nyere formen, der den avsluttende hashen er en del av suiteoppbyggingen og ikke et MAC-valg. Bruk komponentlesingen bare på den eldre navngivningsstilen.

OpenSSL-suitereferansen kobler disse navnene til definisjonene sine hvis en komponent er ukjent.

Les datakanalresultatet for den bårne trafikken

For den bårne trafikken leser du datakanallinjen fra samme økt. En data-ciphers-liste i konfigurasjonen er et tillatt sett, ikke bevis for at en bestemt algoritme ble forhandlet. Loggen registrerer valget; konfigurasjonen fører opp menyen.

En AEAD-chiffer som AES-GCM har sin egen integritetskontroll, så en separat datakanal-HMAC er ikke en del av den veien.

Direktivet auth oppgraderer ikke TLS, sertifikater eller datachifferet. Det velger en digest for delene av protokollen som fortsatt bruker en, og med et AEAD-datachiffer finnes det ingen separat data-HMAC å konfigurere.

Hold identitetskontroller utenfor chifferresultatet

Sertifikatets signaturalgoritme, validering av tillitskjeden og verifisering av partens navn er tre egenskaper til som et chiffernavn ikke sier noe om. Et utløpt sertifikat feiler, uansett hvor sterk suiten er. Et servernavn som ikke stemmer, feiler på samme måte. Å rette en digestinnstilling i profilen reparerer ingen av dem.

Hold disse kontrollene i gjennomgangsnotatene ved siden av chifferresultatet, ikke slått sammen med det.

Registrer de forhandlede resultatene fra gjeldende økt

Ta resultatene fra gjeldende tilkobling og registrer klient- og serverversjonene sammen med dem. En logg som bare legges til, kan inneholde linjen fra en eldre økt, og å sitere den som gjeldende er hvordan et løst problem ser ut til å vedvare.

For en policygjennomgang gir du konfigurasjonseieren den forhandlede TLS-versjonen og -suiten, datachifferet som ble valgt og innstillingene for sertifikatvalidering samlet. Endre det laget og les deretter en ny logg for å bekrefte de nye forhandlede verdiene.