Eén oude peer dwingt TLS 1.0 af: beperk de uitzondering, niet de host

Eén oud apparaat duikt op, kan geen verbinding maken, en de snelst lijkende reparatie is de hele host verzwakken tot de verbinding lukt. Die ruil is op het moment onzichtbaar en in de praktijk permanent, omdat niemand een ondergrens weghaalt die eindelijk werkt. Twee heel verschillende fouten veroorzaken de druk, en slechts één ervan gaat überhaupt over cijfers. Sorteer eerst de fout en zet de uitzondering daarna ergens waar ze zich niet kan verspreiden.

Splits de fout in tweeën voordat je een richtlijn aanpast

Een serverlogregel over geen gedeelde cipher, of over een niet-ondersteunde protocolversie, komt van het controlekanaal: beide uiteinden konden het niet eens worden over hoe ze de onderhandeling zelf beschermen. Een clientregel dat er geen methode voor verificatie van het servercertificaat is ingeschakeld, komt ergens heel anders vandaan, want die client controleert helemaal niet wie er antwoordde. Een datacipher wijzigen helpt niet voor het tweede geval, en een rolcontrole toevoegen helpt niet voor het eerste.

Neem de vroegste falende regel van elke kant in plaats van de laatste regel voor de onderbreking, want de laatste is meestal een gevolg. Stel daarna vast welk bestand de client werkelijk heeft geopend: een geïmporteerd profiel bestaat vaak twee keer onder verschillende weergavenamen, en de kopie bewerken die niemand leest levert een overtuigende niet-wijziging op. Een draaiend proces houdt de instellingen waarmee het begon, dus een opgeslagen bestand is geen geladen bestand. De opdrachten hieronder tonen de onderhandeling van de client naast de kijk van de server op dezelfde poging.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Een tweede listener is de eerlijke plek voor een zwakkere ondergrens

Wanneer het apparaat stopt bij TLS 1.0 met een datakanaal van vóór 2.5, moet de server een lagere ondergrens voor het controlekanaal en een datacipher aanbieden die de oude client herkent. De fallback-richtlijn bestaat precies voor die peer, terwijl de cipherlijst moderne clients op moderne suites houdt. Beide richtlijnen horen bij de listener en niet bij een gebruiker of verbinding, en geen optie per client vernauwt ze achteraf. Daarom is één legacy-apparaat op de hoofdpoort een beslissing over elke peer die die poort deelt.

Waar het platform het toestaat, draai de legacy-listener als eigen instantie op een aparte poort, sta die poort alleen toe vanaf het adres van het apparaat, en laat de hoofddienst met rust. Schrijf op waarom de tweede listener bestaat, in het bestand dat zijn configuratie bevat, want anders leest een toekomstige opruiming hem als achtergebleven rommel. De splitsing is alleen de moeite waard als de zwakkere ondergrens eindigt waar het apparaat eindigt.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Wat een oud providercertificaat werkelijk breekt

De verificatiefout is een ontbrekende rolkoppeling: zonder die koppeling accepteert de client elk certificaat dat naar een vertrouwde CA leidt, of dat certificaat nu voor een server is uitgegeven of niet. Koppel het certificaat eerst aan de serverrol en behandel de koppeling als een vereiste en niet als een afstelknop. Alleen een profiel dat na die stap nog steeds faalt, heeft een echt certificaatprobleem.

Een oud providercertificaat waarvan de sleutelgrootte of het handtekeningalgoritme niet langer aan het standaardbeleid van OpenSSL voldoet, is het geval voor een beperkte wijziging van het beveiligingsniveau op het controlekanaal. Het niveau daar verlagen schakelt de verificatie niet uit, en het mag nooit worden gecombineerd met een lege CA, een uitgeschakelde verificatie of een ongecontroleerde hostnaam. Houd de regel binnen het ene profiel dat hem nodig heeft; een versoepelde OpenSSL-configuratie wereldwijd exporteren zou dezelfde versoepeling aan elk programma op de machine geven.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Lees de onderhandelde waarden, niet de banner

Bij verbosity 4 printen beide uiteinden de TLS-versie en cipher van het controlekanaal waarop ze het eens werden, en het datacipher voor de sessie. Lees die regels in plaats van de initialisatiebanner, die succes meldt en niet de voorwaarden ervan. Verbind daarna opnieuw een moderne client met de hoofdlistener en bevestig dat die nog steeds op een moderne suite uitkomt, want een uitzondering die in de gedeelde configuratie is gelekt, verschijnt hier als eerste. De waarden die je overneemt, worden de basis voor de volgende beoordeling.

Test het oude apparaat apart: het hoort te verbinden, en het hoort de enige sessie in de logs te zijn die de zwakkere parameters toont. Als een tweede peer ook de oude suite onderhandelt, is de uitzondering breder dan bedoeld en is de listener-splitsing niet echt gebeurd. Leg beide waarnemingen vast en niet alleen de conclusie.

Elke uitzondering heeft een eigenaar en een datum nodig

Een uitzondering zonder verwijderingsvoorwaarde wordt stil de standaard, dus zet het apparaat, de eigenaar, de reden en de datum waarop hij verdwijnt naast de configuratie die hij rechtvaardigt. Zonder die regel overleeft de zwakkere ondergrens de hardware die hem nodig had.

De client vervangen, of de provider om een actueel profiel vragen, is het resultaat dat je moet nastreven; de uitzondering is een uitstel en geen ontwerp. Wanneer het apparaat buiten dienst gaat, verwijder dan de listener en het profiel in dezelfde wijziging, zodat geen van beide helften blijft draaien. Niets hiervan maakt de oude parameters veilig, het voorkomt alleen dat de grens van één apparaat de basis van iedereen wordt.