auth digest ปกป้องแพ็กเก็ต OpenVPN แพ็กเก็ตใด
ตัวเลือก auth ครอบคลุมน้อยกว่าที่โปรไฟล์บ่งชี้ ไล่ดูแชนเนล กรณี AEAD และการป้องกันแชนเนลควบคุมก่อนกำหนดนโยบาย digest
การถกเถียงเรื่อง digest ของ OpenVPN ส่วนใหญ่เริ่มจากแพ็กเก็ตผิดตัว การอ่าน auth SHA256 ว่า “รับเฉพาะพีร์ที่เสนอ SHA256” คือสิ่งแรกที่ต้องเลิกทำ ตัวเลือกนี้ระบุ digest สำหรับแพ็กเก็ตบางชนิด และแพ็กเก็ตเหล่านั้นคืออะไรขึ้นอยู่กับแชนเนลและขึ้นอยู่กับว่าแชนเนลนั้นเป็น AEAD หรือไม่ ไล่ดูคำถามสี่ข้อด้านล่างตามลำดับ แต่ละข้อจะจำกัดความหมายที่การตั้งค่านี้มีได้ในการติดตั้งของคุณ
ระบุแชนเนลที่การตั้งค่าตั้งใจจะป้องกัน
OpenVPN มีแชนเนลควบคุมที่ขนส่งทราฟฟิกการจับมือ TLS และแชนเนลข้อมูลที่ขนส่งเพย์โหลดของทันเนล digest ของ auth มีบทบาทในทั้งสอง แต่ไม่ใช่บทบาทเดียวกัน และโปรไฟล์แทบไม่ทำให้เห็นความต่าง เขียนไว้ก่อนแตะไฟล์กำหนดค่าว่าคุณกำลังจำกัดอันไหนในสองอันนี้
ตารางด้านล่างคือฉบับย่อของการที่ตัวเลือกเดียวกันไปลงเอยในแต่ละบริบท
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
ตรวจว่าแชนเนลข้อมูลเป็น AEAD หรือไม่ก่อนพึ่งพามัน
ถ้าไซเฟอร์ข้อมูลที่เจรจาได้คือ AES-GCM หรือ CHACHA20-POLY1305 แชนเนลข้อมูลจะพิสูจน์ตัวตนด้วยตัวเอง และ digest แยกไม่ได้ทำงานที่คุณอาจนึกภาพไว้ ทั้งสองเป็นโครงสร้าง AEAD ความสมบูรณ์จึงเกิดจากปฏิบัติการเดียวกับการเข้ารหัสเพย์โหลด นี่ไม่ใช่การลดระดับ แต่หมายความว่านโยบายที่ให้เหตุผลว่า “ทุกแพ็กเก็ตข้อมูลเป็น HMAC-SHA256” นั้นผิดจริงบนทันเนลนั้น ยืนยันค่าที่เจรจาได้ในบันทึกของเซิร์ฟเวอร์หรือเอาต์พุตสถานะของไคลเอนต์ก่อนเขียนนโยบายใหม่
ตรวจดูไซเฟอร์ที่เจรจาได้จริงแทนรายการในโปรไฟล์ เพราะการเจรจาอาจไปลงที่สมาชิกอีกตัวของชุด data-ciphers AES-256-GCM:AES-128-GCM เป็นรายการเจรจา และทั้งสองรายการเป็น AEAD จึงไม่มีตัวใดใช้ digest ของ auth เพื่อป้องกันเพย์โหลด
ถือว่าการป้องกันแชนเนลควบคุมเป็นการตัดสินใจแยกต่างหาก
tls-auth เพิ่ม HMAC ให้แพ็กเก็ตของแชนเนลควบคุมและรับ digest จากค่าตั้ง auth จึงเป็นเหตุให้ทันเนล AEAD ยังมีการตั้ง digest ที่มีความหมายได้ tls-crypt เป็นการจัดวางอีกแบบที่มีการป้องกันตายตัวของตัวเอง อย่าสันนิษฐานว่ามันสืบทอดทุกคุณสมบัติของ tls-auth อ่านเอกสารของกลไกที่คุณเลือกแทนการย้ายข้อสันนิษฐานระหว่างกัน
พีร์ทั้งสองต้องตกลงกันเรื่องการจัดวางและทิศทางของคีย์ด้วย digest ที่ตรงกันแต่ไฟล์คีย์ถูกใช้ผิดทิศจะทำให้การจับมือล้มเหลวด้วยเหตุที่การตั้ง digest อธิบายไม่ได้
แยก auth ออกจากการเจรจาไซเฟอร์และใบรับรอง
มีการสับสนค่าตั้งสามอย่างตลอดเวลา คือ digest ของ auth รายการไซเฟอร์ข้อมูล และอัลกอริทึมลายเซ็นของใบรับรอง การเปลี่ยนอย่างแรกไม่ทำให้ออกใบรับรองใหม่ ไม่เลือก digest สำหรับลายเซ็น และไม่สร้างวิธีผู้ใช้-รหัสผ่าน คำนิยามของตัวเลือกโปรโตคอลใน ซอร์ส OpenVPN 2.6 อธิบายแต่ละอย่างในหัวข้อของตัวเอง ซึ่งเป็นเครื่องเตือนใจที่มีประโยชน์ว่ามันเป็นปุ่มที่แยกจากกัน
เมื่อพีร์ปฏิเสธเชื่อมต่อหลังเปลี่ยน digest สาเหตุปกติคือความไม่ตรงกันในการตั้งอีกสองอย่าง อ่านทั้งสองฝั่งก่อนเปลี่ยนอย่างใดอย่างหนึ่ง
เขียนนโยบายลงไปและเทียบกับการกำหนดค่าที่กำลังทำงาน
ถ้อยแถลงระดับฟลีตควรระบุโหมดแชนเนลข้อมูลที่อนุญาตและการป้องกันแชนเนลควบคุมที่เลือกไว้อย่างชัดเจนในประโยคเดียวกัน ประโยคนั้นทดสอบได้ ส่วน “เราใช้ SHA256” ทดสอบไม่ได้ จากนั้นเทียบกับโปรไฟล์เซิร์ฟเวอร์และไคลเอนต์ที่ได้ผลจริง ไม่ใช่เทมเพลตในคลัง
ปิดท้ายด้วยการบันทึกว่าแต่ละทันเนลเจรจาอะไรจริงและกลไกใดพิสูจน์ตัวตนแพ็กเก็ตของมัน บรรทัด auth ที่เห็นในโปรไฟล์เป็นเพียงหลักฐานเจตนาของการกำหนดค่า และเจตนาคือส่วนที่ถูกที่สุดของการตรวจ