AES-256-GCM ble ikke funnet: klientens evne eller forhandling?

En OpenVPN-profil som virker andre steder, melder at AES-256-GCM ikke finnes, eller at partene ikke deler noen chiffer, og den første innskytelsen er å endre profilen. De to meldingene beskriver forskjellige feil. Den ene sier at det lokale programmet ikke har den algoritmen; den andre at begge ender har algoritmer, men ikke et felles valg. Å endre profilen retter ingen av dem før du vet hvilken du har.

Les den nøyaktige feilteksten og programmet som produserte den.

Avgjør hvilken feil du har

Meldingen om en chiffer som ikke finnes, kommer fra tolkning av valg på den lokale maskinen, før noen pakke sendes. Det betyr at den kjørbare filen foran deg, eller biblioteket den er lenket mot, ikke tilbyr den algoritmen. Meldingen om ingen felles chiffer kommer senere, under forhandlingen, og betyr at begge sider støtter chiffere, men ikke blir enige om én.

Forskjellen betyr noe fordi den ene er et problem med programvareversjonen og den andre et konfigurasjonsproblem. Den første avgjøres av et versjonsnummer. Den andre avgjøres ved å sammenligne to lister.

Et lokalt hull i evnene

Gamle fellesskapsbygginger er eldre enn de moderne standardverdiene, og et skrivebordsprogram kan ta med sin egen motor som avviker fra kommandolinjepakken som er installert ved siden av. Kjør kontrollene på den kjørbare filen som faktisk startet forbindelsen, og velg deretter en støttet bygging i stedet for å lære et gammelt program en ny algoritme.

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

Hvis AES-256-GCM ikke står på den listen, legger ingen profillinje den til. Løsningen er en nyere klient eller en annen bygging, og begrensningene til den eldre parten blir et eget designspørsmål.

For klienter basert på OpenVPN 3 avviker motoren og de godtatte direktivene fra fellesskapslinjen 2.x, så den samme profitteksten kan feile av grunner som ikke har noe med chifferlisten å gjøre.

Et hull i forhandlingen

Når begge parter lister algoritmen, er spørsmålet hvilken liste hver side tilbyr. Fellesskaps-OpenVPN ga forhandlingsdirektivet nytt navn: ncp-ciphers i 2.4 ble data-ciphers i 2.5, og i 2.6 tjener den eldre cipher-linjen mest til kompatibilitet og tilbakefall framfor å definere det forhandlede settet.

Derfor kan en endring av bare en gammel cipher-linje la forhandlingslisten være urørt. Den gamle linjen er fortsatt viktig for tilbakefall, og det er en egen oppgave. Å blande de to gir endringer som ikke endrer noe synlig.

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

Sammenlign listene i begge ender og serverens avvisningsmelding. Hvis snittet er tomt, juster listene bevisst i stedet for å kopiere en verdi fra et innlegg skrevet for en annen versjon. En for romslig liste svekker stille hver forbindelse. En for smal liste utelukker parten du ville beholde.

Hold kompatibiliteten eksplisitt

Et tilbakefall for én gammel part er et vedtak med en kostnad: hele utrullingen godtar et svakere alternativ for at én enhet skal kunne koble til. Skriv det ned som sådan, og begrens det til parten som trenger det.

To vilkår avgjør utfallet. Er feilen lokal, bytt ut byggingen. Er feilen forhandlet, juster listene i begge ender og noter hvilke versjoner du støtter.

Rapporter deretter den nøyaktige feilen med versjons- og evneutdata vedlagt. Det paret skiller en manglende algoritme fra en uenighet og stopper neste runde med spekulative endringer før den begynner.