HTTPS i VPN nie uwierzytelniają pakietu, który instalujesz

Aktualizacja kończy się niepowodzeniem, a sugestia w wątku idzie znajomą linią: ruch przechodzi przez VPN, więc pobieranie musi być godne zaufania, a weryfikacja podpisu zostaje poluzowana, by ominąć błąd. Dwie odrębne idee zostały stopione w jedno zdanie. Szyfrowanie chroni ścieżkę między punktami końcowymi; uwierzytelnianie decyduje, czy bajty przyszły od wydawcy, którego miały dotyczyć. Tunel daje to pierwsze i nic nie mówi o drugim.

Objawem jest zwykle błąd weryfikacji na jednym hoście, w jednym repozytorium, podczas gdy wszystko inne aktualizuje się normalnie. Ten kształt już mówi, że ścieżka sieciowa działa, a spór dotyczy zaufania.

Dwie kontrole odpowiadające na różne pytania

Bezpieczeństwo transportu odpowiada, kto jest po drugiej stronie tego połączenia i czy ktoś na ścieżce może je czytać lub zmieniać. Uwierzytelnianie pakietu odpowiada, czy ten artefakt został opublikowany przez skonfigurowaną przez ciebie instytucję, i musi przetrwać pobranie przez lustro, którego nie kontrolujesz.

Te pytania pokrywają się tylko na krawędziach. Poprawny certyfikat na lustrze dowodzi, że lustro jest lustrem; nie dowodzi, że lustro zawiera niezmienioną treść wydawcy. Podpisany pakiet dowodzi, że wydawca go podpisał; nie mówi, że sieć dostarczyła najnowszą wersję ani że wskazane repozytorium jest tym zatwierdzonym przez twoją organizację.

Tryb awarii, który ludzie tworzą, wyłączając kontrole, to trwała utrata drugiej gwarancji w zamian za jedno udane pobranie. Ta wymiana jest niewidoczna do dnia, w którym zaczyna mieć znaczenie.

Co apt faktycznie uwierzytelnia

Model APT to uwierzytelniony łańcuch archiwum. Podpisane metadane wydania prowadzą przez sumę kontrolną do indeksów pakietów, a te indeksy prowadzą przez sumę kontrolną do pojedynczych plików pakietów. To właśnie weryfikacja łańcucha czyni lustro nieufnym, ale użytecznym: lustro może serwować, co chce, a podpis metadanych decyduje, czy APT to przyjmie.

To celowo nie jest to samo co sprawdzanie podpisu opiekuna na każdym zainstalowanym pakiecie, i ta różnica wyjaśnia, dlaczego w raportach błędów „pakiet jest podpisany” i „archiwum jest uwierzytelnione” bywają używane zamiennie, choć znaczą co innego.

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

Czytaj wyjście aktualizacji, nie tylko kod wyjścia. APT nazywa repozytorium, którego metadane zawiodły, i ta nazwa jest granicą do zbadania. Repozytorium oznaczone jako zaufane bez weryfikacji podpisu albo nadpisanie dla niezabezpieczonego repozytorium to decyzja konfiguracyjna, którą ktoś podjął i powinien umieć wyjaśnić.

Świeżość to znów osobna właściwość. Poprawnie podpisany plik metadanych może być starszy od tego, który widziałeś w zeszłym tygodniu, dlatego metadane wydania mają datę ważności i dlatego problem z zegarem na kliencie może dawać błędy weryfikacji wyglądające jak problemy z kluczem.

Co dnf5 sprawdza osobno

Strona RPM udostępnia dwa różne przełączniki, a ich pomylenie daje tę samą klasę błędu w drugą stronę. Jeden kontroluje, czy pliki pakietów muszą mieć ważny podpis; drugi, czy metadane repozytorium muszą być podpisane. Można je ustawić niezależnie, a system może być surowy wobec jednego i pobłażliwy wobec drugiego.

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

Zapytanie o pakiet pokazuje, jak wyglądają metadane podpisu zainstalowanej kopii, co jest użytecznym sprawdzeniem rzeczywistości wobec pliku konfiguracji twierdzącego o rygorze. Czego nie mówi, to obsługiwana polityka dystrybucji, i to jej należy przestrzegać zamiast ogólnej instrukcji „włącz GPG” z forum.

Tam, gdzie dwa menedżery się różnią, różnica jest architektoniczna, a nie znakiem, że jeden jest słabszy. Oba uwierzytelniają treść wydawcy; umieszczają podpis w różnych punktach łańcucha.

Co tunel dodaje, a czego nie

VPN może zapewnić wymaganą trasę, trzymać ruch aktualizacji poza niezaufaną siecią dostępową i ograniczyć to, co widzi lokalny obserwator. To realne korzyści operacyjne i żadna z nich nie jest uwierzytelnieniem wydawcy.

HTTPS dodaje własną gwarancję i jest ona węższa, niż się wydaje. Uwierzytelnia punkt końcowy TLS, z którym się połączyłeś. Jeśli ten punkt końcowy jest lustrem, uwierzytelniłeś lustro, a nie treść archiwum, którą ono serwuje. To dokładnie ten przypadek, dla którego istnieje łańcuch podpisanych metadanych.

Żadna z kontroli nie obiecuje dostępności. Sieć może odmówić dostarczenia, a uwierzytelniony obiekt nie jest automatycznie najnowszy. Używaj polityki świeżości samego menedżera pakietów, zamiast wnioskować ją z obecności ikony kłódki.

Zdiagnozuj granicę, która zawiodła

Nazwij etap, zanim cokolwiek zmienisz: rozwiązywanie DNS, proxy lub trasę, tożsamość punktu końcowego TLS, uwierzytelnianie archiwum, kontrole podpisu pakietu albo instalację. Każdy ma inną formę błędu i innego właściciela.

Naprawa ścieżki sieciowej nigdy nie powinna polegać na uznaniu nieznanego klucza podpisującego za zaufany, ignorowaniu certyfikatów ani akceptowaniu konfiguracji repozytorium, o którą nie prosiłeś. Jeśli klucz naprawdę został wymieniony, dystrybucja lub właściciel repozytorium publikuje nowy klucz kanałem, który możesz zweryfikować, i to jest poprawka do zastosowania.

Zapisz, która granica zawiodła i kto za nią odpowiada. Następna awaria aktualizacji będzie przy innej granicy, a posiadanie listy czyni z niej pięciominutową diagnozę zamiast kolejnej dyskusji o tym, czy tunel czyni aktualizacje bezpiecznymi.