Én gammel peer tvinger TLS 1.0: avgrens unntaket, ikke verten

Én gammel enhet dukker opp, får ikke koblet til, og den raskeste reparasjonen ser ut til å være å svekke hele verten til tilkoblingen lykkes. Den byttehandelen er usynlig i øyeblikket og permanent i praksis, fordi ingen fjerner en terskel som endelig virker. To svært forskjellige feil skaper presset, og bare én av dem handler om chiffer i det hele tatt. Sorter feilen først, og sett deretter unntaket et sted der det ikke kan spre seg.

Del feilen i to før du endrer en direktiv

En serverlogglinje om ingen felles chiffer, eller om en protokollversjon som ikke støttes, kommer fra kontrollkanalen: de to endene klarte ikke å bli enige om hvordan de skulle beskytte selve forhandlingen. En klientlinje som sier at ingen metode for å verifisere server sertifikatet er aktivert, kommer fra et helt annet sted, fordi den klienten ikke sjekker hvem som svarte i det hele tatt. Å endre en datachiffer hjelper ikke for det andre tilfellet, og å legge til en rollekontroll hjelper ikke for det første.

Ta den tidligste feilende linjen fra hver side i stedet for den siste linjen før frakoblingen, siden den siste vanligvis er en konsekvens. Finn deretter ut hvilken fil klienten faktisk åpnet: en importert profil finnes ofte to ganger under forskjellige visningsnavn, og å redigere kopien ingen leser gir en overbevisende ingen endring. En kjørende prosess beholder innstillingene den startet med, så en lagret fil er ikke en lastet fil. Kommandoene nedenfor viser klientens forhandling ved siden av serverens syn på det samme 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'

En andre lytter er det ærlige stedet for en svakere terskel

Når enheten stopper på TLS 1.0 med en datakanal før 2.5, må serveren tilby en lavere terskel for kontrollkanalen og en datachiffer den gamle klienten kjenner igjen. Fallback-direktivet finnes nettopp for den peeren, mens chifferlisten holder moderne klienter på moderne suiter. Begge direktivene tilhører lytteren og ikke en bruker eller en tilkobling, og ingen per-klient-opsjon innsnevrer dem etterpå. Derfor er én eldre enhet på hovedporten en avgjørelse om hver peer som deler den porten.

Der plattformen tillater det, kjør den eldre lytteren som sin egen instans på en egen port, tillat den porten bare fra enhetens adresse, og la hovedtjenesten være i fred. Skriv ned hvorfor den andre lytteren finnes, i filen som bærer konfigurasjonen dens, for ellers vil en fremtidig opprydding lese den som rester. Splittelsen er bare verdt noe hvis den svakere terskelen slutter der enheten slutter.

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

Hva et gammelt leverandørsertifikat faktisk ødelegger

Verifiseringsfeilen er en manglende rollebinding: uten den godtar klienten ethvert sertifikat som kjedet til en klarert CA, enten det ble utstedt for en server eller ikke. Bind sertifikatet til serverrollen først, og behandle bindingen som et krav i stedet for en justeringsknapp. Bare en profil som fortsatt feiler etter det trinnet, har et ekte sertifikatproblem.

Et gammelt leverandørsertifikat der nøkkelstørrelsen eller signaturalgoritmen ikke lenger oppfyller standard OpenSSL-policy, er tilfellet for en avgrenset endring av sikkerhetsnivået på kontrollkanalen. Å senke nivået der slår ikke av verifiseringen, og det må aldri kombineres med en tom CA, en deaktivert verifisering eller et ukontrollert vertsnavn. Hold linjen inne i den ene profilen som trenger den; å eksportere en slappet OpenSSL-konfigurasjon globalt ville gi samme lemping til hvert program på maskinen.

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

Les de forhandlede verdiene, ikke banneret

Ved verbosity 4 skriver begge ender ut TLS-versjonen og chifferen for kontrollkanalen som de ble enige om, og datachifferen for økten. Les de linjene i stedet for initialiseringsbanneret, som rapporterer suksess og ikke vilkårene for den. Koble deretter en moderne klient til hovedlytteren igjen og bekreft at den fortsatt lander på en moderne suite, fordi et unntak som har lekket inn i felles konfigurasjon, vises her først. Verdiene du kopierer ut, blir grunnlaget for neste gjennomgang.

Test den gamle enheten alene: den skal koble til, og den skal være den eneste økten i loggene som viser de svakere parameterne. Hvis en andre peer også forhandler den gamle suiten, er unntaket bredere enn tiltenkt, og lytterdelingen skjedde egentlig ikke. Registrer begge observasjonene og ikke bare konklusjonen.

Hvert unntak trenger en eier og en dato

Et unntak uten fjerningsvilkår blir stille standarden, så sett enheten, eieren, årsaken og datoen den forsvinner ved siden av konfigurasjonen den rettferdiggjør. Uten den linjen overlever den svakere terskelen maskinvaren som trengte den.

Å bytte ut klienten, eller å be leverandøren om en gjeldende profil, er resultatet du bør sikte mot; unntaket er en utsettelse og ikke et design. Når enheten pensjoneres, fjern lytteren og profilen i samme endring, slik at ingen halvdel fortsetter å kjøre. Ingenting av dette gjør de gamle parameterne trygge, det hindrer bare at grensen til én enhet blir alles grunnlag.