Een ou eweknie dwing TLS 1.0 af: beperk die uitsondering, nie die gasheer nie

Een ou toestel duik op, kan nie verbind nie, en die vinnigste oënskynlike herstel is om die hele gasheer te verswak totdat die verbinding slaag. Daardie ruil is op die oomblik onsigbaar en in die praktyk permanent, want niemand verwyder 'n vloer wat uiteindelik werk nie. Twee baie verskillende foute skep die druk, en net een daarvan gaan enigsins oor sifers. Sorteer eers die fout en plaas dan die uitsondering op 'n plek waar dit nie kan versprei nie.

Deel die fout in twee voordat jy 'n voorskrif wysig

'n Reël in die bedienerlog oor geen gedeelde sifer nie, of oor 'n onondersteunde protokolweergawe, kom van die beheerkanaal: die twee kante kon nie ooreenkom oor hoe om die onderhandeling self te beskerm nie. 'n Kliëntreël wat sê dat geen metode vir bedienersertifikaatverifikasie geaktiveer is nie, kom van heeltemal elders, want daardie kliënt kyk glad nie wie geantwoord het nie. Om 'n datasyfer te verander maak niks vir die tweede geval nie, en om 'n rolkontrole by te voeg maak niks vir die eerste nie.

Neem die vroegste falende reël van elke kant eerder as die laaste reël voor die ontkoppeling, want die laaste een is gewoonlik 'n gevolg. Bepaal dan watter lêer die kliënt werklik oopgemaak het: 'n ingevoerde profiel bestaan dikwels twee keer onder verskillende vertoonname, en om die kopie te wysig wat niemand lees nie, lewer 'n oortuigende nie-verandering. 'n Lopende proses hou die instellings waarmee dit begin het, so 'n gestoorde lêer is nie 'n gelaaide lêer nie. Die opdragte hieronder wys die kliënt se onderhandeling langs die bediener se siening van dieselfde poging.

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

'n tweede luisteraar is die eerlike plek vir 'n swakker vloer

Wanneer die toestel by TLS 1.0 met 'n pre-2.5-datakanaal stop, moet die bediener 'n laer beheerkanaalvloer en 'n datasyfer bied wat die ou kliënt herken. Die terugvalvoorskrif bestaan juis vir daardie eweknie, terwyl die siferlys moderne kliënte op moderne pakkette hou. Beide voorskrifte hoort by die luisteraar eerder as by 'n gebruiker of 'n verbinding, en geen opsie per kliënt vernou dit daarna nie. Daarom is een ou toestel op die hoofpoort 'n besluit oor elke eweknie wat dit deel.

Waar die platform dit toelaat, laat die ou luisteraar as sy eie instansie op 'n aparte poort loop, laat daardie poort net vanaf die toestel se adres toe, en los die hoofdiens alleen. Skryf neer waarom die tweede luisteraar bestaan, in die lêer wat sy konfigurasie dra, want 'n toekomstige opruiming sal dit anders as oorblyfsels lees. Die splitsing is net die moeite werd as die swakker vloer eindig waar die toestel eindig.

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

Wat 'n ou verskaffersertifikaat werklik breek

Die verifikasiefout is 'n ontbrekende rolbinding: sonder dit sal die kliënt enige sertifikaat aanvaar wat aan 'n vertroude CA koppel, of daardie sertifikaat vir 'n bediener uitgereik is of nie. Bind die sertifikaat eers aan die bedienerrol, en behandel die binding as 'n vereiste eerder as 'n instellingsknoppie. Net 'n profiel wat ná daardie stap steeds misluk, het 'n werklike sertifikaatprobleem.

'n Ou verskaffersertifikaat waarvan die sleutelgrootte of ondertekeningsalgoritme nie meer aan die standaard OpenSSL-beleid voldoen nie, is die geval vir 'n beperkte verandering van die sekuriteitsvlak op die beheerkanaal. Om die vlak daar te verlaag skakel nie verifikasie af nie, en dit mag nooit gekombineer word met 'n leë CA, 'n gedeaktiveerde verifikasie-instelling of 'n ongetoetste gasheernaam nie. Hou die reël binne die een profiel wat dit nodig het; om 'n verslapte OpenSSL-konfigurasie globaal uit te voer, sou dieselfde verslapping aan elke program op die masjien gee.

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

Lees die onderhandelde waardes, nie die banier nie

By vlak 4 van breedsprakigheid druk beide kante die TLS-weergawe en sifer van die beheerkanaal waarop hulle ooreengekom het, en die datasyfer vir die sessie. Lees daardie reëls eerder as die initialiseringsbanier, wat sukses rapporteer en nie die voorwaardes daarvan nie. Verbind dan 'n moderne kliënt weer aan die hoof-luisteraar en bevestig dat dit steeds op 'n moderne pakket beland, want 'n uitsondering wat in gedeelde konfigurasie gelek het, wys hier eerste. Die waardes wat jy uittik, word die basislyn vir die volgende hersiening.

Toets die ou toestel op sy eie: dit behoort te verbind, en dit behoort die enigste sessie in die joernale te wees wat die swakker parameters wys. As 'n tweede eweknie ook die ou pakket onderhandel, is die uitsondering breër as bedoel en het die splitsing van die luisteraar nie regtig gebeur nie. Teken albei waarnemings aan eerder as net die gevolgtrekking.

Elke uitsondering het 'n eienaar en 'n datum nodig

'n Uitsondering sonder 'n verwyderingsvoorwaarde word stilweg die verstek, so plaas die toestel, die eienaar, die rede en die datum waarop dit verdwyn langs die konfigurasie wat dit regverdig. Sonder daardie reël oorleef die swakker vloer die hardeware wat dit nodig gehad het.

Om die kliënt te vervang, of om die verskaffer vir 'n huidige profiel te vra, is die uitkoms om na te streef; die uitsondering is 'n uitstel en nie 'n ontwerp nie. Wanneer die toestel aftree, verwyder die luisteraar en die profiel in dieselfde verandering sodat nie een helfte aan die loop bly nie. Niks hiervan maak die ou parameters veilig nie; dit keer net dat een toestel se beperking almal se basislyn word.