Ĉu malsukcesa VPN-manpremo vere estas malsuprengrada atako?

Manpremo, kiu finiĝas per eraro, sentiĝas kiel atako ĝis vi rigardas la mesaĝon, kaj plej ofte temas pri aritmetiko: neniu komuna propono, eksdata atestilo aŭ pako, kiu neniam alvenis. Malsuprengrada atako estas io specifa: kontraŭulo pelanta ambaŭ flankojn al pli malforta konduto ol ili elektus, kaj ĝi lasas aliajn spurojn. Trakti ĉiun malsukceson kiel malican sendas vin serĉi viktimon, kiu eble ne ekzistas, dum trakti veran malsuprengradon kiel agordan cimon lasas la pli malfortan rezulton surloke. La du eraroj kostas malsamajn aferojn, kaj nur unu el ili estas malmultekoste korektebla.

Kion malsuprengrada atako efektive ŝanĝas

La celo ne estas rompi la ĉifron kaj ne diveni ŝlosilon. Ĝi estas influi la intertraktadon tiel, ke ambaŭ flankoj restu ĉe pli malnova versio aŭ pli malforta algoritmo, kiun la atakanto povas manipuli, aŭ igi unu flankon kredi, ke la alia subtenas nur tion.

Kio ŝanĝiĝas estas la interkonsento, ne la aŭtentikigo. Se la atakanto povas ŝanĝi la proponon sen esti detektita, la partneroj ankoraŭ povas fini manpremon kaj ankoraŭ aŭtentikigi unu la alian, sed per parametroj, kiujn la atakanto preferas. Tial la interesa demando estas, ĉu la intertraktado mem estas kovrita de protekto de integreco.

Kial la intertraktado mem devas esti aŭtentikigita

TLS 1.3 igas tiun protekton eksplicita. Kliento, kiu proponis la pli novan version, povas detekti serveron, kiu silente retrofalis, ĉar la hazarda valoro de la servero portas fiksan ŝablonon, kiam ĝi intertraktas 1.2 aŭ pli malalte, kaj la kliento devas ĉesigi vidinte ĝin. La tuta transskribo ankaŭ estas kovrita de la finaj mesaĝoj, do ŝanĝo ie ajn en la intertraktado malsukcesas poste anstataŭ pasi silente.

Pli malnovaj protokolversioj havis pli malfortajn rakontojn, kaj ĝuste tial la retrofalaj reguloj gravas. TLS 1.0 finpunkto en la sama agordo ne estas malsuprengrada atako; ĝi estas permesita rezulto, kiun vi elektis permesi. La distingo estas, ĉu la pli malforta rezulto venis el protektita decido aŭ el neprotektita vojo, kiun peranto povus influi. Kiam vi esprimas ĝin tiel, plej multaj incidentoj solviĝas en agordan demandon.

IKEv2 kondutas alie sed ripozas sur la sama ideo. La propono estas portata en interŝanĝo, kiu poste aŭtentikigas ambaŭ partnerojn, do mezaparato, kiu reverkas la algoritmojn, rompas la aŭtentikigon anstataŭ direkti ĝin. La kontrolkanalo de OpenVPN protektas sian intertraktadon per TLS kaj poste uzas tiun kanalon por interkonsenti la ĉifrojn de la datkanalo, kaj tial la protokollinio de la kontrolkanalo estas la interesa.

Agordita kongruo ne estas atako

Administranto povas intence permesi pli malnovajn elektojn por subteni dokumentitan klienton, kaj tiu decido estas videbla en la agordo. Atakanto ne povas krei tiun agordon; ili povas nur ekspluati vojon, kiu lasas ilin influi la proponon.

La danĝera riparo estas tiu, kiu forigas pruvon de la diferenco. Ŝalti ĉiun heredaĵan opcion, malŝalti atestilan kontroladon aŭ akcepti ajnan ĉifron por ke eraro malaperu larĝigas tion, kion la finpunkto akceptos, kaj forigas la kontrolojn, kiuj raportus la pli malfortan rezulton.

Se vi devas konservi unu malnovan opcion, nomu la kialon kaj la klienton en la agorda komento, poste limigu la opcion al la profilo, kiu bezonas ĝin. Kongrua escepto limigita al unu aŭskultanto estas reviziebla; tiu aplikata tutmonde estas nur pli malforta defaŭlto, kiun neniu memoras elekti.

Legu la malsukceson antaŭ ol nomi kaŭzon

Konservu la ĝustan erarĉenon, la versiojn de kliento kaj servilo kaj la tempon antaŭ ajna ŝanĝo. Poste klasifiku: ĉu la partneroj malkonsentis pri propono, ĉu la pakvojo malsukcesis, aŭ ĉu unu flanko rifuzis parametron, kiun ĝi iam akceptis?

Miskongruo de propono kutime nomas la kulpajn versiojn aŭ algoritmojn kaj malsukcesas ĉe la sama punkto ĉiufoje. Enkursiga aŭ MTU-problemo haltas aŭ finiĝas per tempolimo, kaj ĝi ofte varias laŭ la reto. Eksdata atestilo produktas kontroleraron anstataŭ intertraktan eraron.

Nenio el tio estas pruvo de atakanto. Atribui malican kaŭzon ĉe la unua malsukceso estas la eraro, ĉar ĝi kaŝas la determinisman cimon, kiu malsukcesos denove morgaŭ.

Konfirmu, kio efektive estis elektita

Post ajna korekto, legu la intertraktitan rezulton anstataŭ fidi, ke la konekto leviĝis. Konekto, kiu sukcesas ĉar kontrolado estis forigita, estas la rezulto, kiun vi provis eviti. La du sekvaj komandoj montras la elektitan version kaj ĉifron por TLS-fronta finpunkto, kaj la kontrolkanalan linion el OpenVPN servila protokolo.

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

Komparu la rezulton kun la agordo, kiun vi celis, ne kun tio, kio nun konektiĝas. Se la elektita versio estas pli malnova ol la permesita minimumo, la profilo aŭ la retrofala listo estas la loko por rigardi, kaj la respondo estas ripari tiun liston anstataŭ deklari atakon kaj rekonstrui ĉion ĉirkaŭ ĝi.