Waarom AES-256 geen VPN-versleutelingssuite beschrijft

Vraag welke versleuteling een VPN gebruikt en het antwoord komt meestal als één woord: AES-256, of ChaCha20, of misschien WireGuard. Dat antwoord noemt één component van één laag, terwijl wat de verbinding werkelijk beschermt een set algoritmen is die vier verschillende rollen vervult. Het component met de opzet verwarren is de meest voorkomende fout in deze gesprekken, en het levert vergelijkingen op die niet te beslechten zijn.

Vier taken in één verbinding

Bulkversleuteling verandert leesbare tekst in cijfertekst voor het datakanaal, en de sleutel wordt afgeleid in plaats van verzonden. Integriteitsbescherming detecteert wijziging, wat een aparte taak is, ook wanneer één constructie beide doet. Sleutelopbouw levert het gedeelde verkeersmateriaal, en authenticatie van de tegenpartij bepaalt wie aan de andere kant zit. Ontbreekt één ervan, dan is de verbinding niet veilig, hoe sterk het overblijvende stuk ook is.

Sommige ontwerpen voegen twee rollen samen. AES-GCM en ChaCha20-Poly1305 zijn geauthenticeerde versleutelingsconstructies, dus vertrouwelijkheid en integriteit komen samen; AES-CBC niet, en het heeft een aparte berichtauthenticatiecode met een eigen sleutel nodig. Een voorstel als een zak onafhankelijke getallen lezen leest daarom degenen verkeerd die als paren zijn ontworpen.

De rollen liggen ook op verschillende lagen, en daarom kan hetzelfde woord in twee producten iets anders betekenen. Een blokcijfer in ESP en een blokcijfer in TLS zijn hetzelfde primitief in verschillende onderhandelingen met verschillende eisen. Daarom kan het citeren van een primitief zonder zijn modus en laag slechter zijn dan niets citeren.

Waarom een cijfernaam bijna niets zegt

Neem de uitdrukking AES-256 even serieus: die duidt een blokcijfer en een sleutellengte aan. Hij zegt niets over de werkmodus, of integriteit wordt geleverd, hoe sleutels tot stand kwamen of hoe de tegenpartij werd geauthenticeerd. Twee producten kunnen beide AES-256 adverteren en op al het andere verschillen, waaronder een dat het aan een niet-geauthenticeerde modus koppelt en een dat een AEAD-modus met moderne sleuteluitwisseling gebruikt.

TLS 1.3 bracht deze scheiding in de standaard, wat een nuttige correctie is voor iedereen die het oudere vocabulaire leerde. De cijfersuites noemen alleen de AEAD en de hash, terwijl sleuteluitwisselingsgroepen en handtekeningalgoritmen als aparte parameters worden onderhandeld. Daarom is een TLS 1.3-suitennaam niet vergelijkbaar met een TLS 1.2-suitennaam op gelijke voet, ook al staan beide in hetzelfde veld van een configuratiebestand. Een auditor die de twee strings rechtstreeks vergelijkt, trekt een conclusie die het protocol niet ondersteunt. Lees ook de onderhandelde groep en de handtekeningparameters, anders is de vergelijking onvolledig.

WireGuard kiest de tegenovergestelde weg en haalt de onderhandeling bijna helemaal weg: het protocol schrijft een vaste algoritmeset voor, dus twee implementaties werken samen of niet. Dat is een legitieme ontwerpkeuze, en het betekent ook dat de vraag welke suite WireGuard onderhandelt geen antwoord heeft dat een vergelijking waard is. Als je het auditeert, lees de specificatie één keer en audit daarna het sleutelbeheer eromheen in plaats van de onderhandeling.

De laag bepaalt het vocabulaire

Een IPsec-implementatie onderhandelt twee keer: een IKE-voorstel voor het besturingskanaal en een ESP-transformatie voor de data, en die twee mogen legitiem verschillen. Het eerste lezen en aannemen dat het het tweede beschrijft is een veelvoorkomende bron van verwarring tijdens een audit, omdat het configuratiebestand beide noemt en het interessante het tweede is.

Een naam die in de ene bibliotheek beschikbaar is, is niet automatisch geïmplementeerd voor een ander datapad. Daarom is de bewering dat ons product AES-256 ondersteunt zwakker dan hij klinkt, en daarom wordt een interoperabiliteitsprobleem meestal opgelost door de onderhouden doorsnede te vinden in plaats van elk oud algoritme aan beide kanten in te schakelen.

De specificatie van TLS 1.3 is het duidelijkste gepubliceerde voorbeeld van de scheiding, omdat zij de suite als een paar definieert en de rest naar hun eigen onderhandeling verplaatst. Zodra die vorm bekend is, worden het IPsec-voorstel en de ene vaste WireGuard-set leesbaar als varianten van hetzelfde idee.

Lees het onderhandelde resultaat en stop dan

Een geconfigureerd voorstel is geen bewijs van wat twee partijen kozen. De levende sessie draagt het antwoord, en elke gangbare implementatie kan het melden zonder pakketten te vangen.

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

Lees in de uitvoer de gekozen algoritmen in plaats van de aangeboden lijst. Is het antwoord zwakker dan het beleid bedoelde, dan hoort de correctie in de voorstelconfiguratie aan een van beide kanten, en een afwijking uit zich in moderne implementaties meestal als een mislukte onderhandeling en niet als een stille verlaging.

Bedenk daarna wat de suite niet dekt. Routes, applicatierechten, logboekregistratie en bewaring zijn aparte beslissingen met hun eigen beoordeling, en een compatibele cryptografische opzet zegt daar niets over. De discussie over het cijfer is de moeite waard, maar beantwoordt een smallere vraag dan de vraag die de meeste mensen feitelijk stellen.

Houd het vocabulaire precies en het argument wordt korter. Een suite is een set rollen op een laag, een cijfer is één component, en het onderhandelde resultaat is het enige dat de verbinding beschrijft die je werkelijk hebt. Al het andere in de vergelijking is versiering.