Spurado de OpenVPN-regaj pakaĵoj: tls-auth antaŭ TLS

Tls-auth-fiasko kutime raportiĝas kiel manprema problemo, kaj ĝi neniam estis tia. La HMAC estas kontrolata sur la rega pakaĵo antaŭ ol ajna TLS-traktado okazas, do malkongrua ŝlosilo aŭ direkto produktas fiaskon, kiu aspektas kiel atestila problemo kaj estas decidata du tavolojn pli frue. Trakti la koverton kiel propran objekton mallongigas la diagnozon: legu la kampojn, konfirmu, ke la kontrolo ekagas frue, poste komparu la tri aferojn, pri kiuj ambaŭ flankoj devas interkonsenti.

Legu la koverton laŭ la ordo, laŭ kiu ĝi estas konstruata

Rega pakaĵo portas sesian identigilon, la laŭvolan tls-auth-HMAC, ripetan kaj konfirman informojn, kaj fidindan mesaĝan identigilon, kaj poste venas la utilaĵo de la mesaĝa tipo. Kiam la mesaĝo estas manprema mesaĝo, la utilaĵo hazarde estas TLS-ĉifrita teksto. Tio estas la tuta rilato: TLS-materialo vojaĝas ene de mesaĝo, kiun la koverto jam protektas. La OpenVPN-referenco pri la reta protokolo listigas la kampojn de la rega kanalo laŭ tiu ordo.

La fidindeca tavolo facile konfuziĝas kun kriptografio. Konfirmoj, resendo kaj la mesaĝa identigilo ekzistas por ke regaj mesaĝoj alvenu unufoje kaj laŭorde super nefidinda transporto. Ili ne estas aŭtentikigo, kaj ĝusta mesaĝa identigilo pruvas nenion pri tio, kiu sendis la pakaĵon.

Tenu ĉi tiun grupigon koncepta. Ĝi ne estas bitok-orda diagramo, kaj ĝi ne sufiĉas por komputi etikedon, ĉar la kampoj, kiuj eniras la HMAC, dependas de la efektivigo, la versio kaj la reĝimo.

Montru, ke la kontrolo ekagas antaŭ la manpremo

Ricevanto, kiu havas la komunan ŝlosilon, povas kontroli la HMAC kaj tuj forĵeti falsitan pakaĵon, sen asigni manpreman staton aŭ fari publikŝlosilan laboron. La protekto kovras ankaŭ la komencajn manpremajn pakaĵojn, kaj ĝuste tial malĝusta ŝlosilo montriĝas kiel malsukcesa konekto anstataŭ kiel malfrua aŭtentikiga eraro.

Altigu la parolecon de la demono kaj observu la regan kanalon anstataŭ la tun-aparaton:

openvpn --config /etc/openvpn/server.conf --verb 6

Tion, kion vi serĉas, estas malsukceso de HMAC-kontrolo de la rega kanalo raportita je pakaĵa nivelo, antaŭ ajna TLS-avizo. TLS-avizo en la protokolo signifas, ke la koverto estis akceptita kaj la malsukceso moviĝis internen, kio estas alia esploro kun alia solvo.

Direkta traktado ankaŭ troviĝas ĉi tie. Kiam statika ŝlosila dosiero estas uzata kun tls-auth, la du flankoj prenas kontraŭajn ŝlosilajn direktojn, kaj la protokolo uzas tiun disigon por ke kaptita pakaĵo ne povas esti reflektita reen al sia sendinto. Inversigi la direkton konservas la ŝlosilon identa kaj tamen malsukcesigas ĉiun pakaĵon. Ŝanĝu unu flankon samtempe, poste restartigu ambaŭ demonojn por ke la paro ŝarĝiĝu kune.

Akordigu ŝlosilon, direkton kaj digest ĉe ambaŭ flankoj

Tri valoroj devas kongrui kaj nur unu el ili estas la dosiero. La enhavo de la statika ŝlosilo devas esti identa ĉe ambaŭ flankoj, la direkto devas esti kontraŭa, kaj la digest uzata por la HMAC devas kongrui. Kontrolu la agordon antaŭ ol tuŝi la ŝlosilan materialon, ĉar unu inversigita direkto klarigas pli da malsukcesoj ol difektita dosiero:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Generu la komunan sekreton per la ilo anstataŭ per redaktilo, kaj tenu la permesojn striktaj:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Pli malnovaj eldonoj akceptis iomete alian opcian ordon por ŝlosilgenerado, kaj profiloj skribitaj por tiuj eldonoj ankoraŭ cirkulas. La generita dosiero estas la sama speco de objekto en ambaŭ kazoj, do la kontrolo estas, ĉu ambaŭ flankoj tenas identajn bitokojn, ne kiun literumadon produktis ilin.

Ne konfuzu tls-auth kun tls-crypt. Ambaŭ protektas la regan kanalon, sed tls-crypt ankaŭ ĉifras ĝin kaj kaŝas la manpremon for de observantoj, kaj ĝi anstataŭigas la direkto-disigon per propra ŝlosila traktado. Profilo uzanta unu ne interrilatos kun kunulo agordita por la alia, kaj neniu digest-agordado fermas tiun breĉon.

Reproduktu etikedon nur el la reala formato

Bitok-preciza reproduktado estas aparta tasko de funkciigi VPN, kaj ĝi funkcias nur kun la realaj enigoj: la efektivigo kaj versio, kiuj konstruis la pakaĵon, la elektita digest, la direkto, kaj la faktaj bitokoj inkluzive de la sesia identigilo kaj la konfirma tabelo. Teksta prezento de la kampa listo ne estas tiuj bitokoj.

La etikeda longeco sekvas el la digest, do la supozo pri fiksa longeco rompiĝas en la momento, kiam iu ŝanĝas ĝin. Haketu la pakaĵon tiel, kiel faras la efektivigo, ne tiel, kiel prezentas ĝin tabelo en blogaĵo, kaj komparu kun kaptaĵo prenita de la sama kunulo anstataŭ kun atendo, kiun vi derivis permane.

Tenu tiun ekzercon for de produktaj profiloj. Nenio pri reproduktado de etikedo diras al vi, ĉu deplojo devus ŝalti la protekton.

Malfaru malkongruon sen forigi la protekton

La tentiga testo estas forigi tls-auth, vidi la konekton sukcesi kaj konkludi, ke la ŝlosilo estis malĝusta. Tiu respondo kostas al vi la protekton kaj instruas nenion pri tio, kiu el la tri valoroj malkongruis. Anstataŭe prenu la aprobitan kongruan agordon de la servila flanko kaj komparu kun ĝi.

Preparu la ŝanĝon tiel, ke ĝi estu malfarebla. Konservu la antaŭan servilan agordon kaj ŝlosilan dosieron, apliku la korektitan paron, kontrolu, ke kliento kompletigas la manpremon, kaj nur poste forigu la rezervkopion. Se klientoj malsukcesas post la ŝanĝo, restarigu la antaŭajn dosierojn anstataŭ improvizi trian varianton dum interrompo. La restarigo devus esti unu komando, kiun vi jam konas antaŭ ol komenci.

Fine, memoru, kion signifas sukcesa kontrolo. Ĝi pruvas, ke la kunulo tenas la komunan ŝlosilon, ne ke ĝia atestilo aŭ konto estas rajtigita, kaj ĝi diras nenion pri la intertraktita datumkanala ĉifro. Rajtigo kaj datuma protekto estas starigataj pli poste, do pura koverta kontrolo estas komenca punkto, ne verdikto.