Éin gamal peer tvingar TLS 1.0: avgrens unntaket, ikkje verten
Éi eining som sit fast på TLS 1.0, eller eit gamalt leverandørsertifikat, kan tvinge fram ein svakare terskel. Avgrens unntaket, og mål deretter kva som faktisk vart forhandla.
Éi gamal eining dukkar opp, får ikkje kopla til, og den raskaste reparasjonen ser ut til å vere å svekke heile verten til tilkoplinga lukkast. Den byttehandelen er usynleg i augneblinken og permanent i praksis, fordi ingen fjernar ein terskel som endeleg verkar. To svært ulike feil skapar presset, og berre éin av dei handlar om chiffer i det heile. Sorter feilen fyrst, og set deretter unntaket ein stad der det ikkje kan spreie seg.
Del feilen i to før du endrar ein direktiv
Ei serverloggline om ingen felles chiffer, eller om ein protokollversjon som ikkje er støtta, kjem frå kontrollkanalen: dei to endane klarte ikkje å bli samde om korleis dei skulle verne sjølve forhandlinga. Ei klientline som seier at ingen metode for å verifisere server sertifikatet er slått på, kjem frå ein heilt annan stad, fordi den klienten ikkje sjekkar kven som svara i det heile. Å endre ein datachiffer hjelper ikkje for det andre tilfellet, og å leggje til ein rollekontroll hjelper ikkje for det første.
Tak den tidlegaste feilande lina frå kvar side i staden for den siste lina før fråkoplinga, sidan den siste vanlegvis er ei følgje. Finn deretter ut kva fil klienten faktisk opna: ein importert profil finst ofte to gonger under ulike visingsnamn, og å redigere kopien ingen les gir ei overtydande inga endring. Ein køyrande prosess held på innstillingane han starta med, så ei lagra fil er ikkje ei lasta fil. Kommandoane nedanfor viser forhandlinga til klienten ved sida av synet til serveren på det same forsøket.
openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'
Ein andre lyttar er den ærlege staden for ein svakare terskel
Når eininga stoppar på TLS 1.0 med ein datakanal før 2.5, må serveren tilby ein lågare terskel for kontrollkanalen og ein datachiffer den gamle klienten kjenner att. Fallback-direktivet finst nettopp for den peeren, medan chifferlista held moderne klientar på moderne suitar. Begge direktiva høyrer til lyttaren og ikkje til ein brukar eller ei tilkopling, og ingen per-klient-opsjon snevrar dei inn etterpå. Difor er éi eldre eining på hovudporten ei avgjerd om kvar peer som deler den porten.
Der plattforma tillèt det, køyr den eldre lyttaren som si eiga instans på ein eigen port, tillat den porten berre frå adressa til eininga, og lat hovudtenesta vere i fred. Skriv ned kvifor den andre lyttaren finst, i fila som ber konfigurasjonen hans, for elles vil ein framtidig opprydding lese han som restar. Splittinga er berre verdt noko om den svakare terskelen sluttar der eininga sluttar.
tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC
Kva eit gamalt leverandørsertifikat faktisk øydelegg
Verifiseringsfeilen er ei manglande rollebinding: utan henne godtek klienten eitkvart sertifikat som er kjeda til ein klarert CA, anten det vart gitt ut for ein server eller ikkje. Bind sertifikatet til serverrolla fyrst, og handsam bindinga som eit krav i staden for ein justeringsknapp. Berre ein profil som framleis feilar etter det steget, har eit ekte sertifikatproblem.
Eit gamalt leverandørsertifikat der nøkkelstorleiken eller signaturalgoritmen ikkje lenger oppfyller standard OpenSSL-policy, er tilfellet for ei avgrensa endring av sikkerheitsnivået på kontrollkanalen. Å senke nivået der slår ikkje av verifiseringa, og det må aldri kombinerast med ein tom CA, ei deaktivert verifisering eller eit ukontrollert vertsnamn. Hald lina inne i den eine profilen som treng henne; å eksportere ein slappa OpenSSL-konfigurasjon globalt ville gjeve same lempe til kvart program på maskina.
remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"
Les dei forhandla verdiane, ikkje banneret
Ved verbosity 4 skriv båe endar ut TLS-versjonen og chifferet for kontrollkanalen som dei vart samde om, og datachifferet for økta. Les dei linene i staden for initialiseringsbanneret, som rapporterer suksess og ikkje vilkåra for han. Kopla deretter ein moderne klient til hovudlyttaren igjen og stadfest at han framleis landar på ein moderne suite, fordi eit unntak som har leka inn i felles konfigurasjon, viser seg her fyrst. Verdiane du kopierer ut, blir grunnlaget for neste gjennomgang.
Test den gamle eininga åleine: ho skal kopla til, og ho skal vere den einaste økta i loggane som viser dei svakare parametrane. Viss ein andre peer også forhandlar den gamle suiten, er unntaket breiare enn tenkt, og lyttardelinga skjedde eigentleg ikkje. Registrer båe observasjonane og ikkje berre konklusjonen.
Kvart unntak treng ein eigar og ein dato
Eit unntak utan fjernevilkår blir stille standarden, så set eininga, eigaren, årsaka og datoen ho forsvinn ved sida av konfigurasjonen ho rettferdiggjer. Utan den lina overlever den svakare terskelen maskinvara som trengde han.
Å bytte ut klienten, eller å be leverandøren om ein gjeldande profil, er resultatet du bør sikte mot; unntaket er ei utsetjing og ikkje eit design. Når eininga blir pensjonert, fjern lyttaren og profilen i same endring, slik at ingen halvdel held fram med å køyre. Ingenting av dette gjer dei gamle parametrane trygge, det hindrar berre at grensa til éi eining blir grunnlaget for alle.