Malsukcesis HMAC-aŭtentikigo de OpenVPN-paketo: kiu tavolo?

Du malsukcesoj raportiĝas per la sama vortprovizo kaj havas preskaŭ nenion komunan. Unu estas paketo, kies aŭtentiga etikedo ne validiĝis; la alia estas persono, kies legitimiloj estis rifuzitaj. Trakti la unuan kiel la duan sendas vin serĉi pasvorton, kiu neniam estis la problemo.

La mesaĝo nomas tavolon, kaj la utila laboro estas decidi kiun antaŭ ol anstataŭigi ajnan materialon. Kompari la kandidatojn flank-al-flanke estas la plej rapida maniero vidi la diferencon.

Du malsukcesoj, kiuj dividas unu vorton

Paketa aŭtentiga eraro ekestas dum prilaborado de trafiko: etikedo aŭ resumo sur ricevita paketo ne kongruis kun tio, kion la ricevanto kalkulis. Konta rifuzo okazas post kiam ensaluta interŝanĝo estis analizita, kaj ĝi nomas uzanton anstataŭ paketon. Tria mesaĝo, pri neebleco trovi HMAC en alvenanta paketo, denove estas alia, ĉar tie la paketo alvenis tute sen la atendata aŭtentiga elemento. La plena protokola prefikso diras al vi, kiun el la tri vi havas, kaj la prefikso kutime estas la unua afero forigata, kiam eraro estas algluita en bileton.

La distingo ŝanĝas la riparon. Unu postulas kongruajn kanalagordojn, alia kontostaton, kaj la tria profilon, kiu ne kongruas kun la aŭskultanto, kiun ĝi atingis.

Komparu, kion la kuranta procezo efektive ŝargis

Ĝusta dosiero sur la disko pruvas nenion pri procezo, kiu komenciĝis antaŭ ol ĝi estis redaktita. Kontrolu la elektitan profilon, la finpunkton, kiun ĝi kontaktis, kaj ĉu la servo estis reŝargita post la ŝanĝo. Konfirmu ankaŭ, ke la finpunkto apartenas al la profilo, ĉar alia instanco aŭ alia servo povas aŭskulti tie, kie la malnova dosiero atendas ion alian.

Reeksporti subtenatan profilon el la sama fonto estas malmultekosta komparo, ĉar ĝi forigas la diferencon inter tio, kion vi kredas agordita, kaj tio, kion la kliento efektive sendas. Generi freŝan ŝlosilan materialon estas multe pli granda paŝo, kaj ĝi helpas nur se ambaŭ flankoj adoptas ĝin kune. Anstataŭigi unu flankon loke rekreis la miskongruon, kiun vi provis forigi.

Komparu la kontrolkanalon kun la datenkanalo

Du mekanismoj aŭtentikigas malsamajn partojn de konekto kaj agordiĝas aparte, kiel la opcia referenco 2.6 priskribas. tls-auth aldonas HMAC al paketoj de la kontrolkanalo kaj prenas direkton-argumenton, kiu devas esti mala ĉe la du samtavolanoj, dum tls-crypt protektas la kontrolkanalon per komuna ŝlosilo anstataŭe. Nenium estas la propra integrekontrolo de la datenkanalo. Ĉe AEAD-datenĉifro tiu kontrolo estas enkonstruita en la ĉifron, do la aparta auth resumo ne uziĝas tiel, kiel ĉe ĉifro, kiu ne estas AEAD.

Kio signifas, ke auth linio kopiita el funkcianta ne-AEAD-ekspansio povas esti senrilata en AEAD-ekspansio, kaj AEAD-ekspansio ankoraŭ povas malsukcesi ĉe la kontrolkanalo, se la tls-auth ŝlosilo aŭ ĝia direkto estas malĝusta. Komparu ĉiun agordon kun la samtavolano, ne kun memorata agordo.

Komparu la riparon kun la eco, kiun vi rezignas

Malŝalti paketan aŭtentikigon silentigas la averton kaj forigas la kontrolon, kiu trovis la miskongruon, kio ne samas al ripari la profilon. Demandu, kiun econ vi fordonas kaj ĉu la dezajno ankoraŭ tenas sen ĝi.

Legu la unuan gravan eventon ĉe ambaŭ finoj antaŭ ol ŝanĝi ion ajn, poste ŝanĝu nur la miskongruon, kiun ĝi nomas.

Se la sekva provo progresas al atestila aŭ ensaluta eraro, tio estas progreso, ne regreso: la paketa tavolo nun konsentas kaj la konekto antaŭeniris. Notu la agordojn, kiuj kaŭzis la ŝanĝon, por ke la sekva persono heredas klarigon anstataŭ enigmon.