Ein handshake som endar i ein feil kjennest som eit åtak til ein ser på meldinga, og oftast er det aritmetikk: ingen felles tilbod, eit sertifikat som har gått ut, eller ei pakke som aldri kom fram. Eit downgrade-åtak er noko bestemt: ein motstandar som pressar begge endar mot veikare åtferd enn dei ville ha valt, og det etterlèt andre spor. Behandlar ein kvar feil som vondskap, leitar ein etter eit offer som kanskje ikkje finst, medan ein ved å behandla ein ekte downgrade som ein konfigurasjonsfeil lèt det veikare resultatet bli ståande. Dei to feila kostar ulikt, og berre éin av dei er billeg å retta.

Kva eit downgrade-åtak eigentleg endrar

Målet er ikkje å bryta chifferen og ikkje å gjeta ein nøkkel. Det er å påverka forhandlinga slik at begge sider landar på ein eldre versjon eller ein veikare algoritme som åtaksmannen kan handtera, eller å få den eine sida til å tru at den andre berre støttar det.

Det som endrar seg, er avtala, ikkje autentiseringa. Viss åtaksmannen kan endra tilbodet utan å bli oppdaga, kan partane framleis fullføra ein handshake og framleis autentisera kvarandre, med parameterar åtaksmannen føretrekkjer. Derfor er det interessante spørsmålet om sjølve forhandlinga er dekt av integritetsvern.

Kvifor sjølve forhandlinga må autentiserast

TLS 1.3 gjer det vernet eksplisitt. Ein klient som tilbaud den nyare versjonen, kan oppdaga ein tenar som stille fall tilbake, fordi den tilfeldige verdien til tenaren ber eit fast mønster når han forhandlar 1.2 eller lågare, og klienten må avbryta når han ser det. Heile transkriptet er òg dekt av dei avsluttande meldingane, så ei endring kvar som helst i forhandlinga feilar seinare i staden for å passera ubemerka.

Eldre protokollversjonar hadde veikare historier, og det er nettopp derfor fallback-reglane tel. Eit TLS 1.0-endepunkt i same konfigurasjon er ikkje eit downgrade-åtak; det er eit tillate utfall du sjølv valde å tillata. Skilnaden er om det veikare resultatet kom frå ei verna avgjerd eller frå ein uverna veg ein mellommann kunne påverka. Når ein formulerer det slik, blir dei fleste hendingar eit konfigurasjonsspørsmål.

IKEv2 oppfører seg annleis, men kviler på same idé. Tilbodet blir bore i ein utveksling som seinare autentiserer begge partar, så ein mellomliggande boks som skriv om algoritmane, bryt autentiseringa i staden for å styra henne. Kontrollkanalen til OpenVPN verner forhandlinga si med TLS og brukar deretter kanalen til å bli samde om chiffera til datakanalen, og derfor er logglinja for kontrollkanalen den interessante.

Konfigurert kompatibilitet er ikkje eit åtak

Ein administrator kan med vilje tillata eldre val for å støtta ein dokumentert klient, og den avgjerda er synleg i konfigurasjonen. Ein åtaksmann kan ikkje laga den konfigurasjonen; dei kan berre utnytta ein veg som lèt dei påverka tilbodet.

Den farlege reparasjonen er den som fjernar beviset for skilnaden. Å slå på alle eldre val, slå av sertifikatvalidering eller godta kva chiffer som helst for å få ein feil til å forsvinna utvidar kva endepunktet vil godta, og fjernar kontrollane som ville ha rapportert det veikare resultatet.

Viss du må halda på eitt gammalt val, nemn årsaka og klienten i konfigurasjonskommentaren, og avgrens deretter valet til profilen som treng det. Eit kompatibilitetsunntak avgrensa til éin lyttar kan reviderast; eitt som blir brukt globalt er berre ein veikare standard som ingen hugsar å ha valt.

Les feilen før du nemner ei årsak

Ta vare på den nøyaktige feilstrengen, klient- og tenarversjonane og tidspunktet før kvar endring. Klassifiser deretter: var partane usamde om eit tilbod, svikta pakkevegen, eller avviste den eine sida ein parameter ho ein gong godtok?

Eit mismatch i tilbodet nemner vanlegvis dei gjeldande versjonane eller algoritmane og feilar på same punkt kvar gong. Eit ruting- eller MTU-problem stoppar eller går ut på tid, og det varierer ofte med nettet. Eit utgått sertifikat gir ein valideringsfeil i staden for ein forhandlingsfeil.

Ingenting av dette er bevis på ein åtaksmann. Å tildele vondsinna årsak ved den første feilen er feilen, fordi det skjuler den deterministiske feilen som vil feila igjen i morgon.

Stadfest kva som faktisk vart valt

Etter kvar korreksjon, les det forhandla resultatet i staden for å stola på at sambandet kom opp. Eit samband som lykkast fordi valideringa vart fjerna, er utfallet du prøvde å unngå. Dei to kommandoane nedanfor viser vald versjon og chiffer for eit TLS-fronta endepunkt, pluss kontrollkanallinja frå ein OpenVPN tenarlogg.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Samanlikn resultatet med konfigurasjonen du hadde til hensikt, ikkje med kva som no koplar til. Viss den valde versjonen er eldre enn tillate minimum, er profilen eller fallback-lista staden å sjå, og svaret er å retta den lista i staden for å erklæra eit åtak og byggja alt rundt det på nytt.

Relaterte artiklar