HTTPS ja VPN ei autendi paigaldatavat paketti

Värskendus ebaõnnestub ja lõimes pakutud lahendus järgib tuttavat liini: liiklus käib VPN-i kaudu, seega peab allalaadimine olema usaldusväärne, ja allkirjakontrolli lõdvendatakse, et vigast mööda saada. Kaks eraldi ideed on ühte lausesse sulandunud. Krüpteerimine kaitseb teed otspunktide vahel; autentimine otsustab, kas baidid tulid kavatsetud avaldajalt. Tunnel annab esimese ega ütle teise kohta midagi.

Sümptom on tavaliselt kontrolliviga ühes hostis, ühes hoidlas, samal ajal kui kõik muu uueneb normaalselt. See kuju ütleb juba, et võrgutee töötab ja et lahkarvamus puudutab usaldust.

Kaks kontrolli, mis vastavad erinevatele küsimustele

Transporditurve vastab, kes on selle ühenduse teises otsas ja kas keegi teel saab seda lugeda või muuta. Paketi autentimine vastab, kas selle artefakti avaldas asutus, mille te seadistasite, ja see peab vastu pidama allalaadimisele läbi peegli, mida te ei kontrolli.

Need küsimused kattuvad ainult servades. Õige sertifikaat peeglil tõestab, et peegel on peegel; see ei tõesta, et peegel hoiab muutmata avaldaja sisu. Allkirjastatud pakett tõestab, et avaldaja selle allkirjastas; see ei ütle teile, et võrk edastas uusima versiooni või et hoidla, millele te osutasite, on see, mille teie organisatsioon heaks kiitis.

Tõrkeržiim, mille inimesed kontrollide väljalülitamisega loovad, on teise garantii jääv kaotus ühe õnnestunud allalaadimise eest. See vahetus on nähtamatu kuni päevani, mil see loeb.

Mida apt tegelikult autendib

APT mudel on autenditud arhiiviahel. Allkirjastatud väljaande metaandmed viivad kontrollsumma kaudu paketiindeksiteni ja need indeksid viivad kontrollsumma kaudu üksikute paketifailideni. Just ahela kontrollimine teeb peeglist mitteusaldusväärse, kuid kasutatava: peegel võib serveerida mida iganes, ja metaandmete allkiri otsustab, kas APT selle vastu võtab.

See ei ole tahtlikult sama mis hooldaja allkirja kontrollimine igal paigaldatud paketil, ja see erinevus selgitab, miks «pakett on allkirjastatud» ja «arhiiv on autenditud» kasutatakse veaaruannetes vaheldumisi, kuigi need tähendavad erinevaid asju.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

Lugege värskenduse väljundit, mitte ainult väljumiskoodi. APT nimetab hoidla, mille metaandmed ebaõnnestusid, ja see nimi on uuritav piir. Allkirjakontrollita usaldusväärseks märgitud hoidla või ebaturvalise hoidla jaoks tehtud möödasõit on seadistusotsus, mille keegi tegi ja mida ta peaks suutma selgitada.

Värskus on jälle eraldi omadus. Kehtivalt allkirjastatud metaandmefail võib olla vanem kui see, mida nägite eelmisel nädalal, seepärast kannavad väljaande metaandmed aegumiskuupäeva ja seepärast võib kliendi kella probleem tekitada kontrollivigu, mis näevad välja nagu võtmeprobleemid.

Mida dnf5 eraldi kontrollib

RPM pool pakub kahte erinevat lülitit ja nende segamine tekitab sama veaklassi vastassuunas. Üks juhib, kas paketifailidel peab olema kehtiv allkiri; teine juhib, kas hoidla metaandmed peavad olema allkirjastatud. Neid saab seada sõltumatult ja süsteem võib olla ühes range ja teises leebe.

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

Paketipäring näitab, millised on paigaldatud koopia allkirja metaandmed, mis on kasulik reaalsuskontroll rangeust väitva seadistusfaili vastu. Mida see teile ei ütle, on distributsiooni toetatud poliitika, ja just seda peaksite järgima, mitte foorumist pärit üldist «lülitage GPG sisse» juhist.

Kus kaks haldurit erinevad, on erinevus arhitektuurne, mitte märk, et üks on nõrgem. Mõlemad autendivad avaldaja sisu; nad paigutavad allkirja ahelas erinevatesse kohtadesse.

Mida tunnel lisab ja mida mitte

VPN saab pakkuda vajalikku marsruuti, hoida värskendusliiklust väljaspool mitteusaldusväärset juurdepääsuvõrku ja vähendada seda, mida kohalik vaatleja näeb. Need on tõelised operatiivsed eelised ja ükski neist ei ole avaldaja autentimine.

HTTPS lisab oma garantii ja see on kitsam, kui tundub. See autendib TLS-otspunkti, millega ühendusite. Kui see otspunkt on peegel, olete autendinud peegli, mitte selle serveeritava arhiivisisu. Just see on juhtum, mille jaoks allkirjastatud metaandmete ahel on olemas.

Kumbki kontroll ei taga kättesaadavust. Võrk võib tarne keelata ja autenditud objekt ei ole automaatselt uusim. Kasutage paketihalduri enda värskuspoliitikat, selle asemel et tuletada seda lukuikooni olemasolust.

Diagnoosige piir, mis ebaõnnestus

Nimetage etapp enne millegi muutmist: DNS-i lahendamine, puhverserver või marsruut, TLS-otspunkti identiteet, arhiivi autentimine, paketi allkirjakontrollid või paigaldamine. Igal on erinev veakuju ja erinev omanik.

Võrgutee parandamine ei peaks kunagi hõlmama tundmatu allkirjavõtme usaldusväärseks kuulutamist, sertifikaatide eiramist ega sellise hoidla seadistuse vastuvõtmist, mida te ei küsinud. Kui võti tõesti vahetus, avaldab distributsioon või hoidla omanik uue võtme kanali kaudu, mida saate kontrollida, ja see on parandus, mida tuleb rakendada.

Kirjutage üles, milline piir ebaõnnestus ja kes selle eest vastutab. Järgmine värskendustõrge on teisel piiril ja nimekirja olemasolu teeb sellest viie minuti diagnoosi, mitte veel ühe vaidluse selle üle, kas tunnel muudab värskendused turvaliseks.