AES-256 kontra OFB: vælg en komplet VPN-chifferkonstruktion

AES-256 og OFB besvarer forskellige spørgsmål, og det er her chiffergennemgange går galt, når de behandles som konkurrerende valgmuligheder. Den ene navngiver en blokchiffer med en nøglestørrelse; den anden beskriver, hvordan en blokchiffer omdannes til en strøm til en længere besked. En runbook til valg af beskyttelse skal se på hele konstruktionen, herunder hvordan modtageren opdager en ændret pakke.

Navngiv konstruktionens fire dele

Hver gennemgang reduceres til fire spørgsmål: hvilken primitiv og nøglestørrelse, hvordan beskeder behandles med den, hvordan modtageren afviser uautoriseret ændring, og hvordan protokollen styrer input, nøgler og deres levetid. En liste over velkendte navne besvarer kun det første. Det andet og tredje er der, hvor de reelle forskelle ligger, og det fjerde er der, hvor implementeringer stille divergerer. Stil dem i den rækkefølge, og skriv svarene ned.

OFB optræder blandt fortrolighedstilstandene i NIST-publikationen om blokchiffertilstande, og fortrolighed er alt, hvad den giver. En protokol, der parrer en krypteringstilstand med en separat MAC, skal sammensætte dem korrekt, og et algoritmenavn beviser ikke den sammensætning. Derfor kan tilstandens navn alene ikke afgøre en udrulningsbeslutning.

Det fjerde spørgsmål er det, en operatør faktisk kan verificere på det kørende system.

Foretræk en autentificeret konstruktion

Autentificeret kryptering giver fortrolighed og integritet sammen, og AEAD-konstruktioner beskytter også tilknyttede data mod ændring uden at kryptere dem. Det er en egenskab ved pakkebeskyttelse og har intet at gøre med, om et menneske er logget ind.

Netgates Netgates vejledning til OpenVPN-kryptografiindstillinger peger på AEAD-muligheder, heriblandt AES-GCM, til datakanalen, og det er den slags understøttede politik, man bør følge. Brug de valg, som den installerede version og peer-klienterne understøtter, i stedet for at kopiere en historisk tilstandsrangliste ind i en ny udrulning. Ældre kompatibilitet, kryptobackends og offload-understøttelse begrænser, hvad der reelt er tilgængeligt.

En understøttet konstruktion slår en smart sammensætning hver gang.

Læs det forhandlede resultat, ikke tilbuddet

En chiffer på en accepteret liste siger intet om den aktuelle session. Læs den forhandlede datakanalbeskyttelse hos klienten eller gatewayen, og sammenlign den med den politik, du ville håndhæve. En konfiguration, der stadig angiver en ældre mulighed for en gammel peer, er en kompatibilitetsbeslutning, ikke en udtalelse om sessionen foran dig.

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

På en gateway er det tilsvarende output sikkerhedsassociationen eller forbindelsens kryptodetaljer, afhængigt af platformen. Under alle omstændigheder er tilbuddet og resultatet forskellige fakta. En liste med en ældre mulighed for en gammel peer betyder ikke, at hver session bruger den, og den session, der gør, er det, du havde brug for at vide.

Notér begge fakta sammen, med dato og klientversion.

Mål kun det, du kan sammenligne

Gennemstrømning afhænger af endepunkternes hardware, implementeringen, acceleration, pakkestørrelser og den valgte konfiguration. Hverken nøglelængden eller ordet OFB fortæller dig, hvilken udrulning der bliver hurtigst. Derfor er et benchmark fra et andet site i bedste fald et hint om hardware, som en anden ejer. Dine egne tal starter ved dine egne endepunkter.

Til en autoriseret sammenligning skal du holde endepunkter, arbejdsbelastning og den krævede politik konstante og notere den forhandlede beskyttelse plus implementeringsversionerne. Bedøm derefter resultatet på, om applikationen blev færdig, hvor meget den mistede, og hvad endepunkterne lavede, i stedet for at udlede kryptoomkostninger af en enkelt hastighedstest. Et tal produceret under andre forhold er en historie, ikke en måling.

Hvis en gammel peer ikke kan opfylde politikken, er det en kompatibilitetsbeslutning for dens ejer.

Hold integritet uden for handlen

At slå integritetskontroller fra eller acceptere en uverificeret server er ikke en ydeevneoptimering, og det er ikke en kompatibilitetsrettelse. Det ændrer den sikkerhedsegenskab, som konstruktionen blev valgt for at give. Det samme gælder for at udvide den accepterede chifferliste, indtil en gammel peer forbinder: forbindelsen lykkes, og politikken findes ikke længere.

Skriv den accepterede konstruktion og dens ejer i runbooken, så den næste ændring starter med en beslutning frem for en præference.

Det, du vil have, er en politik, som begge ender kan håndhæve. At argumentere for, at ét navn er det stærkeste, er en anden samtale, og den ender normalt uden beslutning.