TLS VPN กับ IPsec: ห้าฟิลด์ที่ควรตรวจสอบ
เปรียบเทียบ TLS VPN และ IPsec VPN ตามรุ่นซอฟต์แวร์ เวอร์ชันโปรโตคอล ชุดป้องกัน ตัวตนของเพื่อนร่วม และขอบเขตที่เปิดเผย รวมถึงผลลัพธ์ความล้มเหลวที่คุณกำหนดค่าไว้จริง
การจัดอันดับ TLS VPN เทียบกับ IPsec VPN ตามตระกูลโปรโตคอลตอบคำถามที่ไม่มีใครถาม และมักอ้างถึงโครงสร้างที่ทั้งสองตระกูลเลิกใช้ไปหลายปีแล้ว สิ่งที่ผู้ตรวจสอบประเมินได้จริงคือการป้องกันที่เจรจากัน ตัวตนของเพื่อนร่วม โมเดลไคลเอนต์ และบริการที่เปิดเผย สี่สิ่งนี้มองเห็นได้ในการติดตั้ง และไม่มีสิ่งใดมาจากฉลากผลิตภัณฑ์ ขอห้าฟิลด์แล้วบทสนทนาจะเป็นรูปธรรม
ห้าฟิลด์ และฉลากไม่ใช่หนึ่งในนั้น
ฟิลด์แรกคือรุ่นซอฟต์แวร์ที่รองรับ เพราะคำอธิบายโปรโตคอลที่ไม่มีเวอร์ชันเป็นเพียงแผ่นพับ ฟิลด์ที่สองคือเวอร์ชันโปรโตคอลที่เจรจากัน ซึ่งตัดสินว่าโครงสร้างใดมีให้ใช้ ฟิลด์ที่สามคือชุดป้องกัน ฟิลด์ที่สี่คือวิธีรับรองความถูกต้องสำหรับทั้งเพื่อนร่วมและผู้ใช้ และฟิลด์ที่ห้าคือขอบเขตการเข้าถึงที่ผลิตภัณฑ์ให้หลังการรับเข้า
ฉลาก SSL VPN ครอบคลุมผลิตภัณฑ์ต่างกันอย่างน้อยสามแบบ คือไคลเอนต์เครือข่ายเต็มรูปแบบ พร็อกซีแอปพลิเคชัน และพอร์ทัลเก่าที่ใช้เบราว์เซอร์ สิ่งเหล่านี้เปิดเผยบริการต่างกันและล้มเหลวต่างกัน ฉลากจึงแทนฟิลด์ขอบเขตไม่ได้
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
การเข้ารหัสที่รับรองความถูกต้องเปลี่ยนอะไรจริง
TLS 1.3 กำหนดให้ใช้การเข้ารหัสที่รับรองความถูกต้อง ซึ่งถอดโครงสร้าง MAC-then-encrypt แบบเก่าออกจากโปรโตคอลแทนที่จะปล่อยเป็นทางเลือก IPsec ESP ก็มีชุดการเข้ารหัสที่รับรองความถูกต้องมานานเท่ากัน โดย AES-GCM ถูกกำหนดใน RFC ของตัวเอง ในทั้งสองตระกูลการรับประกันมาจากชุดที่เจรจากัน ไม่ใช่ชื่อตระกูล จึงเป็นเหตุให้รายการฟิลด์เริ่มด้วยเวอร์ชัน ผู้ตรวจสอบที่บอกชื่อชุดไม่ได้ก็ไม่มีอะไรให้ประเมิน
นั่นคือเหตุผลที่การเปรียบเทียบเชิงประวัติศาสตร์ทำให้เข้าใจผิด การติดตั้งที่ตรึงกับ TLS รุ่นเก่าด้วยชุด CBC และอีกระบบที่รัน TLS 1.3 ด้วยชุด AEAD ไม่ใช่ท่าทีความปลอดภัยเดียวกัน แม้ทั้งคู่จะเป็น TLS VPN การแบ่งเดียวกันนี้มีอยู่ฝั่ง IPsec ระหว่างชุด ESP สมัยใหม่กับชุดผสมแบบเก่า
อ่านค่าที่เจรจากัน ไม่ใช่การกำหนดค่าที่คุณตั้งใจ คำสั่งด้านล่างแสดงสิ่งที่ปลายทางที่ทำงานอยู่และอุโมงค์ที่ทำงานอยู่ตกลงกันจริง
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasหากปลายทางไม่ยอมเจรจา TLS 1.3 นั่นคือข้อค้นพบ ไม่ใช่ความชอบ หากอุโมงค์แสดงชุดที่คุณไม่ได้คาดไว้ การกำหนดค่าที่สำคัญคือชุดที่เพื่อนร่วมเลือก ไม่ใช่ชุดในแม่แบบ
ตัวตนของเพื่อนร่วมเป็นคำถามแยกต่างหาก
การเข้ารหัสโดยไม่มีเพื่อนร่วมที่ตรวจสอบแล้วปกป้องทราฟฟิกจากผู้สังเกตและมอบให้ผู้ที่ตอบการเชื่อมต่อ การรับรองเพื่อนร่วมถามว่าคาดหวังตัวตนใด วัสดุความเชื่อถือใดตรวจสอบตัวตนนั้น และไคลเอนต์ทำอย่างไรเมื่อคำตอบไม่ตรงกัน ห่วงโซ่ใบรับรอง คีย์ที่ปักหมุด และความลับที่แบ่งปันล่วงหน้าเป็นสามคำตอบที่ต่างกันด้วยต้นทุนการดำเนินงานที่ต่างกัน
จากนั้นถามคำถามเดียวกันเกี่ยวกับผู้ใช้หรืออุปกรณ์ เกตเวย์ที่รับรองเครื่องและรับผู้ใช้ใดก็ได้ หรือกลับกัน มีท่าทีเฉพาะที่ควรเขียนไว้ไม่ใช่สันนิษฐาน สิทธิ์ทรัพยากรที่ใช้หลังการรับเข้าเป็นส่วนหนึ่งของฟิลด์เดียวกัน เพราะการรับรองความถูกต้องไม่ใช่การอนุญาต
การรักษาการตรวจสอบชื่อโฮสต์และใบรับรองสำคัญกว่าความคุ้นเคยของหน้าต่างเข้าสู่ระบบ ไคลเอนต์ที่กำหนดให้เพิกเฉยการตรวจสอบได้ถอดขั้นตอนเดียวที่แยกเกตเวย์ของคุณจากการเลียนแบบที่น่าเชื่อถือ
ขอบเขตที่ผลิตภัณฑ์เปิดเผย
พอร์ทัลที่ไม่ต้องใช้ไคลเอนต์พร็อกซีการดำเนินการแอปพลิเคชันที่เลือกผ่านเกตเวย์ ผู้ใช้จึงเข้าถึงอินเทอร์เฟซไม่ใช่เครือข่าย ไคลเอนต์อุโมงค์เต็มรูปแบบพาสิ่งที่เส้นทางและนโยบายการกรองเลือก ซึ่งเป็นพื้นที่ผิวใหญ่กว่ามาก การเปรียบเทียบทั้งสองด้วยความแข็งแกร่งของโปรโตคอลพลาดความแตกต่างในสิ่งที่ผู้โจมตีเข้าถึงได้ผ่านทั้งสอง ฝ่ายหนึ่งเปิดอินเทอร์เฟซแอปพลิเคชัน อีกฝ่ายเปิดเครือข่ายที่กำหนดเส้นทาง และทั้งสองต้องการการตรวจสอบต่างกัน
ถามว่าบริการใดเปิดเผย การดำเนินการใดได้รับอนุญาต และเกตเวย์เองฟังสิ่งใด อินเทอร์เฟซการจัดการที่เข้าถึงได้จากที่อยู่เดียวกับพอร์ทัลผู้ใช้เป็นข้อค้นพบด้านการติดตั้ง และไม่มีตัวเลือกโปรโตคอลใดชดเชยได้
ขอบเขตต่อแอปพลิเคชันทำให้พื้นที่ผิวแคบลงอีก และเปลี่ยนพฤติกรรมความล้มเหลวเมื่ออุโมงค์ล่ม การออกแบบที่สันนิษฐานการเข้าถึงแบบอุโมงค์เต็มจะแตกในแบบที่การออกแบบต่อแอปไม่รู้จัก และภาระสนับสนุนจะตามมา
ตัดสินใจผลลัพธ์ความล้มเหลวและวงจรชีวิต
สิ่งที่เกิดขึ้นเมื่อการรับรองหรือการป้องกันไม่พร้อมใช้งานเป็นการตัดสินเชิงนโยบายที่อยู่ในขอบเขตการตรวจสอบ ผลลัพธ์ที่ถูกบล็อกและการถอยกลับโดยตรงที่ไม่ประกาศมีผลต่างกัน และความแตกต่างมองไม่เห็นในรายการคุณสมบัติ ระบุพฤติกรรมที่ตั้งใจไว้ข้างทรัพยากรที่มันปกป้อง
รวมวงจรชีวิตการแพตช์และการสนับสนุนของเกตเวย์ คุณสมบัติภายนอกที่เปิดใช้งาน และเส้นทางการอัปเดตสำหรับไคลเอนต์ การเลือกโปรโตคอลที่ถูกต้องไม่ได้ทำให้บริการที่ติดตั้งไม่ดีปลอดภัย และเหตุการณ์ส่วนใหญ่อาศัยอยู่ในช่องว่างนั้นไม่ใช่ในชุดป้องกัน
เขียนห้าฟิลด์ นโยบายความล้มเหลว และเจ้าของวงจรชีวิตลงในหน้าเดียว หน้านั้นคือการตรวจสอบ ส่วนการเปรียบเทียบตระกูลโปรโตคอลคือความเห็น