OpenVPN tls-ciphersuites kontra tls-version-min: hvad hver især håndhæver

Tre forskellige fakta bliver slået sammen til én linje i de fleste OpenVPN TLS-diskussioner: hvad din klientbuild kan, hvad profilen tillader, og hvad sessionen faktisk forhandlede. En kort TLS 1.3-suiteliste besvarer kun det midterste spørgsmål halvt og siger intet om protokolversionens gulv. Gå gennem kontrollerne nedenfor i rækkefølge, og stop ved den første, der ikke holder, fordi hver senere kontrol forudsætter, at de tidligere er afklaret.

Kontroller buildet, før du læser nogen liste

En konfigurationsdirektiv kan ikke tilføje protokolunderstøttelse til en binær, der mangler den. Start med versionsbanneret, som angiver det kompilerede kryptobibliotek:

openvpn --version

Et 2.6-build linket mod OpenSSL accepterer både tls-cipher og tls-ciphersuites. Et build mod mbed TLS har slet ingen TLS 1.3-suitevalg, og 2.6-manualen markerer tls-ciphersuites som en OpenSSL-indstilling. Hvis serveren er genopbygget med en anden backend, kan den samme profil ændre adfærd, uden at en eneste linje konfiguration ændres.

Mens du er her, kør openvpn --show-tls og gem outputtet. Det er den fortegnelse, du senere vil sammenligne med, og det er billigt at fange den, før nogen begynder at redigere profiler.

Skriv banneret og listen ind i ændringsbilletten, ikke i et chatvindue. Når to personer er uenige om, hvorvidt en klient kan tilbyde en suite om seks uger, afgør det fangede output det på én linje.

Hold versionsgrænser adskilt fra cipherlister

I 2.6-manualen er disse tre kontroller, ikke én:

• tls-cipher sætter cipherpolitikken for TLS 1.2 og tidligere og sendes videre til OpenSSLs cipherliste;
• tls-ciphersuites vælger TLS 1.3-suiter;
• tls-version-min og tls-version-max begrænser de protokolversioner, forbindelsen må bruge.

En omhyggeligt trimmet TLS 1.3-suiteliste beviser altså intet om, at en ældre version stadig er tilladt. Hvis kravet er »kun TLS 1.3«, er det versionsgulvet, der bærer det, og suitelisten indsnævrer kun valgene inden for det gulv:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Det par udfører to opgaver. Sletter man en af linjerne, håndhæver den anden mindre, end du tror, og det er netop den fejl, hele denne kontrol findes for at fange.

Datakanalen er en fjerde kontrol. data-ciphers forhandler den symmetriske cipher inde i tunnelen, og resultatet siger intet om kontrolkanalens TLS-version. At se AES-256-GCM i sessionsoversigten er ikke bevis for TLS 1.3 i nogen retning.

Læs show-tls som en lokal fortegnelse

--show-tls viser de suiter, som det kryptobibliotek, denne binær er linket mod, understøtter, i præferenceorden. Det er ikke en rapport fra gatewayen. Manualen siger udtrykkeligt, at listen kommer fra det lokale bibliotek, hvilket betyder, at en bærbar med OpenSSL 3.x og en router med et ældre build vil udskrive forskellige lister, mens de taler med den samme server.

Antag, at en klient understøtter suiterne A, B og C, og at én session vælger B. Det fastslår intet om, hvorvidt serveren tillader A eller C, og intet om, hvorvidt B er dens eneste tilladte valg. Hold de tre rækker adskilt, og de fleste forvirrende TLS-tråde løser sig selv.

Fortegnelsen er stadig værd at beholde. Når en session fejler, viser sammenligningen af bibliotekets liste med profilens liste, om klienten overhovedet havde en chance for at tilbyde det, serveren ville have. Den viser også, om en backend-ændring stille har fjernet TLS_CHACHA20_POLY1305_SHA256 fra den pulje, ældre klienter er afhængige af — den slags regression, der viser sig som en håndfuld brugere, der ikke kan forbinde, mens alle andre intet bemærker.

Stil gatewayen et spørgsmål, den kan besvare

Hvis du administrerer tjenesten, så undersøg den kørende instans' effektive konfiguration i stedet for en fil på disken. OpenVPN kan være startet med en anden --config-sti, kan hente includes, og er måske ikke genstartet siden ændringen. Det er den kørende daemons politik, klienterne møder.

Hvis du ikke administrerer den, så spørg operatøren om understøttede klientkrav eller en afgrænset accepttest. Et afvist forsøg er ikke automatisk en afvist suite: et versionsgulv, certifikatidentitetskontroller som remote-cert-tls eller en uoverensstemmelse mellem tls-auth og tls-crypt kan afslutte udvekslingen, før suitevalget bliver relevant. Læs serverens fejl, før du ændrer klientens liste, fordi »handshake failed« dækker fire forskellige årsager, og kun én af dem er en cipher-uoverensstemmelse.

At pege openssl s_client mod VPN-porten gengiver heller ikke spørgsmålet. Kontrolkanalen kører inde i OpenVPNs egen indramning, så en rå TLS-probe tester en anden protokol på en port, der forventer noget andet. Enhver konklusion derfra handler om proben, ikke om tunnelen.

Registrér to resultater, og hold dem adskilt

En ny tilladt session producerer en kontrolkanal-linje, der angiver protokolversionen og den valgte cipher, og en separat datakanal-linje, der angiver tunnelens cipher. Fang begge med klientversionen og profilnavnet, og notér, hvilken serverinstans der svarede:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Læs derefter de to linjer ud af den fil i stedet for fra hukommelsen. Parret er beviset; et suitenavn alene er en præference, og versionsgrænsen er en separat erklæring om, hvad serveren afviser.

Kør kontrollerne i denne rækkefølge. Bekræft buildet og backend med --version. Fang --show-tls, før du ændrer noget. Angiv det krævede versionsgulv separat fra suitelisten. Bekræft den kørende instans' effektive politik med dens ejer. Observer én tilladt session og, hvis planen tillader det, ét afvist forsøg med en ældre version. Registrér kontrolkanalens og datakanalens resultater som separate fund.

Hvis en krævet klient ikke kan opfylde et nyt minimum, så træf den migrations- eller undtagelsesbeslutning eksplicit i stedet for stille at sænke en urelateret acceptregel for at få udrulningen til at se færdig ud.