A HTTPS és a VPN nem hitelesíti a telepített csomagot

Egy frissítés meghiúsul, és a szálban javasolt megoldás ismerős irányt követ: a forgalom VPN-en halad át, tehát a letöltésnek megbízhatónak kell lennie, és az aláírás-ellenőrzést lazítják, hogy túljussanak a hibán. Két különálló gondolat olvadt össze egyetlen mondatba. A titkosítás védi a végpontok közötti utat; a hitelesítés dönti el, hogy a bájtok attól a kiadótól jöttek-e, akit szándékoltál. Az alagút az elsőt adja, a másodikról semmit sem mond.

A tünet általában ellenőrzési hiba egyetlen hoszton, egyetlen tárolóban, miközben minden más rendesen frissül. Ez a forma már elárulja, hogy a hálózati útvonal működik, és a nézeteltérés a bizalomról szól.

Két ellenőrzés, amelyek különböző kérdésekre válaszolnak

A szállításbiztonság arra válaszol, ki van a kapcsolat túlsó végén, és hogy az útvonalon bárki olvashatja-e vagy módosíthatja-e. A csomaghitelesítés arra válaszol, hogy ezt az artefaktumot a beállított hatóság adta-e ki, és ki kell bírnia a letöltést egy olyan tükrön keresztül, amelyet nem ellenőrzöl.

Ezek a kérdések csak a széleken fednek át. A helyes tanúsítvány egy tükrön azt bizonyítja, hogy a tükör a tükör; azt nem bizonyítja, hogy a tükör változatlan kiadói tartalmat tartalmaz. Az aláírt csomag azt bizonyítja, hogy a kiadó aláírta; azt nem mondja meg, hogy a hálózat a legújabb verziót szállította-e, vagy hogy a megadott tároló az-e, amelyet a szervezeted jóváhagyott.

A hibaállapot, amit az emberek az ellenőrzések kikapcsolásával létrehoznak, a második garancia végleges elvesztése egyetlen sikeres letöltés fejében. Ez a csere addig láthatatlan, amíg számít.

Mit hitelesít valójában az apt

Az APT modellje egy hitelesített archívumlánc. Az aláírt kiadási metaadatok ellenőrzőösszegen keresztül vezetnek a csomagindexekhez, azok az indexek pedig ellenőrzőösszegen keresztül az egyes csomagfájlokhoz. A lánc ellenőrzése teszi a tükröt megbízhatatlanná, de használhatóvá: a tükör azt szolgál ki, amit akar, és a metaadatok aláírása dönti el, hogy az APT elfogadja-e.

Ez szándékosan nem ugyanaz, mint minden telepített csomagon ellenőrizni a karbantartó aláírását, és ez a különbség magyarázza, miért használják a hibajegyekben felcserélhetően az „a csomag aláírt” és „az archívum hitelesített” kifejezéseket, holott mást jelentenek.

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

A frissítés kimenetét olvasd, ne csak a kilépési kódot. Az APT megnevezi azt a tárolót, amelynek metaadatai meghiúsultak, és az a név a vizsgálandó határ. Az aláírás-ellenőrzés nélkül megbízhatónak jelölt tároló, vagy egy nem biztonságos tároló felülírása olyan konfigurációs döntés, amelyet valaki meghozott, és meg kell tudnia magyarázni.

A frissesség megint külön tulajdonság. Egy érvényesen aláírt metaadatfájl lehet régebbi, mint amit múlt héten láttál, ezért hordoz lejárati dátumot a kiadási metaadat, és ezért okozhat az ügyfél óraproblémája olyan ellenőrzési hibákat, amelyek kulcsproblémáknak tűnnek.

Mit ellenőriz külön a dnf5

Az RPM oldal két külön kapcsolót kínál, és ezek összekeverése ugyanazt a hibosztályt hozza létre a másik irányban. Az egyik azt szabályozza, hogy a csomagfájloknak érvényes aláírást kell-e hordozniuk; a másik azt, hogy a tároló metaadatainak aláírtnak kell-e lennie. Egymástól függetlenül állíthatók, és egy rendszer lehet szigorú az egyikben és engedékeny a másikban.

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

A csomaglekérdezés megmutatja, hogyan néznek ki a telepített példány aláírás-metaadatai, ami hasznos valóságellenőrzés egy szigort állító konfigurációs fájllal szemben. Amit nem mond el, az a disztribúció támogatott irányelve, és azt kellene követned egy fórumról származó általános „kapcsold be a GPG-t” utasítás helyett.

Ahol a két kezelő eltér, a különbség architekturális, nem annak jele, hogy az egyik gyengébb. Mindkettő hitelesíti a kiadói tartalmat; az aláírást a lánc különböző pontjaira helyezik.

Mit ad hozzá az alagút és mit nem

A VPN biztosíthat szükséges útvonalat, távol tarthatja a frissítési forgalmat egy nem megbízható hozzáférési hálózattól, és csökkentheti azt, amit egy helyi megfigyelő lát. Ezek valódi üzemeltetési előnyök, és egyik sem kiadóhitelesítés.

A HTTPS hozzáadja a saját garanciáját, és az szűkebb, mint amilyennek érződik. Azt a TLS-végpontot hitelesíti, amelyhez kapcsolódtál. Ha az a végpont tükör, a tükröt hitelesítetted, nem a kiszolgált archívumtartalmat. Pontosan ez az az eset, amelyre az aláírt metaadatok lánca létezik.

Egyik ellenőrzés sem ígér elérhetőséget. A hálózat megtagadhatja a kézbesítést, és egy hitelesített objektum nem automatikusan a legújabb. A csomagkezelő saját frissességi irányelvét használd, ahelyett hogy egy lakatikon jelenlétéből következtetnél rá.

Diagnosztizáld a meghiúsult határt

Nevezd meg a szakaszt, mielőtt bármit módosítasz: DNS-feloldás, a proxy vagy az útvonal, a TLS-végpont identitása, az archívum hitelesítése, a csomag aláírás-ellenőrzései vagy a telepítés. Mindegyiknek külön hibaformája és külön tulajdonosa van.

Egy hálózati útvonal javítása soha nem járhat együtt egy ismeretlen aláírókulcs megbízhatónak nyilvánításával, tanúsítványok figyelmen kívül hagyásával vagy egy nem kért tárolókonfiguráció elfogadásával. Ha egy kulcs valóban lecserélődött, a disztribúció vagy a tároló tulajdonosa olyan csatornán teszi közzé az új kulcsot, amelyet ellenőrizni tudsz, és ezt a javítást kell alkalmazni.

Írd le, melyik határ hiúsult meg, és ki a tulajdonosa. A következő frissítési hiba másik határnál lesz, és a lista birtokában ötperces diagnózissá válik az újabb vita helyett arról, hogy az alagút biztonságossá teszi-e a frissítéseket.