OpenVPN tls-ciphersuites kontra tls-version-min: vad var och en genomdriver

Tre olika fakta pressas ihop till en rad i de flesta OpenVPN-TLS-diskussioner: vad din klientbuild kan, vad profilen tillåter och vad sessionen faktiskt förhandlade. En kort lista över TLS 1.3-sviter besvarar bara halva mittfrågan och säger ingenting om protokollversionens golv. Gå igenom kontrollerna nedan i ordning och stanna vid den första som inte håller, eftersom varje senare kontroll förutsätter att de tidigare är avklarade.

Kontrollera bygget innan du läser någon lista

Ett konfigurationsdirektiv kan inte lägga till protokollstöd i en binärfil som saknar det. Börja med versionsbannern, som namnger det kompilerade kryptobiblioteket:

openvpn --version

Ett 2.6-bygge länkat mot OpenSSL accepterar både tls-cipher och tls-ciphersuites. Ett bygge mot mbed TLS har inget val av TLS 1.3-sviter alls, och 2.6-handboken markerar tls-ciphersuites som ett OpenSSL-alternativ. Om servern byggs om med en annan backend kan samma profil ändra beteende utan att en enda konfigurationsrad ändras.

Medan du är här, kör openvpn --show-tls och spara utdata. Det är inventariet du senare ska jämföra mot, och det är billigt att fånga det innan någon börjar redigera profiler.

Skriv in bannern och listan i ändringsärendet, inte i ett chattfönster. När två personer grälar om en klient kan erbjuda en svit om sex veckor avgör de fångade utdata det på en rad.

Håll versionsgränser åtskilda från sifferlistor

I 2.6-handboken är dessa tre kontroller, inte en:

• tls-cipher sätter sifferpolicyn för TLS 1.2 och äldre, och skickas vidare till OpenSSL:s sifferlista;
• tls-ciphersuites väljer TLS 1.3-sviter;
• tls-version-min och tls-version-max begränsar de protokollversioner som anslutningen får använda.

En noggrant trimmad lista över TLS 1.3-sviter bevisar alltså ingenting om att en äldre version fortfarande är tillåten. Om kravet är «endast TLS 1.3» är det versionsgolvet som bär det, och svitlistan snävar bara in valen inom det golvet:

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

Det paret gör två jobb. Tar man bort en av raderna genomdriver den andra mindre än du tror, och det är just det felet hela den här kontrollen finns för att fånga.

Datakanalen är en fjärde kontroll. data-ciphers förhandlar den symmetriska siffern inne i tunneln, och resultatet säger ingenting om kontrollkanalens TLS-version. Att se AES-256-GCM i sessionssammanfattningen är inte bevis för TLS 1.3 i någon riktning.

Läs show-tls som ett lokalt inventarium

--show-tls listar de sviter som kryptobiblioteket den här binärfilen är länkad mot stöder, i preferensordning. Det är inte en rapport från gatewayen. Handboken säger uttryckligen att listan kommer från det lokala biblioteket, vilket betyder att en bärbar dator med OpenSSL 3.x och en router med äldre bygge skriver ut olika listor medan de talar med samma server.

Anta att en klient stöder sviterna A, B och C och att en session väljer B. Det fastställer ingenting om huruvida servern tillåter A eller C, och ingenting om huruvida B är dess enda tillåtna val. Håll de tre raderna åtskilda, och de flesta förvirrande TLS-trådar löser sig själva.

Inventariet är ändå värt att behålla. När en session misslyckas visar jämförelsen av bibliotekets lista med profilens lista om klienten överhuvudtaget hade en chans att erbjuda det servern ville ha. Den visar också om en backend-ändring tyst har tagit bort TLS_CHACHA20_POLY1305_SHA256 från poolen som äldre klienter är beroende av — den typ av regression som visar sig som en handfull användare som inte kan ansluta medan alla andra inte märker något.

Fråga gatewayen om något den kan svara på

Om du administrerar tjänsten, inspektera den körande instansens effektiva konfiguration i stället för en fil på disken. OpenVPN kan ha startats med en annan --config-sökväg, kan hämta inkluderingar och är kanske inte omstartat sedan ändringen. Det är den körande daemonens policy som klienterna möter.

Om du inte administrerar den, be operatören om stödda klientkrav eller ett avgränsat acceptanstest. Ett avvisat försök är inte automatiskt en avvisad svit: ett versionsgolv, certifikatidentitetskontroller som remote-cert-tls, eller en missanpassning mellan tls-auth och tls-crypt kan avsluta utbytet innan svitvalet blir relevant. Läs serverns fel innan du ändrar klientens lista, eftersom «handshake failed» täcker fyra olika orsaker och bara en av dem är en siffermissanpassning.

Att peka openssl s_client mot VPN-porten återskapar inte heller frågan. Kontrollkanalen körs inne i OpenVPN:s egen inramning, så en rå TLS-probe testar en annan protokoll på en port som förväntar sig något annat. Varje slutsats därifrån handlar om proben, inte om tunneln.

Registrera två resultat och håll dem åtskilda

En färsk tillåten session producerar en kontrollkanalrad som namnger protokollversionen och den valda siffern, och en separat datakanalrad som namnger tunnelns siffer. Fånga båda med klientversionen och profilnamnet, och notera vilken serverinstans som svarade:

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

Läs sedan de två raderna från den filen i stället för från minnet. Paret är beviset; ett svitnamn ensamt är en preferens, och versionsgränsen är ett separat påstående om vad servern avvisar.

Utför kontrollerna i den här ordningen. Bekräfta bygget och backend med --version. Fånga --show-tls innan du ändrar något. Ange det krävda versionsgolvet separat från svitlistan. Bekräfta den körande instansens effektiva policy med dess ägare. Observera en tillåten session och, om planen tillåter, ett avvisat försök med en äldre version. Registrera resultaten för kontrollkanalen och datakanalen som separata fynd.

Om en krävd klient inte kan uppfylla ett nytt minimum, fatta det migrerings- eller undantagsbeslutet uttryckligen i stället för att tyst sänka en orelaterad acceptansregel så att utrullningen ser klar ut.