Én gammel peer tvinger TLS 1.0: afgræns undtagelsen, ikke værten

Én gammel enhed dukker op, kan ikke forbinde, og den hurtigste tilsyneladende reparation er at svække hele værten, indtil forbindelsen lykkes. Den handel er usynlig i øjeblikket og permanent i praksis, fordi ingen fjerner et minimum, der endelig virker. To meget forskellige fejl skaber presset, og kun den ene handler overhovedet om chiffrer. Sortér fejlen først, og anbring derefter undtagelsen et sted, hvor den ikke kan sprede sig.

Del fejlen i to, før du redigerer en direktiv

En linje i serverloggen om ingen fælles chiffre eller om en ikke-understøttet protokolversion kommer fra kontrolkanalen: de to ender kunne ikke blive enige om, hvordan selve forhandlingen skulle beskyttes. En klientlinje om, at ingen verifikationsmetode for servercertifikater er aktiveret, kommer fra et helt andet sted, fordi den klient slet ikke kontrollerer, hvem der svarede. At ændre en datachiffre gør intet i det andet tilfælde, og at tilføje et rolletjek gør intet i det første.

Tag den tidligste fejlende linje fra hver side i stedet for den sidste linje før afbrydelsen, fordi den sidste normalt er en konsekvens. Fastslå derefter, hvilken fil klienten faktisk åbnede: en importeret profil findes ofte to gange under forskellige visningsnavne, og at redigere den kopi, ingen læser, giver en overbevisende ikke-ændring. En kørende proces beholder de indstillinger, den startede med, så en gemt fil er ikke en indlæst fil. Kommandoerne nedenfor viser klientens forhandling ved siden af serverens syn på samme forsøg.

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

En anden listener er det ærlige sted for et svagere minimum

Når enheden topper ved TLS 1.0 med en datakanal fra før 2.5, skal serveren tilbyde et lavere minimum for kontrolkanalen og en datachiffre, som den gamle klient genkender. Fallback-direktivet findes netop til den peer, mens chiffrelisten holder moderne klienter på moderne suiter. Begge direktiver hører til listeneren og ikke til en bruger eller en forbindelse, og ingen indstilling for den enkelte klient indsnævrer dem bagefter. Derfor er én gammel enhed på hovedporten en beslutning om enhver peer, der deler den.

Hvor platformen tillader det, kør den gamle listener som sin egen instans på en separat port, tillad den port kun fra enhedens adresse, og lad hovedtjenesten være i fred. Skriv ned, hvorfor den anden listener findes, i den fil, der bærer dens konfiguration, fordi en fremtidig oprydning ellers vil læse det som efterladenskaber. Opdelingen er kun værd at have, hvis det svagere minimum slutter, hvor enheden slutter.

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

Hvad et gammelt udbydercertifikat egentlig ødelægger

Verifikationsfejlen er en manglende rollebinding: uden den accepterer klienten ethvert certifikat, der kæder til en betroet CA, uanset om certifikatet blev udstedt til en server. Bind certifikatet til serverrollen først, og behandl bindingen som et krav i stedet for en justeringsknap. Kun en profil, der stadig fejler efter det trin, har et egentligt certifikatproblem.

Et gammelt udbydercertifikat, hvis nøglestørrelse eller signaturalgoritme ikke længere opfylder standardpolitikken i OpenSSL, er tilfældet for en afgrænset ændring af sikkerhedsniveauet på kontrolkanalen. At sænke niveauet der slår ikke verifikationen fra, og det må aldrig kombineres med en tom CA, en deaktiveret verifikationsindstilling eller et ukontrolleret værtsnavn. Hold linjen inde i den ene profil, der har brug for den; at eksportere en lempet OpenSSL-konfiguration globalt ville give samme lempelse til hvert program på maskinen.

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

Læs de forhandlede værdier, ikke banneret

Ved detaljeringsgrad 4 udskriver begge ender den TLS-version og chiffre for kontrolkanalen, som de blev enige om, og datachiffren for sessionen. Læs de linjer i stedet for initialiseringsbanneret, som rapporterer succes og ikke vilkårene for den. Forbind derefter en moderne klient til hovedlisteneren igen, og bekræft, at den stadig lander på en moderne suite, fordi en undtagelse, der er lækket ind i fælles konfiguration, viser sig her først. De værdier, du kopierer ud, bliver baseline for næste gennemgang.

Test den gamle enhed alene: den skal kunne forbinde, og den skal være den eneste session i loggene, der viser de svagere parametre. Hvis en anden peer også forhandler den gamle suite, er undtagelsen bredere end tilsigtet, og listener-opdelingen skete ikke rigtigt. Notér begge observationer i stedet for kun konklusionen.

Hver undtagelse kræver en ejer og en dato

En undtagelse uden fjernelsesbetingelse bliver stille standarden, så anbring enheden, ejeren, årsagen og datoen, hvor den forsvinder, ved siden af den konfiguration, den retfærdiggør. Uden den linje overlever det svagere minimum det hardware, der havde brug for det.

At udskifte klienten eller bede udbyderen om en aktuel profil er det resultat, der er værd at sigte efter; undtagelsen er en udsættelse og ikke et design. Når enheden pensioneres, fjern listeneren og profilen i samme ændring, så ingen af halvdelene bliver kørende. Intet af dette gør de gamle parametre sikre, det forhindrer blot, at én enheds grænse bliver alles baseline.