HTTPS і VPN не пацвярджаюць пакунак, які вы ўсталёўваеце

Абнаўленне не ўдаецца, і парада ў галінцы ідзе па знаёмай лініі: трафік ідзе праз VPN, значыць, спампаванне мусіць быць надзейным, і праверку подпісу паслабляюць, каб абысці памылку. Дзве асобныя думкі зліліся ў адным сказе. Шыфраванне абараняе шлях паміж канцавымі пунктамі; аўтэнтыфікацыя вырашае, ці прыйшлі байты ад выдаўца, якога вы мелі на ўвазе. Тунель дае першае і нічога не кажа пра другое.

Сімптом звычайна — памылка праверкі на адным хоставе, у адным сховішчы, тады як усё астатняе абнаўляецца нармальна. Гэтая форма ўжо кажа, што сеткавы шлях працуе, а разыходжанне тычыцца даверу.

Два кантролі, якія адказваюць на розныя пытанні

Бяспека транспарту адказвае, хто знаходзіцца на другім канцы гэтага злучэння і ці можа нехта на шляху прачытаць або змяніць яго. Аўтэнтыфікацыя пакунка адказвае, ці быў гэты артэфакт апублікаваны ўладай, якую вы наладзілі, і яна мусіць вытрымаць спампаванне праз люстэрка, якім вы не кіруеце.

Гэтыя пытанні перасякаюцца толькі па краях. Правільны сертыфікат на люстэрку даказвае, што люстэрка — гэта люстэрка; ён не даказвае, што люстэрка трымае нязменены змест выдаўца. Падпісаны пакунак даказвае, што выдавец яго падпісаў; ён не кажа вам, што сетка даставіла найноўшую версію або што сховішча, на якое вы паказалі, — тое, якое ўхваліла ваша арганізацыя.

Рэжым адмовы, які ствараюць людзі, выключаючы праверкі, — гэта назаўсёдная страта другой гарантыі ў абмен на адно паспяховае спампаванне. Гэты абмен незаўважны да таго дня, калі ён мае значэнне.

Што apt насамрэч аўтэнтыфікуе

Мадэль APT — гэта ланцуг аўтэнтыфікаванага архіва. Падпісаныя метаданыя выпуску вядуць праз кантрольную суму да індэксаў пакункаў, а гэтыя індэксы вядуць праз кантрольную суму да асобных файлаў пакункаў. Менавіта праверка ланцуга робіць люстэрка недавераным, але прыдатным: люстэрка можа падаваць што заўгодна, а подпіс метаданых вырашае, ці прыме гэта APT.

Гэта свядома не тое ж, што праверка подпісу суправаджальніка на кожным усталяваным пакунку, і гэтае адрозненне тлумачыць, чаму ў справаздачах пра памылкі «пакунак падпісаны» і «архіў аўтэнтыфікаваны» ўжываюць як узаемазаменныя, хоць яны значаць рознае.

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

Чытайце вывад абнаўлення, а не толькі код выхаду. APT называе сховішча, чые метаданыя не прайшлі, і гэтае імя — мяжа для даследавання. Сховішча, пазначанае як даверанае без праверкі подпісу, або пераазначэнне для небяспечнага сховішча — гэта канфігурацыйнае рашэнне, якое нехта прыняў і мусіць умець тлумачыць.

Свежасць — зноў асобная ўласцівасць. Сапраўдныя падпісаныя метаданыя могуць быць старэйшымі за тыя, што вы бачылі тыдзень таму, таму метаданыя выпуску маюць тэрмін дзеяння і таму збой гадзінніка на кліенце можа даваць памылкі праверкі, падобныя на праблемы з ключом.

Што dnf5 правярае асобна

Бок RPM прапаноўвае два асобныя перамыкачы, і блытанне іх дае той жа клас памылак у іншым кірунку. Адзін кіруе тым, ці мусіць файлы пакункаў мець сапраўдны подпіс; другі — ці мусіць быць падпісаныя метаданыя сховішча. Іх можна ўсталёўваць незалежна, і сістэма можа быць строгай у адным і паблажлівай у другім.

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

Запыт пакунка паказвае, як выглядаюць метаданыя подпісу ўсталяванай копіі, што ёсць карыснай праверкай рэальнасці супраць файла канфігурацыі, які сцвярджае строгасць. Чаго ён вам не кажа — падтрыманая палітыка дыстрыбутыва, і менавіта ёй трэба ісці, а не агульнай інструкцыі «уключыце GPG» з форуму.

Там, дзе два кіраўнікі розняцца, розніца архітэктурная, а не знак, што адзін слабейшы. Абодва аўтэнтыфікуюць змест выдаўца; подпіс яны ставяць у розных кропках ланцуга.

Што тунель дае і чаго не дае

VPN можа даць патрэбны маршрут, трымаць трафік абнаўленняў па-за недаверанымі сеткамі доступу і паменшыць тое, што бачыць мясцовы назіральнік. Гэта рэальныя аперацыйныя перавагі, і ніводная з іх не ёсць аўтэнтыфікацыяй выдаўца.

HTTPS дадае ўласную гарантыю, і яна вужэйшая, чым здаецца. Ён аўтэнтыфікуе канцавы пункт TLS, да якога вы далучыліся. Калі гэты канцавы пункт — люстэрка, вы аўтэнтыфікавалі люстэрка, а не змест архіва, які яно падае. Гэта менавіта той выпадак, для якога існуе ланцуг падпісаных метаданых.

Ніводзін з кантроляў не абяцае даступнасці. Сетка можа адмовіць у дастаўцы, а аўтэнтыфікаваны аб'ект не абавязкова найноўшы. Карыстайцеся ўласнай палітыкай свежасці кіраўніка пакункаў замест таго, каб рабіць выснову з наяўнасці значкі замка.

Дыягнастуйце мяжу, якая адмовіла

Назвіце этап, перш чым нешта змяняць: развязанне DNS, проксі або маршрут, ідэнтычнасць канцавога пункта TLS, аўтэнтыфікацыя архіва, праверкі подпісу пакункаў або ўсталяванне. Кожны мае ўласную форму памылкі і ўласнага ўладальніка.

Рамантаванне сеткавага шляху ніколі не мусіць уключаць абвяшчэнне невядомага ключа подпісу давераным, ігнараванне сертыфікатаў або прыняцце канфігурацыі сховішча, якую вы не прасілі. Калі ключ сапраўды змяніўся, дыстрыбутыў або ўладальнік сховішча публікуе новы ключ праз канал, які вы можаце праверыць, і гэта і ёсць папраўка, якую трэба ўжыць.

Запішыце, якая мяжа адмовіла і хто ёю валодае. Наступная адмова абнаўлення будзе на іншай мяжы, і наяўнасць спісу робіць гэта дыягнозам на пяць хвілін замест чарговых спрэчак пра тое, ці робіць тунель абнаўленні бяспечнымі.