AES-256 mot OFB: velg en komplett VPN-chifferkonstruksjon

AES-256 og OFB svarer på ulike spørsmål, og det er her chiffergjennomganger går galt når de behandles som konkurrerende alternativer. Den ene navngir et blokkchiffer med en nøkkelstørrelse; den andre beskriver hvordan et blokkchiffer gjøres om til en strøm for en lengre melding. En runbook for valg av beskyttelse må se på hele konstruksjonen, inkludert hvordan mottakeren oppdager en endret pakke.

Navngi de fire delene av konstruksjonen

Hver gjennomgang reduseres til fire spørsmål: hvilken primitiv og nøkkelstørrelse, hvordan meldinger behandles med den, hvordan mottakeren avviser uautorisert endring, og hvordan protokollen håndterer inndata, nøkler og levetiden deres. En liste med kjente navn svarer bare på det første. Det andre og tredje er der de reelle forskjellene ligger, og det fjerde er der implementasjoner stille går fra hverandre. Still dem i den rekkefølgen og skriv ned svarene.

OFB står blant konfidensialitetsmodusene i NIST-publikasjonen om blokkchiffermoduser, og konfidensialitet er alt det gir. En protokoll som parer en krypteringsmodus med en separat MAC, må sette dem sammen riktig, og et algoritmenavn beviser ikke den sammensetningen. Derfor kan modusnavnet alene ikke avgjøre en utrullingsbeslutning.

Det fjerde spørsmålet er det en operatør faktisk kan verifisere på det kjørende systemet.

Foretrekk en autentisert konstruksjon

Autentisert kryptering gir konfidensialitet og integritet sammen, og AEAD-konstruksjoner beskytter også tilknyttede data mot endring uten å kryptere dem. Det er en egenskap ved pakkebeskyttelse, og det har ingenting å gjøre med om et menneske har logget inn.

Netgates veiledning for OpenVPN-kryptoinnstillinger peker på AEAD-alternativer, blant dem AES-GCM, for datakanalen, og det er den typen støttet policy man bør følge. Bruk valgene den installerte versjonen og peer-klientene støtter, i stedet for å kopiere en historisk modusrangering inn i en ny utrulling. Eldre kompatibilitet, kryptobackends og offload-støtte begrenser hva som faktisk er tilgjengelig.

En støttet konstruksjon slår en smart sammensetning hver gang.

Les det forhandlede resultatet, ikke tilbudet

Et chiffer på en akseptert liste sier ingenting om den gjeldende sesjonen. Les den forhandlede datakanalbeskyttelsen hos klienten eller på gatewayen, og sammenlign den med policyen du ville håndheve. En konfigurasjon som fortsatt lister et eldre alternativ for en gammel peer, er en kompatibilitetsbeslutning, ikke en uttalelse om sesjonen foran deg.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

På en gateway er den tilsvarende utdataen sikkerhetstilknytningen eller kryptodetaljene for tilkoblingen, avhengig av plattformen. I begge tilfeller er tilbudet og resultatet forskjellige fakta. En liste med et eldre alternativ for en gammel peer betyr ikke at hver sesjon bruker det, og sesjonen som gjør det, er det du trengte å vite.

Noter begge fakta sammen, med dato og klientversjon.

Mål bare det du kan sammenligne

Gjennomstrømning avhenger av maskinvaren på endepunktene, implementasjonen, akselerasjon, pakkestørrelser og den valgte konfigurasjonen. Verken nøkkellengden eller ordet OFB forteller deg hvilken utrulling som blir raskest. Derfor er en benchmark fra et annet nettsted i beste fall et hint om maskinvare noen andre eier. Dine egne tall starter ved dine egne endepunkter.

For en autorisert sammenligning holder du endepunktene, arbeidsmengden og den påkrevde policyen konstante, og noterer den forhandlede beskyttelsen samt implementasjonsversjonene. Deretter vurderer du resultatet etter om applikasjonen ble ferdig, hvor mye den mistet og hva endepunktene gjorde, i stedet for å utlede kryptokostnad fra én hastighetstest. Et tall produsert under andre forhold er en historie, ikke en måling.

Hvis en gammel peer ikke kan oppfylle policyen, er det en kompatibilitetsbeslutning for eieren.

Hold integritet utenfor handelen

Å slå av integritetskontroller eller godta en uverifisert server er ikke en ytelsesoptimalisering, og det er ikke en kompatibilitetsretting. Det endrer sikkerhetsegenskapen konstruksjonen ble valgt for. Det samme gjelder å utvide den aksepterte chifferlisten til en gammel peer kobler til: tilkoblingen lykkes, og policyen finnes ikke lenger.

Skriv den aksepterte konstruksjonen og eieren i runbooken, slik at neste endring starter med en beslutning og ikke en preferanse.

Det du vil ha, er en policy begge ender kan håndheve. Å argumentere for at ett navn er sterkest, er en annen samtale, og den ender vanligvis uten beslutning.