Waarom AES-256 nie n VPN-versleutelingspakket beskryf nie

Vra watter versleuteling n VPN gebruik, en die antwoord kom gewoonlik as een woord terug: AES-256, of ChaCha20, of miskien WireGuard. Daardie antwoord noem een komponent van een laag, terwyl die ding wat die verbinding werklik beskerm n stel algoritmes is wat vier verskillende rolle vul. Om die komponent met die rangskikking te verwar is die algemeenste fout in hierdie gesprekke, en dit lewer vergelykings op wat nie opgelos kan word nie.

Vier take binne een verbinding

Grootmaatversleuteling verander gewone teks in syferteks vir die datakanaal, en sy sleutel word afgelei eerder as oorgedra. Integriteitsbeskerming bespeur verandering, wat n aparte taak is selfs wanneer een konstruksie albei doen. Sleutelvestiging lewer die gedeelde verkeersmateriaal, en eweknie-verifikasie besluit wie aan die ander kant is. Mis een daarvan en die verbinding is nie veilig nie, maak nie saak hoe sterk die oorblywende stuk is nie.

Sommige ontwerpe voeg twee rolle saam. AES-GCM en ChaCha20-Poly1305 is geauthentiseerde versleutelingskonstruksies, dus kom vertroulikheid en integriteit saam; AES-CBC nie, en het n aparte boodskapverifikasiekode met sy eie sleutel nodig. Om n voorstel as n sak onafhanklike getalle te lees, mislees dus die wat as pare ontwerp is.

Die rolle sit ook op verskillende lae, en daarom kan dieselfde woord in twee produkte verskillende dinge beteken. n Bloksyfer in ESP en n bloksyfer in TLS is dieselfde primitief in verskillende onderhandelinge met verskillende vereistes. Daarom kan dit erger wees om n primitief sonder sy modus en laag aan te haal as om niks aan te haal nie.

Waarom n syfernaam amper niks se

Neem die frase AES-256 vir n oomblik ernstig: dit dui n bloksyfer en n sleutelgrootte aan. Dit se niks oor die werkingsmodus, of integriteit gelewer word, hoe sleutels gevestig of die eweknie geverifieer is nie. Twee produkte kan albei AES-256 adverteer en in elke ander opsig verskil, insluitend een met n ongeauthentiseerde modus en een met n AEAD-modus en moderne sleuteluitruiling.

TLS 1.3 het hierdie skeiding in die standaard ingebou, wat n nuttige regstelling is vir enigiemand wat die ouer woordeskat geleer het. Sy syferpakke noem net die AEAD en die hash, terwyl sleuteluitruilgroepe en handtekeningalgoritmes as aparte parameters onderhandel word. n TLS 1.3-paknaam is dus nie op gelyke voet met n TLS 1.2-paknaam vergelykbaar nie, al verskyn albei in dieselfde veld van n konfigurasielêer. n Ouditeur wat die twee stringe direk vergelyk, trek dus n gevolgtrekking wat die protokol nie ondersteun nie. Lees ook die onderhandelde groep en handtekeningparameters, anders is die vergelyking onvolledig.

WireGuard volg die teenoorgestelde benadering en verwyder onderhandeling byna heeltemal: die protokol spesifiseer n vaste algoritmestel, dus werk twee implementasies saam of nie. Dit is n wettige ontwerpkeuse, en dit beteken ook dat die vraag watter pakket WireGuard onderhandel geen antwoord het wat die moeite werd is om te vergelyk nie. As jy dit oudit, lees die spesifikasie een keer en oudit dan die sleutelhantering daaromheen eerder as die onderhandeling.

Die laag bepaal die woordeskat

n IPsec-ontplooiing onderhandel twee keer: n IKE-voorstel vir die beheerkanaal en n ESP-transform vir die data, en die twee mag wettig verskil. Om die eerste te lees en aan te neem dit beskryf die tweede is n algemene bron van verwarring tydens n oudit, want die konfigurasielêer noem albei en die interessante een is die tweede.

n Naam wat in een biblioteek beskikbaar is, is nie outomaties vir n ander datapad geïmplementeer nie. Daarom is die stelling dat ons produk AES-256 ondersteun swakker as wat dit klink, en daarom word n interoperabiliteitsprobleem gewoonlik opgelos deur die onderhoude snyding te vind eerder as om elke ou algoritme aan beide kante te aktiveer.

Die TLS 1.3-spesifikasie is die duidelikste gepubliseerde voorbeeld van die skeiding, want dit definieer die pakket as n paar en skuif die res na hul eie onderhandeling. Sodra daardie vorm bekend is, word die IPsec-voorstel en die enkele vaste WireGuard-stel leesbaar as variante op dieselfde idee.

Lees die onderhandelde resultaat, dan stop

n Gekonfigureerde voorstel is nie bewys van wat twee eweknieë gekies het nie. Die lewende sessie dra die antwoord, en elke hoofstroom-implementasie kan dit rapporteer sonder n pakkie-opname.

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

Lees in die uitset die gekose algoritmes eerder as die aangebode lys. As die antwoord swakker is as wat die beleid bedoel het, hoort die regstelling in die voorstel-konfigurasie aan een of ander kant, en n wanverhouding wys in moderne implementasies gewoonlik as n mislukte onderhandeling eerder as n stil degradering.

Onthou dan wat die pakket nie dek nie. Roetes, toepassingstoestemmings, logboek en bewaring is aparte besluite met hul eie hersiening, en n versoenbare kriptografiese rangskikking se niks daaroor nie. Die syfergesprek is die moeite werd, maar dit beantwoord n nouer vraag as die een wat die meeste mense eintlik vra.

Hou die woordeskat presies, en die argument word korter. n Pakket is n stel rolle op n laag, n syfer is een komponent, en die onderhandelde resultaat is die enigste ding wat die verbinding beskryf wat jy werklik het. Alles anders in die vergelyking is versiering.