HTTPS dan VPN tidak mengautentikasi paket yang Anda pasang

Sebuah pembaruan gagal, dan saran di utas mengikuti pola yang lazim: lalu lintas melewati VPN, jadi unduhan pasti tepercaya, dan pemeriksaan tanda tangan dilonggarkan agar bisa melewati galat. Dua gagasan terpisah telah dilebur menjadi satu kalimat. Enkripsi melindungi jalur antara dua ujung; autentikasi memutuskan apakah byte berasal dari penerbit yang Anda maksud. Terowongan menyediakan yang pertama dan tidak berkata apa pun tentang yang kedua.

Gejalanya biasanya galat verifikasi pada satu host, di satu repositori, sementara semua yang lain diperbarui dengan normal. Bentuk itu sudah menunjukkan bahwa jalur jaringan bekerja dan perselisihannya soal kepercayaan.

Dua kendali yang menjawab pertanyaan berbeda

Keamanan transport menjawab siapa yang ada di ujung lain koneksi ini dan apakah seseorang di jalur dapat membacanya atau mengubahnya. Autentikasi paket menjawab apakah artefak ini diterbitkan oleh otoritas yang Anda konfigurasi, dan ia harus bertahan saat diunduh lewat cermin yang tidak Anda kendalikan.

Pertanyaan itu hanya bersinggungan di tepinya. Sertifikat yang benar pada cermin membuktikan cermin itu adalah cermin; itu tidak membuktikan cermin menyimpan konten penerbit yang tidak berubah. Paket bertanda tangan membuktikan penerbit menandatanganinya; itu tidak memberi tahu Anda bahwa jaringan mengantarkan versi terbaru atau bahwa repositori yang Anda tuju adalah yang disetujui organisasi Anda.

Mode kegagalan yang orang ciptakan dengan mematikan pemeriksaan adalah hilangnya jaminan kedua secara permanen, ditukar dengan satu unduhan yang berhasil. Pertukaran itu tidak terlihat sampai hari ketika ia penting.

Apa yang sebenarnya diautentikasi apt

Model APT adalah rantai arsip terautentikasi. Metadata rilis bertanda tangan menuntun lewat checksum ke indeks paket, dan indeks itu menuntun lewat checksum ke berkas paket individual. Memverifikasi rantai itulah yang membuat cermin tak tepercaya tetapi tetap bisa dipakai: cermin boleh menyajikan apa pun, dan tanda tangan metadata yang memutuskan apakah APT menerimanya.

Itu sengaja tidak sama dengan memeriksa tanda tangan pemelihara pada setiap paket terpasang, dan perbedaan itu menjelaskan mengapa «paketnya bertanda tangan» dan «arsipnya terautentikasi» dipakai bergantian dalam laporan bug padahal keduanya berarti hal berbeda.

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

Baca keluaran pembaruan, bukan hanya kode keluarnya. APT menyebut repositori yang metadatanya gagal, dan nama itu adalah batas yang perlu diselidiki. Repositori yang ditandai tepercaya tanpa verifikasi tanda tangan, atau penimpaan untuk repositori tidak aman, adalah keputusan konfigurasi yang diambil seseorang dan seharusnya bisa dijelaskannya.

Kesegaran lagi-lagi properti tersendiri. Berkas metadata yang bertanda tangan sah bisa lebih tua daripada yang Anda lihat pekan lalu, karena itu metadata rilis membawa tanggal kedaluwarsa dan karena itu masalah jam di klien dapat menghasilkan galat verifikasi yang tampak seperti masalah kunci.

Apa yang diperiksa dnf5 secara terpisah

Sisi RPM menampilkan dua sakelar berbeda, dan mencampuradukkannya menghasilkan kelas kesalahan yang sama ke arah sebaliknya. Satu mengatur apakah berkas paket harus membawa tanda tangan yang sah; yang lain mengatur apakah metadata repositori harus bertanda tangan. Keduanya dapat diatur secara terpisah, dan sebuah sistem bisa ketat pada satu dan longgar pada yang lain.

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

Kueri paket menunjukkan bagaimana metadata tanda tangan salinan terpasang, yang merupakan pemeriksaan kenyataan berguna terhadap berkas konfigurasi yang mengklaim ketat. Yang tidak diberitahukannya adalah kebijakan distribusi yang didukung, dan itulah yang semestinya Anda ikuti alih-alih instruksi umum «aktifkan GPG» dari forum.

Di mana kedua pengelola berbeda, perbedaannya arsitektural dan bukan tanda salah satunya lebih lemah. Keduanya mengautentikasi konten penerbit; keduanya menempatkan tanda tangan di titik berbeda dalam rantai.

Apa yang ditambahkan terowongan dan apa yang tidak

VPN dapat menyediakan rute yang dibutuhkan, menjauhkan lalu lintas pembaruan dari jaringan akses tak tepercaya, dan mengurangi apa yang dilihat pengamat lokal. Itu manfaat operasional nyata, dan tidak satu pun merupakan autentikasi penerbit.

HTTPS menambahkan jaminannya sendiri, dan jaminan itu lebih sempit daripada rasanya. Ia mengautentikasi ujung TLS yang Anda hubungi. Jika ujung itu adalah cermin, Anda mengautentikasi cermin, bukan konten arsip yang disajikannya. Inilah tepatnya kasus yang membuat rantai metadata bertanda tangan ada.

Tak satu pun kendali menjanjikan ketersediaan. Jaringan dapat menolak pengantaran, dan objek yang terautentikasi tidak otomatis yang terbaru. Gunakan kebijakan kesegaran pengelola paket itu sendiri alih-alih menyimpulkannya dari adanya ikon gembok.

Diagnosis batas yang gagal

Sebutkan tahapnya sebelum mengubah apa pun: resolusi DNS, proksi atau rute, identitas ujung TLS, autentikasi arsip, pemeriksaan tanda tangan paket, atau pemasangan. Masing-masing punya bentuk galat dan pemilik yang berbeda.

Memperbaiki jalur jaringan tidak boleh pernah melibatkan menyatakan kunci tanda tangan tak dikenal sebagai tepercaya, mengabaikan sertifikat, atau menerima konfigurasi repositori yang tidak Anda minta. Jika kunci benar-benar dirotasi, distribusi atau pemilik repositori menerbitkan kunci baru lewat kanal yang dapat Anda verifikasi, dan itulah koreksi yang harus diterapkan.

Tuliskan batas mana yang gagal dan siapa pemiliknya. Kegagalan pembaruan berikutnya akan berada di batas lain, dan memiliki daftarnya membuatnya jadi diagnosis lima menit alih-alih perdebatan lain soal apakah terowongan membuat pembaruan aman.