OpenVPN tls-ciphersuites kontra tls-version-min: hva hver håndhever

Tre ulike fakta presses sammen til én linje i de fleste OpenVPN-TLS-diskusjoner: hva klientbyggingen din kan, hva profilen tillater, og hva økten faktisk forhandlet. En kort liste over TLS 1.3-sviter besvarer bare halvveis det midterste spørsmålet, og den sier ingenting om protokollversjonens gulv. Gå gjennom kontrollene nedenfor i rekkefølge og stopp ved den første som ikke holder, fordi hver senere kontroll forutsetter at de tidligere er avklart.

Kontroller byggingen før du leser noen liste

En konfigurasjonsdirektiv kan ikke legge til protokollstøtte i en binærfil som mangler det. Start med versjonsbanneret, som navngir det kompilerte kryptobiblioteket:

openvpn --version

En 2.6-bygging lenket mot OpenSSL godtar både tls-cipher og tls-ciphersuites. En bygging mot mbed TLS har ingen valg av TLS 1.3-sviter i det hele tatt, og 2.6-håndboken markerer tls-ciphersuites som et OpenSSL-alternativ. Hvis serveren bygges på nytt med en annen backend, kan samme profil endre atferd uten at én eneste konfigurasjonslinje endres.

Mens du er her, kjør openvpn --show-tls og ta vare på utdataene. Det er inventaret du senere skal sammenligne mot, og det er billig å fange det før noen begynner å redigere profiler.

Skriv banneret og listen inn i endringssaken, ikke i et chattevindu. Når to personer krangler om en klient kan tilby en svit om seks uker, avgjør de fangede utdataene det på én linje.

Hold versjonsgrenser atskilt fra sifferlister

I 2.6-håndboken er disse tre kontroller, ikke én:

• tls-cipher setter sifferpolicyen for TLS 1.2 og eldre, og sendes videre til OpenSSLs sifferliste;
• tls-ciphersuites velger TLS 1.3-sviter;
• tls-version-min og tls-version-max begrenser protokollversjonene forbindelsen kan bruke.

En nøye trimmet liste over TLS 1.3-sviter beviser altså ingenting om at en eldre versjon fortsatt er tillatt. Hvis kravet er «bare TLS 1.3», er det versjonsgulvet som bærer det, og svitelisten innsnevrer bare valgene innenfor det gulvet:

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

Det paret gjør to jobber. Sletter man en av linjene, håndhever den andre mindre enn du tror, og det er nettopp feilen hele denne kontrollen finnes for å fange.

Datakanalen er en fjerde kontroll. data-ciphers forhandler den symmetriske sifferen inne i tunnelen, og resultatet sier ingenting om kontrollkanalens TLS-versjon. Å se AES-256-GCM i øktsammendraget er ikke bevis for TLS 1.3 i noen retning.

Les show-tls som et lokalt inventar

--show-tls viser svitene som kryptobiblioteket denne binærfilen er lenket mot støtter, i preferanserekkefølge. Det er ikke en rapport fra gatewayen. Håndboken sier eksplisitt at listen kommer fra det lokale biblioteket, noe som betyr at en bærbar PC med OpenSSL 3.x og en ruter med eldre bygging vil skrive ut ulike lister mens de snakker med samme server.

Anta at en klient støtter svitene A, B og C, og at én økt velger B. Det fastslår ingenting om hvorvidt serveren tillater A eller C, og ingenting om hvorvidt B er dens eneste tillatte valg. Hold de tre radene atskilt, og de fleste forvirrende TLS-tråder løser seg selv.

Inventaret er likevel verdt å ta vare på. Når en økt feiler, viser sammenligningen av bibliotekets liste med profilens liste om klienten i det hele tatt hadde en sjanse til å tilby det serveren ville ha. Den viser også om en backend-endring stille har fjernet TLS_CHACHA20_POLY1305_SHA256 fra bassenget eldre klienter er avhengige av — den typen regresjon som viser seg som en håndfull brukere som ikke får koblet til, mens alle andre ikke merker noe.

Spør gatewayen om noe den kan svare på

Hvis du administrerer tjenesten, undersøk den kjørende instansens effektive konfigurasjon i stedet for en fil på disken. OpenVPN kan ha blitt startet med en annen --config-sti, kan hente inkluderinger, og er kanskje ikke restartet siden endringen. Det er den kjørende daemonens policy klientene møter.

Hvis du ikke administrerer den, spør operatøren om støttede klientkrav eller en avgrenset aksepttest. Et avvist forsøk er ikke automatisk en avvist svit: et versjonsgulv, sertifikatidentitetskontroller som remote-cert-tls, eller et misforhold mellom tls-auth og tls-crypt kan avslutte utvekslingen før svitvalget blir relevant. Les serverens feil før du endrer klientens liste, fordi «handshake failed» dekker fire ulike årsaker, og bare én av dem er et siffermisforhold.

Å peke openssl s_client mot VPN-porten gjenskaper heller ikke spørsmålet. Kontrollkanalen går inne i OpenVPNs egen innramming, så en rå TLS-probe tester en annen protokoll på en port som forventer noe annet. Enhver konklusjon derfra handler om proben, ikke om tunnelen.

Registrer to resultater og hold dem atskilt

En fersk tillatt økt gir en kontrollkanallinje som navngir protokollversjonen og den valgte sifferen, og en egen datakanallinje som navngir tunnelens siffer. Fang begge med klientversjonen og profilnavnet, og noter hvilken serverinstans som svarte:

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

Les deretter de to linjene fra den filen i stedet for fra hukommelsen. Paret er beviset; et svitenavn alene er en preferanse, og versjonsgrensen er en separat uttalelse om hva serveren avviser.

Utfør kontrollene i denne rekkefølgen. Bekreft byggingen og backend med --version. Fang --show-tls før du endrer noe. Oppgi det påkrevde versjonsgulvet atskilt fra svitelisten. Bekreft den kjørende instansens effektive policy med eieren. Observer én tillatt økt og, hvis planen tillater det, ett avvist forsøk med en eldre versjon. Registrer resultatene for kontrollkanalen og datakanalen som separate funn.

Hvis en påkrevd klient ikke kan oppfylle et nytt minimum, ta den migrerings- eller unntaksbeslutningen eksplisitt i stedet for å senke en urelatert akseptregel i stillhet for at utrullingen skal se ferdig ut.