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، احراز بایگانی، بررسی‌های امضای بسته، یا نصب. هر یک شکل خطا و مالک متفاوتی دارد.

ترمیم یک مسیر شبکه هرگز نباید شامل قابل‌اعتماد اعلام کردن یک کلید امضای ناشناخته، نادیده گرفتن گواهی‌ها، یا پذیرفتن پیکربندی مخزنی باشد که درخواستش نکرده‌اید. اگر کلیدی واقعاً چرخیده باشد، توزیع یا مالک مخزن کلید جدید را از کانالی منتشر می‌کند که می‌توانید تأیید کنید، و همان اصلاحی است که باید اعمال شود.

بنویسید کدام مرز شکست خورد و مالکش کیست. شکست بعدی به‌روزرسانی در مرز دیگری خواهد بود، و داشتن این فهرست آن را به تشخیصی پنج‌دقیقه‌ای تبدیل می‌کند نه بحثی دیگر دربارهٔ اینکه آیا تونل به‌روزرسانی‌ها را امن می‌کند.