บันทึก OpenVPN: ไซเฟอร์ของช่องทางควบคุมกับไซเฟอร์ของช่องทางข้อมูล

บรรทัดบันทึกที่ระบุ DHE-RSA-AES256-SHA ไม่ใช่บทสรุปของการเชื่อมต่อทั้งหมด มันเป็นของการจับมือ TLS ที่ปกป้องช่องทางควบคุม และทราฟฟิกภายในอุโมงค์อาจถูกเข้ารหัสด้วยวิธีที่แตกต่างไปทั้งหมด การนำเสนอเป็นไซเฟอร์ข้อมูลของ VPN คือข้อผิดพลาดที่ต้องหลีกเลี่ยง

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

สองผลลัพธ์ สองคำถาม

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

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

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

ถอดรหัสชื่อชุด TLS ในบริบทของมันเอง

ในชื่อแบบ OpenSSL เชิงประวัติศาสตร์เช่น DHE-RSA-AES256-SHA แต่ละองค์ประกอบอธิบายการตัดสินใจที่ต่างกัน DHE คือข้อตกลงคีย์ Diffie-Hellman แบบชั่วคราว RSA คือวิธีการพิสูจน์ตัวตน AES256 คือ AES-256 ในโหมด CBC สำหรับระเบียน TLS และ SHA คือ MAC ของระเบียนที่อิง SHA-1

องค์ประกอบสุดท้ายไม่ใช่ลายนิ้วมือของใบรับรอง และการอ่านเช่นนั้นเป็นข้อผิดพลาดทั่วไป ชื่อไม่ได้บ่งบอกเวอร์ชันโปรโตคอลด้วยตัวเอง เพราะ TLS 1.3 ใช้รูปแบบการตั้งชื่อที่ต่างออกไปทั้งหมด TLS_AES_256_GCM_SHA384 ตามรูปแบบใหม่นั้น ซึ่งแฮชท้ายเป็นส่วนหนึ่งของการสร้างชุด ไม่ใช่การเลือก MAC ใช้การอ่านตามองค์ประกอบกับรูปแบบการตั้งชื่อแบบเก่าเท่านั้น

เอกสารอ้างอิงชุด OpenSSL เชื่อมชื่อเหล่านี้กับคำจำกัดความหากองค์ประกอบใดไม่คุ้นเคย

อ่านผลลัพธ์ของช่องทางข้อมูลสำหรับทราฟฟิกที่ขนส่ง

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

ไซเฟอร์ AEAD เช่น AES-GCM มีการตรวจสอบความสมบูรณ์ของตัวเอง ดังนั้น HMAC แยกของช่องทางข้อมูลจึงไม่ใช่ส่วนหนึ่งของเส้นทางนั้น

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

แยกการตรวจสอบตัวตนออกจากผลลัพธ์ของไซเฟอร์

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

เก็บการตรวจสอบเหล่านี้ไว้ในบันทึกการทบทวนข้างผลลัพธ์ของไซเฟอร์ ไม่ใช่หลอมรวมเข้าไป

บันทึกผลลัพธ์ที่เจรจาของเซสชันปัจจุบัน

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

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