OpenVPN tls-ciphersuites versus tls-version-min: wat elk afdwingt

Drie verschillende feiten worden in de meeste OpenVPN-TLS-discussies tot één regel samengevat: wat je clientbuild kan, wat het profiel toestaat en wat de sessie werkelijk heeft onderhandeld. Een korte TLS 1.3-suitelijst beantwoordt alleen de middelste vraag half, en zegt niets over de ondergrens van de protocolversie. Doorloop de onderstaande controles in volgorde en stop bij de eerste die niet standhoudt, want elke latere controle veronderstelt dat de eerdere zijn afgehandeld.

Controleer de build voordat je een lijst leest

Een configuratierichtlijn kan geen protocolondersteuning toevoegen aan een binary die die niet heeft. Begin met de versiebanner, die de gecompileerde cryptobibliotheek noemt:

openvpn --version

Een 2.6-build die aan OpenSSL is gelinkt, accepteert zowel tls-cipher als tls-ciphersuites. Een build met mbed TLS heeft helemaal geen TLS 1.3-suitekeuze, en de 2.6-handleiding markeert tls-ciphersuites als een OpenSSL-optie. Als de server met een andere backend opnieuw wordt gebouwd, kan hetzelfde profiel zijn gedrag veranderen zonder dat één regel configuratie verandert.

Terwijl je hier bent, voer openvpn --show-tls uit en bewaar de uitvoer. Het is de inventaris waarmee je later vergelijkt, en het is goedkoop om die vast te leggen voordat iemand profielen begint te bewerken.

Schrijf de banner en de lijst in de wijzigingsticket, niet in een chatvenster. Wanneer twee mensen discussiëren of een client over zes weken een suite kan aanbieden, beslist de vastgelegde uitvoer dat in één regel.

Houd versiegrenzen gescheiden van cijferlijsten

In de 2.6-handleiding zijn dit drie controles, niet één:

• tls-cipher stelt het cijferbeleid in voor TLS 1.2 en ouder, en wordt doorgegeven aan OpenSSL's cijferlijst;
• tls-ciphersuites selecteert TLS 1.3-suites;
• tls-version-min en tls-version-max begrenzen de protocolversies die de verbinding mag gebruiken.

Een zorgvuldig bijgesneden TLS 1.3-suitelijst bewijst dus niets over het feit dat een oudere versie nog is toegestaan. Als de eis «alleen TLS 1.3» is, draagt de versieondergrens die, en de suitelijst vernauwt alleen de keuzes binnen die ondergrens:

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

Dat paar doet twee taken. Een van de regels verwijderen laat de andere minder afdwingen dan je denkt, en dat is precies de fout waarvoor deze hele controle bestaat.

Het datakanaal is een vierde controle. data-ciphers onderhandelt het symmetrische cijfer binnen de tunnel, en het resultaat zegt niets over de TLS-versie van het controlekanaal. AES-256-GCM in het sessieoverzicht zien is in geen enkele richting bewijs voor TLS 1.3.

Lees show-tls als een lokale inventaris

--show-tls somt de suites op die de cryptobibliotheek waaraan deze binary is gelinkt ondersteunt, in voorkeursvolgorde. Het is geen rapport van de gateway. De handleiding zegt uitdrukkelijk dat de lijst uit de lokale bibliotheek komt, wat betekent dat een laptop met OpenSSL 3.x en een router met een oudere build verschillende lijsten afdrukken terwijl ze met dezelfde server praten.

Stel dat een client de suites A, B en C ondersteunt en één sessie B kiest. Dat stelt niets vast over de vraag of de server A of C toestaat, en ook niet of B de enige toegestane keuze is. Houd de drie regels gescheiden, en de meeste verwarrende TLS-discussies lossen zichzelf op.

De inventaris is het toch waard om te bewaren. Wanneer een sessie mislukt, laat het vergelijken van de bibliotheeklijst met de profiellijst zien of de client enige kans had om aan te bieden wat de server wilde. Het laat ook zien of een backendwijziging stilletjes TLS_CHACHA20_POLY1305_SHA256 uit de pool heeft verwijderd waarop oudere clients vertrouwen — het soort regressie dat zich uit als een handvol gebruikers dat geen verbinding krijgt terwijl iedereen niets merkt.

Vraag de gateway iets wat die kan beantwoorden

Als je de dienst beheert, inspecteer dan de effectieve configuratie van de draaiende instantie in plaats van een bestand op schijf. OpenVPN is misschien gestart met een ander --config-pad, haalt includes op en is mogelijk niet herstart sinds de bewerking. Het beleid van de draaiende daemon is wat clients tegenkomen.

Als je die niet beheert, vraag de operator dan om ondersteunde clientvereisten of een afgebakende acceptatietest. Een geweigerde poging is niet automatisch een geweigerde suite: een versieondergrens, certificaat-identiteitscontroles zoals remote-cert-tls, of een mismatch tussen tls-auth en tls-crypt kunnen de uitwisseling beëindigen voordat de suitekeuze ertoe doet. Lees de fout van de server voordat je de lijst van de client wijzigt, want «handshake failed» dekt vier verschillende oorzaken en slechts één daarvan is een cijfermismatch.

Het richten van openssl s_client op de VPN-poort reproduceert de vraag ook niet. Het controlekanaal loopt binnen OpenVPN's eigen framing, dus een ruwe TLS-probe test een ander protocol op een poort die iets anders verwacht. Elke conclusie daaruit gaat over de probe, niet over de tunnel.

Registreer twee resultaten en houd ze gescheiden

Een nieuwe toegestane sessie levert een controlekanaalregel op met de protocolversie en het gekozen cijfer, en een aparte datakanaalregel met het tunnelcijfer. Leg beide vast met de clientversie en de profielnaam, en noteer welke serverinstantie heeft geantwoord:

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

Lees daarna de twee regels uit dat bestand in plaats van uit je geheugen. Het paar is het bewijs; een suitenaam alleen is een voorkeur, en de versiegrens is een aparte uitspraak over wat de server weigert.

Voer de controles in deze volgorde uit. Bevestig de build en de backend met --version. Leg --show-tls vast voordat je iets wijzigt. Noem de vereiste versieondergrens apart van de suitelijst. Bevestig het effectieve beleid van de draaiende instantie met de eigenaar. Observeer één toegestane sessie en, als het plan dat toestaat, één geweigerde poging met een oudere versie. Registreer de resultaten van het controlekanaal en het datakanaal als afzonderlijke bevindingen.

Als een vereiste client een nieuw minimum niet kan halen, neem die migratie- of uitzonderingsbeslissing dan expliciet in plaats van stilletjes een ongerelateerde acceptatieregel te verlagen zodat de uitrol af lijkt.