การพิสูจน์ตัวตน HMAC ของแพ็กเก็ต OpenVPN ล้มเหลว: ชั้นไหน?

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

ข้อความระบุชื่อชั้น และงานที่มีประโยชน์คือตัดสินว่าเป็นชั้นใดก่อนจะเปลี่ยนวัสดุใด ๆ การเปรียบเทียบตัวเลือกเคียงข้างกันเป็นวิธีที่เร็วที่สุดในการเห็นความแตกต่าง

ความล้มเหลวสองแบบที่ใช้คำร่วมกัน

ข้อผิดพลาดในการพิสูจน์ตัวตนแพ็กเก็ตเกิดขึ้นระหว่างประมวลผลทราฟฟิก แท็กหรือไดเจสต์บนแพ็กเก็ตที่รับเข้ามาไม่ตรงกับสิ่งที่ผู้รับคำนวณไว้ การปฏิเสธบัญชีเกิดขึ้นหลังจากแยกวิเคราะห์การแลกเปลี่ยนการเข้าสู่ระบบแล้ว และระบุชื่อผู้ใช้แทนที่จะเป็นแพ็กเก็ต ข้อความที่สามเกี่ยวกับการค้นหา HMAC ในแพ็กเก็ตขาเข้าไม่พบนั้นต่างออกไปอีก เพราะแพ็กเก็ตมาถึงโดยไม่มีองค์ประกอบพิสูจน์ตัวตนที่คาดไว้เลย คำนำหน้าบันทึกแบบเต็มบอกคุณว่าคุณมีหนึ่งในสามแบบใด และคำนำหน้ามักเป็นสิ่งแรกที่ถูกตัดออกเมื่อวางข้อผิดพลาดลงในตั๋ว

ความแตกต่างนี้เปลี่ยนวิธีซ่อมแซม แบบหนึ่งต้องตั้งค่าช่องสัญญาณให้ตรงกัน อีกแบบต้องดูสถานะบัญชี และแบบที่สามต้องดูโปรไฟล์ที่ไม่ตรงกับตัวรับฟังที่มันไปถึง

เปรียบเทียบสิ่งที่โปรเซสที่กำลังทำงานโหลดไว้จริง

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

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

เปรียบเทียบช่องสัญญาณควบคุมกับช่องสัญญาณข้อมูล

กลไกสองอย่างพิสูจน์ตัวตนส่วนต่าง ๆ ของการเชื่อมต่อและถูกกำหนดค่าแยกกัน ตามที่ เอกสารอ้างอิงตัวเลือก 2.6 อธิบายไว้ tls-auth เพิ่ม HMAC ให้แพ็กเก็ตของช่องสัญญาณควบคุมและรับอาร์กิวเมนต์ทิศทางซึ่งต้องตรงข้ามกันบนสองฝั่ง ขณะที่ tls-crypt ปกป้องช่องสัญญาณควบคุมด้วยกุญแจที่แชร์ร่วมกันแทน ทั้งสองไม่ใช่การตรวจสอบความสมบูรณ์ของช่องสัญญาณข้อมูลเอง เมื่อใช้ชุดรหัสข้อมูลแบบ AEAD การตรวจสอบนั้นถูกสร้างไว้ในชุดรหัสแล้ว ดังนั้นไดเจสต์ auth แยกต่างหากจึงไม่ถูกใช้แบบเดียวกับชุดรหัสที่ไม่ใช่ AEAD

นั่นหมายความว่าบรรทัด auth ที่คัดลอกจากระบบที่ไม่ใช่ AEAD ซึ่งทำงานอยู่ อาจไม่เกี่ยวข้องในระบบ AEAD และระบบ AEAD ก็ยังล้มเหลวที่ช่องสัญญาณควบคุมได้หากกุญแจ tls-auth หรือทิศทางของมันผิด เปรียบเทียบการตั้งค่าแต่ละอย่างกับอีกฝั่ง ไม่ใช่กับค่าที่จำไว้

เปรียบเทียบการแก้ไขกับคุณสมบัติที่คุณยอมสละ

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

อ่านเหตุการณ์แรกที่เกี่ยวข้องบนทั้งสองฝั่งก่อนเปลี่ยนแปลงสิ่งใด แล้วแก้เฉพาะความไม่ตรงกันที่มันระบุ

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