OpenVPN-logg: chifferet for kontrollkanalen mot chifferet for datakanalen

Ei logglinje som nemner DHE-RSA-AES256-SHA er ikkje eit samandrag av heile tilkopinga. Ho høyrer til TLS-handtrykket som vernar kontrollkanalen, og trafikken inne i tunnelen kan vere kryptert med noko heilt anna. Å rapportere henne som datachifferet til VPN-en er feilen du må unngå.

To resultat tel, og dei svarar på ulike spørsmål. Det eine er den forhandla TLS-suiten for kontrollkanalen; det andre er datachifferet for pakkane tunnelen ber.

To resultat, to spørsmål

Kontrollkanalen ber handtrykket og administrasjonsmeldingane mellom partane. Chifferet vert valt av TLS-stakken, så namnet følgjer TLS-konvensjonane. Datakanalen ber brukartrafikken og vert konfigurert av OpenVPN sin eigen chifferforhandling.

Avgjer kva spørsmål du svarar på før du les nokon av linjene. Om tunnelen er kryptert og om handtrykket er sterkt, er ikkje det same spørsmålet.

Eit loggutdrag som viser begge linjene, er det nyttige. Les kontrollinja for TLS-versjon og -suite, og datalinja for algoritmen som faktisk vernar nyttelasta.

Dekod TLS-suitenamnet i sin eigen samanheng

I eit historisk OpenSSL-namn som DHE-RSA-AES256-SHA skildrar kvar komponent ei anna avgjerd. DHE er den efemære Diffie-Hellman-nøkkelavtalen, RSA er autentiseringsmetoden, AES256 er AES-256 i CBC-modus for TLS-postar, og SHA er post-MAC-en basert på SHA-1.

Den siste komponenten er ikkje eit sertifikatfingeravtrykk, og å lese han som eitt er ein vanleg feil. Namnet oppgir heller ikkje protokollversjonen åleine, fordi TLS 1.3 brukar eit heilt anna namngjevingsskjema. TLS_AES_256_GCM_SHA384 følgjer den nyare forma, der den avsluttande hashen er ein del av suiteoppbygginga og ikkje eit MAC-val. Bruk komponentlesinga berre på den eldre namngjevingsstilen.

OpenSSL-suitereferansen knyter desse namna til definisjonane sine om ein komponent er ukjend.

Les datakanalresultatet for den bårne trafikken

For den bårne trafikken les du datakanallinja frå same økt. Ei data-ciphers-liste i konfigurasjonen er eit tillate sett, ikkje bevis for at ein bestemt algoritme vart forhandla. Loggen registrerer valet; konfigurasjonen fører opp menyen.

Eit AEAD-chiffer som AES-GCM har sin eigen integritetskontroll, så ein separat datakanal-HMAC er ikkje ein del av den vegen.

Direktivet auth oppgraderer ikkje TLS, sertifikat eller datachifferet. Det vel ein digest for delane av protokollen som framleis brukar ein, og med eit AEAD-datachiffer finst det ingen separat data-HMAC å konfigurere.

Hald identitetskontrollar utanfor chifferresultatet

Signaturalgoritmen til sertifikatet, validering av tillitskjeda og verifisering av namnet til parten er tre eigenskapar til som eit chiffernamn ikkje seier noko om. Eit utgått sertifikat feilar, same kor sterk suiten er. Eit servernamn som ikkje stemmer, feilar på same måten. Å rette ei digestinnstilling i profilen reparerer ingen av dei.

Hald desse kontrollane i gjennomgangsnotata ved sida av chifferresultatet, ikkje samanslått med det.

Registrer dei forhandla resultata frå gjeldande økt

Ta resultata frå gjeldande tilkoping og registrer klient- og serverversjonane saman med dei. Ein logg som berre vert lagt til, kan innehalde linja frå ei eldre økt, og å sitere henne som gjeldande er korleis eit løyst problem ser ut til å vare ved.

For ein policygjennomgang gir du konfigurasjonseigaren den forhandla TLS-versjonen og -suiten, datachifferet som vart valt og innstillingane for sertifikatvalidering samla. Endre det laget og les deretter ein ny logg for å stadfeste dei nye forhandla verdiane.