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 การยืนยันคลัง การตรวจสอบลายเซ็นแพ็กเกจ หรือการติดตั้ง แต่ละอย่างมีรูปแบบข้อผิดพลาดและเจ้าของที่ต่างกัน

การซ่อมเส้นทางเครือข่ายไม่ควรเกี่ยวข้องกับการประกาศว่าคีย์ลายเซ็นที่ไม่รู้จักนั้นเชื่อถือได้ การเพิกเฉยต่อใบรับรอง หรือการยอมรับการกำหนดค่าคลังที่คุณไม่ได้ขอ ถ้าคีย์ถูกหมุนจริง ผู้เผยแพร่ดิสทริบิวชันหรือเจ้าของคลังจะเผยแพร่คีย์ใหม่ผ่านช่องทางที่คุณตรวจสอบได้ และนั่นคือการแก้ไขที่ต้องนำไปใช้

เขียนว่าขอบเขตใดล้มเหลวและใครเป็นเจ้าของ มันจะเกิดความล้มเหลวในการอัปเดตครั้งถัดไปที่ขอบเขตอื่น และการมีรายการนี้ทำให้มันกลายเป็นการวินิจฉัยห้านาทีแทนการโต้เถียงอีกครั้งว่าอุโมงค์ทำให้การอัปเดตปลอดภัยหรือไม่