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, автентифікацію архіву, перевірки підпису пакета або встановлення. Кожен має власну форму помилки й власного власника.

Виправлення мережевого шляху ніколи не повинно включати оголошення невідомого ключа підпису довіреним, ігнорування сертифікатів або прийняття конфігурації репозиторію, яку ви не просили. Якщо ключ справді змінився, дистрибутив або власник репозиторію публікує новий ключ каналом, який ви можете перевірити, і це та поправка, яку треба застосувати.

Запишіть, яка межа не пройшла і хто за неї відповідає. Наступний збій оновлення буде на іншій межі, і наявність списку перетворює його на п'ятихвилинну діагностику замість чергової суперечки про те, чи робить тунель оновлення безпечними.