tls-auth กับ tls-crypt: แต่ละตัวปกป้องอะไรใน OpenVPN

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

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

คีย์ร่วมปกป้องอะไรจริง ๆ

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

tls-auth ใช้ความลับนั้นคำนวณ HMAC บนแพ็กเก็ตควบคุม แพ็กเก็ตที่ไม่มีลายเซ็นที่ถูกต้องจะถูกทิ้งก่อนถึงการประมวลผล TLS ที่แพงกว่า จึงมักอธิบายตัวเลือกนี้ว่าเป็นตัวกรองแรก ไม่ใช่ตัวแทนของ TLS

tls-crypt ไปไกลกว่านั้นโดยเข้ารหัสทราฟฟิกควบคุมที่ได้รับการป้องกันนอกเหนือจากการพิสูจน์ตัวตน เนื้อหาใบรับรอง ชื่อรหัสที่เจรจากัน และรายละเอียดแฮนด์เชกอื่น ๆ ไม่ปรากฏบนเครือข่ายอีกต่อไป และผู้สังเกตที่ไม่มีคีย์ก็ไม่เห็นแม้แต่จะรู้ว่ากำลังลอง TLS เวอร์ชันใด สำหรับการติดตั้งที่กลัวการเปิดเผยลายนิ้วมือ VPN คุณสมบัตินี้คือเหตุผลหลักในการเลือกใช้ มันยังเป็นความลับของกลุ่ม ไม่ใช่ข้อมูลรับรองรายผู้ใช้

ไม่มีกลไกใดออกตัวตน คีย์ร่วมเป็นความลับของกลุ่ม และใครก็ตามที่มีคีย์ก็ผ่านชั้นการตรวจสอบนั้นได้

สองตัวเลือกต่างกันตรงไหน

ความต่างที่สังเกตได้คือสิ่งที่ผู้สังเกตเห็น เมื่อใช้ tls-auth แฮนด์เชกมองเห็นได้แต่ตรวจสอบไม่ได้หากไม่มีคีย์ เมื่อใช้ tls-crypt แฮนด์เชกจะทึบแสงสำหรับใครก็ตามที่ไม่มีคีย์

การกำหนดค่าก็ต่างกัน tls-auth ใช้กับค่าทิศทาง ดังนั้นฝั่งหนึ่งใช้ครึ่งหนึ่งของวัสดุคีย์และอีกฝั่งใช้อีกครึ่ง tls-crypt ใช้คีย์เดียวในทั้งสองทิศทาง คำสั่งทิศทางจึงไม่ใช่ส่วนหนึ่งของโครงสร้าง

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

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

ทำไมความไม่ตรงกันดูเหมือนไม่มีอะไรเกิดขึ้น

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

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

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

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

สิ่งที่ยังต้องกำหนดค่าแยกต่างหาก

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

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

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