AES-256 eller OFB: välj en komplett VPN-chifferkonstruktion

AES-256 och OFB svarar på olika frågor, och det är här chiffergranskningar går fel när de behandlas som konkurrerande alternativ. Den ena namnger ett blockchiffer med en nyckellängd; den andra beskriver hur ett blockchiffer görs om till en ström för ett längre meddelande. En runbook för val av skydd måste titta på hela konstruktionen, inklusive hur mottagaren upptäcker ett ändrat paket.

Namnge konstruktionens fyra delar

Varje granskning kokar ner till fyra frågor: vilken primitiv och nyckellängd, hur meddelanden bearbetas med den, hur mottagaren avvisar en obehörig ändring och hur protokollet hanterar indata, nycklar och deras livslängd. En lista med bekanta namn svarar bara på den första. Den andra och tredje är där de verkliga skillnaderna finns, och den fjärde är där implementationer tyst glider isär. Ställ dem i den ordningen och skriv ner svaren.

OFB finns bland sekretesslägena i NIST:s publikation om blockchifferlägen, och sekretess är allt det erbjuder. Ett protokoll som parar ett krypteringsläge med en separat MAC måste sätta ihop dem korrekt, och ett algoritmnamn bevisar inte den sammansättningen. Därför kan lägesnamnet ensamt inte avgöra ett införandebeslut.

Den fjärde frågan är den som en operatör faktiskt kan verifiera på det körande systemet.

Föredra en autentiserad konstruktion

Autentiserad kryptering ger sekretess och integritet tillsammans, och AEAD-konstruktioner skyddar även associerade data mot ändring utan att kryptera dem. Det är en egenskap hos paketskyddet och har inget att göra med om en människa har loggat in.

Netgates Netgates vägledning för OpenVPN:s kryptoinställningar pekar på AEAD-alternativ, bland dem AES-GCM, för datakanalen, och det är den typen av stött policy som bör följas. Använd de val som den installerade versionen och peer-klienterna stöder, i stället för att kopiera en historisk lägesrangordning till en ny driftsättning. Äldre kompatibilitet, kryptobackends och offload-stöd begränsar vad som faktiskt är tillgängligt.

En stödd konstruktion slår en smart sammansättning varje gång.

Läs det förhandlade resultatet, inte erbjudandet

Ett chiffer på en accepterad lista säger ingenting om den aktuella sessionen. Läs det förhandlade datakanalsskyddet hos klienten eller på gatewayen och jämför det med den princip du ville genomdriva. En konfiguration som fortfarande listar ett äldre alternativ för en gammal peer är ett kompatibilitetsbeslut, inte ett påstående om sessionen framför dig.

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

På en gateway är motsvarande utdata säkerhetsassociationen eller anslutningens kryptodetaljer, beroende på plattform. I båda fallen är erbjudandet och resultatet olika fakta. En lista med ett äldre alternativ för en gammal peer betyder inte att varje session använder det, och den session som gör det är det du behövde veta.

Anteckna båda fakta tillsammans, med datum och klientversion.

Mät bara det som går att jämföra

Genomströmningen beror på ändpunkternas hårdvara, implementationen, acceleration, paketstorlekar och den valda konfigurationen. Varken nyckellängden eller ordet OFB säger vilken driftsättning som blir snabbare. Därför är ett benchmark från en annan webbplats i bästa fall en antydan om hårdvara som någon annan äger. Dina egna siffror börjar vid dina egna ändpunkter.

För en auktoriserad jämförelse håller du ändpunkter, arbetsbelastning och den krävda principen konstanta och antecknar det förhandlade skyddet samt implementationsversionerna. Bedöm sedan resultatet efter om applikationen blev klar, hur mycket den förlorade och vad ändpunkterna gjorde, i stället för att härleda kryptokostnad från ett enda hastighetstest. En siffra som tagits fram under andra förhållanden är en berättelse, inte en mätning.

Om en gammal peer inte kan uppfylla principen är det ett kompatibilitetsbeslut för dess ägare.

Håll integriteten utanför affären

Att stänga av integritetskontroller eller acceptera en overifierad server är inte en prestandaoptimering och inte en kompatibilitetsrättelse. Det ändrar den säkerhetsegenskap som konstruktionen valdes för. Samma sak gäller att utöka den accepterade chifferlistan tills en gammal peer ansluter: anslutningen lyckas och principen finns inte längre.

Skriv den accepterade konstruktionen och dess ägare i runbooken, så att nästa ändring börjar med ett beslut och inte en preferens.

Det du vill ha är en princip som båda ändar kan genomdriva. Att argumentera för att ett namn är starkast är ett annat samtal, och det slutar oftast utan beslut.