AES-256-GCM niet gevonden: clientcapaciteit of onderhandeling?

Een OpenVPN-profiel dat elders werkt meldt dat AES-256-GCM niet gevonden wordt, of dat de peers geen gedeelde cipher hebben, en de eerste neiging is het profiel aan te passen. Die twee berichten beschrijven verschillende storingen. Het ene zegt dat het lokale programma dat algoritme niet heeft; het andere dat beide kanten algoritmen hebben maar geen gemeenschappelijke keuze. Het profiel aanpassen lost geen van beide op tot je weet welke je hebt.

Lees de exacte fouttekst en het programma dat hem heeft geproduceerd.

Bepaal welke fout je hebt

Het bericht over een cipher die niet gevonden wordt, komt uit de optieanalyse op de lokale machine, voordat er een pakket wordt verzonden. Het betekent dat het uitvoerbare bestand voor je, of de bibliotheek waaraan het linkt, dat algoritme niet biedt. Het bericht over geen gedeelde cipher komt later, tijdens de onderhandeling, en betekent dat beide zijden ciphers ondersteunen maar het niet eens worden over een.

Het onderscheid is belangrijk omdat het ene een probleem met de softwareversie is en het andere een configuratieprobleem. Het eerste wordt beslecht door een versienummer. Het tweede door twee lijsten te vergelijken.

Een lokaal capaciteitstekort

Oude community-builds zijn ouder dan de moderne standaardwaarden, en een desktopapplicatie kan zijn eigen engine meebrengen die afwijkt van het commandoregelpakket dat ernaast is geïnstalleerd. Voer de controles uit op het uitvoerbare bestand dat de verbinding werkelijk startte, en kies dan een ondersteunde build in plaats van een oud programma een nieuw algoritme te leren.

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

Als AES-256-GCM niet in die lijst staat, voegt geen enkele profielregel het toe. De oplossing is een nieuwere client of een andere build, en de beperkingen van de oudere kant worden een apart ontwerpvraagstuk.

Bij clients op basis van OpenVPN 3 verschillen de engine en de geaccepteerde richtlijnen van de communitylijn 2.x, dus dezelfde profieltekst kan mislukken om redenen die niets met de cipherlijst te maken hebben.

Een onderhandelingstekort

Wanneer beide peers het algoritme opsommen, blijft de vraag welke lijst elke kant biedt. De community-OpenVPN hernoemde de onderhandelingsrichtlijn: ncp-ciphers in 2.4 werd data-ciphers in 2.5, en in 2.6 dient de oudere cipher-regel vooral compatibiliteit en terugval, niet het bepalen van de onderhandelde set.

Daarom kan het wijzigen van alleen een oude cipher-regel de onderhandelingslijst ongemoeid laten. De oude regel blijft belangrijk voor terugval, en dat is een aparte taak. De twee verwarren levert wijzigingen op die zichtbaar niets veranderen.

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

Vergelijk de lijsten van beide uiteinden en het weigeringsbericht van de server. Is de doorsnede leeg, stem de lijsten dan bewust af in plaats van een waarde te kopiëren uit een artikel voor een andere versie. Een te ruime lijst verzwakt stil elke verbinding. Een te smalle lijst sluit de peer uit die je wilde houden.

Houd compatibiliteit expliciet

Een terugval voor een oude peer is een beslissing met een prijs: de hele uitrol accepteert een zwakkere optie zodat een apparaat kan verbinden. Schrijf het als zodanig op en beperk het tot de peer die het nodig heeft.

Twee voorwaarden bepalen de uitkomst. Is de fout lokaal, vervang dan de build. Is de fout onderhandeld, stem de lijsten dan aan beide kanten af en noteer welke versies je ondersteunt.

Meld daarna de exacte fout met de versie- en capaciteitsuitvoer bijgevoegd. Dat paar scheidt een ontbrekend algoritme van een meningsverschil en stopt de volgende ronde speculatieve wijzigingen voordat die begint.