ทำไม AES-256 จึงไม่ได้อธิบายชุดการเข้ารหัสของ VPN
ชุดหนึ่งทำหน้าที่สี่อย่าง: การเข้ารหัสจำนวนมาก ความสมบูรณ์ การสร้างกุญแจ และการยืนยันตัวตนของคู่สนทนา ชื่อของรหัสครอบคลุมเพียงหนึ่งในนั้น ในชั้นเดียว
ถามว่า VPN ใช้การเข้ารหัสอะไร คำตอบมักมาเป็นคำเดียว: AES-256 หรือ ChaCha20 หรืออาจจะเป็น WireGuard คำตอบนั้นบอกชื่อองค์ประกอบหนึ่งของชั้นหนึ่ง ขณะที่สิ่งที่ปกป้องการเชื่อมต่อจริง ๆ คือชุดอัลกอริทึมที่ทำหน้าที่สี่อย่างต่างกัน การสับสนระหว่างองค์ประกอบกับโครงสร้างเป็นข้อผิดพลาดที่พบบ่อยที่สุดในการสนทนาเหล่านี้ และทำให้เกิดการเปรียบเทียบที่หาข้อยุติไม่ได้
สี่งานภายในหนึ่งการเชื่อมต่อ
การเข้ารหัสจำนวนมากเปลี่ยนข้อความธรรมดาเป็นข้อความเข้ารหัสสำหรับช่องทางข้อมูล และกุญแจของมันถูกสร้างขึ้นแทนที่จะส่งไป การป้องกันความสมบูรณ์ตรวจจับการเปลี่ยนแปลง ซึ่งเป็นงานแยกต่างหากแม้โครงสร้างเดียวจะทำทั้งสองอย่าง การสร้างกุญแจผลิตวัสดุการรับส่งที่ใช้ร่วมกัน และการยืนยันตัวตนของคู่สนทนาตัดสินว่าใครอยู่อีกฝั่ง หากขาดอย่างใดอย่างหนึ่ง การเชื่อมต่อก็ไม่ปลอดภัย ไม่ว่าส่วนที่เหลือจะแข็งแรงเพียงใด
การออกแบบบางแบบรวมสองบทบาทเป็นหนึ่งเดียว AES-GCM และ ChaCha20-Poly1305 เป็นโครงสร้างการเข้ารหัสที่ผ่านการยืนยัน ดังนั้นความลับและความสมบูรณ์มาพร้อมกัน ส่วน AES-CBC ไม่เป็นเช่นนั้น และต้องใช้รหัสยืนยันข้อความแยกต่างหากที่มีกุญแจของตัวเอง ดังนั้นการอ่านข้อเสนอเป็นถุงตัวเลขอิสระจึงอ่านสิ่งที่ออกแบบเป็นคู่ผิด
บทบาทยังอยู่คนละชั้น จึงเป็นเหตุให้คำเดียวกันอาจหมายถึงสิ่งต่างกันในสองผลิตภัณฑ์ การเข้ารหัสบล็อกใน ESP และการเข้ารหัสบล็อกใน TLS เป็นองค์ประกอบพื้นฐานเดียวกันในการเจรจาต่างกันด้วยข้อกำหนดต่างกัน ดังนั้นการอ้างถึงองค์ประกอบพื้นฐานโดยไม่มีโหมดและชั้นของมันอาจแย่กว่าการไม่อ้างถึงอะไรเลย
ทำไมชื่อรหัสจึงแทบไม่บอกอะไร
ลองพิจารณาวลี AES-256 อย่างจริงจังสักครู่: มันระบุการเข้ารหัสบล็อกและขนาดกุญแจ มันไม่บอกอะไรเกี่ยวกับโหมดการทำงาน ไม่บอกว่ามีความสมบูรณ์หรือไม่ ไม่บอกว่ากุญแจถูกสร้างอย่างไรหรือคู่สนทนาถูกยืนยันอย่างไร สองผลิตภัณฑ์สามารถโฆษณา AES-256 ทั้งคู่และแตกต่างในทุกอย่างอื่น รวมถึงแบบหนึ่งที่จับคู่กับโหมดที่ไม่ผ่านการยืนยันและอีกแบบที่ใช้โหมด AEAD พร้อมการแลกกุญแจที่ทันสมัย
TLS 1.3 นำการแยกนี้เข้าสู่มาตรฐาน ซึ่งเป็นการแก้ไขที่เป็นประโยชน์สำหรับทุกคนที่เรียนรู้คำศัพท์แบบเก่า ชุดรหัสของมันระบุเฉพาะ AEAD และแฮช ขณะที่กลุ่มแลกเปลี่ยนกุญแจและอัลกอริทึมลายเซ็นถูกเจรจาเป็นพารามิเตอร์แยกต่างหาก ดังนั้นชื่อชุด TLS 1.3 จึงเทียบกับชื่อชุด TLS 1.2 ไม่ได้บนพื้นฐานเดียวกัน แม้ทั้งสองจะปรากฏในฟิลด์เดียวกันของไฟล์กำหนดค่า ผู้ตรวจสอบที่เปรียบเทียบสองสตริงโดยตรงจะได้ข้อสรุปที่โปรโตคอลไม่รองรับ อ่านกลุ่มที่เจรจาและพารามิเตอร์ลายเซ็นด้วย มิฉะนั้นการเปรียบเทียบจะไม่สมบูรณ์
WireGuard เลือกทางตรงกันข้ามและเกือบจะขจัดการเจรจาออกทั้งหมด: โปรโตคอลกำหนดชุดอัลกอริทึมตายตัว ดังนั้นสองการใช้งานจะทำงานร่วมกันหรือไม่ก็ไม่ นี่เป็นทางเลือกการออกแบบที่ชอบด้วยกฎหมาย และยังหมายความว่าคำถามที่ว่า WireGuard เจรจาชุดใดไม่มีคำตอบที่คุ้มค่าแก่การเปรียบเทียบ หากคุณกำลังตรวจสอบมัน อ่านข้อกำหนดสักครั้งแล้วตรวจสอบการจัดการกุญแจรอบ ๆ แทนการเจรจา
ชั้นเป็นตัวกำหนดคำศัพท์
การติดตั้ง IPsec เจรจาสองครั้ง: ข้อเสนอ IKE สำหรับช่องทางควบคุมและการแปลง ESP สำหรับข้อมูล และทั้งสองสามารถแตกต่างกันได้ตามกฎหมาย การอ่านอันแรกแล้วถือว่าอธิบายอันที่สองเป็นแหล่งความสับสนทั่วไประหว่างการตรวจสอบ เพราะไฟล์กำหนดค่าระบุทั้งสองและอันที่น่าสนใจคืออันที่สอง
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
ชื่อที่ใช้ได้ในไลบรารีหนึ่งไม่ได้ถูกนำไปใช้โดยอัตโนมัติสำหรับเส้นทางข้อมูลอื่น ดังนั้นข้อกล่าวอ้างว่าผลิตภัณฑ์ของเรารองรับ AES-256 จึงอ่อนกว่าที่ฟัง และนั่นคือเหตุผลที่ปัญหาการทำงานร่วมกันมักแก้ไขด้วยการหาจุดตัดที่ยังดูแลอยู่ แทนการเปิดอัลกอริทึมเก่าทั้งหมดทั้งสองฝั่ง
ข้อกำหนด TLS 1.3 เป็นตัวอย่างที่เผยแพร่ชัดเจนที่สุดของการแยกนี้ เพราะมันนิยามชุดเป็นคู่และย้ายส่วนที่เหลือไปยังการเจรจาของตัวเอง เมื่อรูปแบบนั้นคุ้นเคย ข้อเสนอ IPsec และชุดตายตัวชุดเดียวของ WireGuard จะอ่านเป็นรูปแบบต่าง ๆ ของแนวคิดเดียวกัน
อ่านผลลัพธ์ที่เจรจาแล้ว แล้วหยุด
ข้อเสนอที่กำหนดค่าไว้ไม่ใช่หลักฐานว่าสองฝ่ายเลือกอะไร เซสชันที่ยังมีชีวิตเป็นผู้ถือคำตอบ และการใช้งานกระแสหลักใด ๆ ก็รายงานได้โดยไม่ต้องดักจับแพ็กเก็ต
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showในผลลัพธ์ ให้อ่านอัลกอริทึมที่เลือกไม่ใช่รายการที่เสนอ หากคำตอบอ่อนกว่าที่นโยบายตั้งใจ การแก้ไขอยู่ที่การกำหนดค่าข้อเสนอของฝ่ายใดฝ่ายหนึ่ง และความไม่ตรงกันในการใช้งานสมัยใหม่มักปรากฏเป็นการเจรจาที่ล้มเหลวไม่ใช่การลดลงอย่างเงียบ ๆ
จากนั้นจำไว้ว่าชุดไม่ได้ครอบคลุมอะไร เส้นทาง สิทธิ์ของแอป การบันทึก และการเก็บรักษาเป็นการตัดสินใจแยกต่างหากที่มีการทบทวนของตัวเอง และการจัดวางการเข้ารหัสที่เข้ากันได้ไม่บอกอะไรเกี่ยวกับสิ่งเหล่านั้น การถกเถียงเรื่องรหัสนั้นคุ้มค่า แต่ตอบคำถามที่แคบกว่าคำถามที่คนส่วนใหญ่ถามจริง ๆ
รักษาคำศัพท์ให้แม่นยำแล้วข้อโต้แย้งจะสั้นลง ชุดคือกลุ่มบทบาทบนชั้นหนึ่ง รหัสคือองค์ประกอบหนึ่ง และผลลัพธ์ที่เจรจาคือสิ่งเดียวที่อธิบายการเชื่อมต่อที่คุณมีจริง ๆ ส่วนที่เหลือในการเปรียบเทียบเป็นเพียงการตกแต่ง