AES-256-GCM vart ikkje funne: evna til klienten eller forhandlinga?

Ein OpenVPN-profil som verkar andre stader melder at AES-256-GCM ikkje finst, eller at partane ikkje deler nokon chiffer, og den første innskytten er å endre profilen. Dei to meldingane skildrar ulike feil. Den eine seier at det lokale programmet ikkje har den algoritmen; den andre at begge endar har algoritmar, men ikkje eit felles val. Å endre profilen rettar ingen av dei før du veit kva du har.

Les den nøyaktige feilteksten og programmet som laga han.

Avgjer kva feil du har

Meldinga om ein chiffer som ikkje finst, kjem frå tolking av val på den lokale maskina, før noka pakke vert send. Det tyder at den køyrbare fila framfor deg, eller biblioteket ho er lenka mot, ikkje tilbyr den algoritmen. Meldinga om ingen felles chiffer kjem seinare, under forhandlinga, og tyder at begge sider støttar chifre, men ikkje vert samde om éin.

Skilnaden har noko føre seg fordi den eine er eit problem med programvareversjonen og den andre eit konfigurasjonsproblem. Den første vert avgjord av eit versjonsnummer. Den andre vert avgjord ved å samanlikne to lister.

Eit lokalt hol i evnene

Gamle fellesskapsbyggingar er eldre enn dei moderne standardverdiane, og eit skrivebordsprogram kan ta med si eiga motor som avvik frå kommandolinjepakken som er installert ved sida av. Køyr kontrollane på den køyrbare fila som faktisk starta sambandet, og vel så ei støtta bygging i staden for å lære eit gamalt program ein ny algoritme.

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

Om AES-256-GCM ikkje står på den lista, legg ingen profillinje han til. Løysinga er ein nyare klient eller ei anna bygging, og avgrensingane til den eldre parten vert eit eige designspørsmål.

For klientar baserte på OpenVPN 3 avvik motoren og dei godtekne direktiva frå fellesskapslinja 2.x, så den same profillteksten kan feile av grunnar som ikkje har noko med chifferlista å gjere.

Eit hol i forhandlinga

Når begge partar listar algoritmen, er spørsmålet kva liste kvar side tilbyr. Fellesskaps-OpenVPN gav forhandlingsdirektivet nytt namn: ncp-ciphers i 2.4 vart data-ciphers i 2.5, og i 2.6 tener den eldre cipher-linja mest til kompatibilitet og tilbakefall framfor å definere det forhandla settet.

Difor kan ei endring av berre ei gamal cipher-linje la forhandlingslista vere urørd. Den gamle linja er framleis viktig for tilbakefall, og det er ein eigen oppgåve. Å blande dei to gjev endringar som ikkje endrar noko synleg.

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

Samanlikn listene i begge endar og avvisingsmeldinga til tenaren. Om snittet er tomt, juster listene medvite i staden for å kopiere ein verdi frå eit innlegg skrive for ein annan versjon. Ei for romsleg liste svekkjer stille kvar samband. Ei for smal liste utelèt parten du ville behalde.

Hald kompatibiliteten eksplisitt

Eit tilbakefall for éin gamal part er eit vedtak med ein kostnad: heile utrullinga godtek eit svakare alternativ for at éi eining skal kunne kople til. Skriv det ned som slikt, og avgrens det til parten som treng det.

To vilkår avgjer utfallet. Er feilen lokal, byt ut bygginga. Er feilen forhandla, juster listene i begge endar og noter kva versjonar du støttar.

Rapporter så den nøyaktige feilen med versjons- og evneutdata vedlagt. Det paret skil ein manglande algoritme frå ei usemje og stoggar neste runde med spekulative endringar før han byrjar.