AES-256 eller OFB: velg en fullstendig VPN-chifferkonstruksjon

AES-256 og OFB besvarer forskjellige spørsmål, og det er her chiffergjennomganger feiler når de behandles som konkurrerende valg. Den ene navngir et blokkchiffer med en nøkkelstørrelse; den andre beskriver hvordan et blokkchiffer blir gjort om til en strøm for en lengre melding. En håndbok for valg av beskyttelse må se på hele konstruksjonen, inkludert hvordan mottakeren oppdager en endret pakke.

Navngi konstruksjonens fire deler

Hver gjennomgang koker ned til fire spørsmål: hvilken primitiv og nøkkelstørrelse, hvordan meldinger behandles med den, hvordan mottakeren avviser uautorisert endring, og hvordan protokollen styrer inndata, nøkler og levetiden deres. En liste med kjente navn besvarer bare det første. Det andre og tredje er der de virkelige forskjellene ligger, og det fjerde er der implementasjoner stille skiller lag. Still dem i den rekkefølgen og skriv ned svarene.

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

Det fjerde spørsmålet er det en operatør faktisk kan kontrollere på systemet som kjører.

Foretrekk en autentisert konstruksjon

Autentisert kryptering gir konfidensialitet og integritet samtidig, og AEAD-konstruksjoner beskytter også tilknyttede data mot endring uten å kryptere dem. Dette er en egenskap ved pakkebeskyttelse, og den har ingenting med om en person har logget inn å gjøre.

Netgates Netgates veiledning for kryptooppsett i OpenVPN peker på AEAD-valg, blant dem AES-GCM, for datakanalen, og det er den typen støttet policy som bør følges. Bruk valgene som den installerte versjonen og peer-klientene støtter, i stedet for å kopiere en historisk modusrekkefølge inn i en ny utrulling. Eldre kompatibilitet, kryptobakgrunner og offload-støtte begrenser hva som reelt 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 aktive sesjonen. Les den forhandlede datakanalbeskyttelsen fra klienten eller gatewayen, og sammenlign den med policyen du ønsket å håndheve. En konfigurasjon som fortsatt lister et eldre valg for en gammel peer, er en kompatibilitetsbeslutning, ikke en påstand om sesjonen foran deg.

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

På en gateway er den tilsvarende utskriften sikkerhetsassosiasjonen eller kryptodetaljene for forbindelsen, avhengig av plattform. I begge tilfeller er tilbudet og resultatet forskjellige fakta. En liste som inneholder et eldre valg for en gammel peer, betyr ikke at hver sesjon bruker det, og sesjonen som gjør det, er det du trengte å vite.

Skriv ned begge fakta sammen, med dato og klientversjon.

Mål bare det som kan sammenlignes

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 som noen andre eier. Dine egne tall begynner ved dine egne endepunkter.

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

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

Hold integriteten utenfor handelen

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

Skriv den aksepterte konstruksjonen og eieren dens i håndboken, slik at neste endring begynner med en beslutning og ikke en preferanse.

Det du ønsker, er en policy som begge ender kan håndheve. Å krangle om hvilket navn som er sterkest, er en annen samtale, og den ender vanligvis uten beslutning.