En gammal peer tvingar fram TLS 1.0: begränsa undantaget, inte värden

En gammal enhet dyker upp, kan inte ansluta, och den snabbaste synbara reparationen är att försvaga hela värden tills anslutningen lyckas. Den affären är osynlig i stunden och permanent i praktiken, eftersom ingen tar bort en undre gräns som äntligen fungerar. Trycket skapas av två helt olika fel, och bara ett av dem handlar om chiffer överhuvudtaget. Sortera felet först och placera sedan undantaget där det inte kan sprida sig.

Dela felet i två innan du ändrar ett direktiv

En serverloggrada om ingen gemensam chiffer, eller om en protokollversion som inte stöds, kommer från kontrollkanalen: de två ändarna kunde inte enas om hur de skulle skydda själva förhandlingen. En klientrad som säger att ingen metod för att verifiera servercertifikatet är aktiverad kommer från en helt annan plats, eftersom den klienten inte ens kontrollerar vem som svarade. Att byta en datachiffer gör inget för det andra fallet, och att lägga till en rollkontroll gör inget för det första.

Ta den tidigaste felande raden från varje sida i stället för den sista före frånkopplingen, eftersom den sista oftast är en följd. Fastställ sedan vilken fil klienten verkligen öppnade: en importerad profil finns ofta två gånger under olika visningsnamn, och att redigera kopian som ingen läser ger en övertygande ingen ändring. En körande process behåller inställningarna den startade med, så en sparad fil är inte en laddad fil. Kommandona nedan visar klientens förhandling bredvid serverns syn på samma försök.

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

En andra lyssnare är den ärliga platsen för en svagare undre gräns

När enheten stannar på TLS 1.0 med en datakanal före 2.5 måste servern erbjuda en lägre undre gräns för kontrollkanalen och en datachiffer som den gamla klienten känner igen. Fallback-direktivet finns just för den peeren, medan chifferlistan håller moderna klienter på moderna sviter. Båda direktiven tillhör lyssnaren och inte en användare eller anslutning, och ingen inställning per klient snävar in dem efteråt. Därför är en enda äldre enhet på huvudporten ett beslut om varje peer som delar den porten.

Där plattformen tillåter det, kör den äldre lyssnaren som en egen instans på en separat port, tillåt den porten bara från enhetens adress och låt huvudtjänsten vara i fred. Skriv ned varför den andra lyssnaren finns, i filen som bär dess konfiguration, annars läser en framtida städning den som rester. Uppdelningen är bara värd något om den svagare undre gränsen slutar där enheten slutar.

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

Vad ett gammalt leverantörscertifikat faktiskt bryter sönder

Verifieringsfelet är en saknad rollbindning: utan den accepterar klienten vilket certifikat som helst som kedjar till en betrodd CA, oavsett om det utfärdades för en server eller inte. Bind certifikatet till serverrollen först och behandla bindningen som ett krav i stället för en justeringsknapp. Bara en profil som fortfarande misslyckas efter det steget har ett verkligt certifikatproblem.

Ett gammalt leverantörscertifikat vars nyckelstorlek eller signaturalgoritm inte längre uppfyller OpenSSL:s standardpolicy är fallet för en avgränsad ändring av säkerhetsnivån på kontrollkanalen. Att sänka nivån där stänger inte av verifieringen, och det får aldrig kombineras med en tom CA, en inaktiverad verifiering eller ett okontrollerat värdnamn. Håll raden inne i den enda profil som behöver den; att exportera en uppmjukad OpenSSL-konfiguration globalt skulle ge samma uppmjukning till varje program på maskinen.

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

Läs de förhandlade värdena, inte bannern

Vid verbosity 4 skriver båda ändarna ut den TLS-version och chiffer för kontrollkanalen som de enades om, och datachiffern för sessionen. Läs de raderna i stället för initieringsbannern, som rapporterar framgång och inte villkoren för den. Anslut sedan en modern klient till huvudlyssnaren igen och bekräfta att den fortfarande landar på en modern svit, eftersom ett undantag som läckt in i den delade konfigurationen syns här först. Värdena du kopierar ut blir basen för nästa granskning.

Testa den gamla enheten ensam: den ska ansluta, och den ska vara den enda sessionen i loggarna som visar de svagare parametrarna. Om en andra peer också förhandlar den gamla sviten är undantaget bredare än avsett, och lyssnaruppdelningen skedde egentligen inte. Registrera båda observationerna och inte bara slutsatsen.

Varje undantag behöver en ägare och ett datum

Ett undantag utan borttagningsvillkor blir tyst standarden, så sätt enheten, ägaren, orsaken och datumet då det försvinner bredvid konfigurationen det rättfärdigar. Utan den raden överlever den svagare undre gränsen den hårdvara som behövde den.

Att byta ut klienten, eller be leverantören om en aktuell profil, är resultatet man ska sträva efter; undantaget är ett uppskov och inte en design. När enheten pensioneras, ta bort lyssnaren och profilen i samma ändring så att ingen halva fortsätter att köra. Inget av detta gör de gamla parametrarna säkra, det hindrar bara att gränsen för en enhet blir allas bas.