การเข้ารหัสจากต้นทางถึงปลายทางเป็นชั้นป้องกันเพิ่มเติม ไม่ใช่ใบอนุญาตให้เพิกเฉยต่อคำเตือน TLS หรือเชื่อถือโค้ดที่ถูกแก้ไข
TLS และการเข้ารหัสจากต้นทางถึงปลายทางสร้างขอบเขตสองแบบที่ต่างกัน ขอบเขตเหล่านี้สำคัญต่อการประเมิน VPN และพร็อกซีเช่นกัน โดยทั่วไป TLS ปกป้องการเชื่อมต่อระหว่างอุปกรณ์ของคุณกับบริการ ส่วนการเข้ารหัสจากต้นทางถึงปลายทางที่ถูกต้องและผ่านการยืนยันความแท้จะปกป้องเนื้อหาการสนทนาไปจนถึงอุปกรณ์ผู้รับ การอ่านชั้น TLS ได้ไม่ได้แปลว่าจะอ่านเนื้อหาที่เข้ารหัสจากต้นทางถึงปลายทางได้เสมอไป แต่ก็ไม่ควรสรุปจากข้อเท็จจริงนี้ว่าความปลอดภัยของ TLS ไม่สำคัญอีกต่อไป
หากตัวกลางสามารถเป็นจุดสิ้นสุดของการเชื่อมต่อที่ปลอดภัยได้ นอกจากจะเห็นข้อมูลที่ส่งผ่านแล้ว ยังอาจแก้ไขคำตอบหรือโค้ดของเว็บแอปได้ด้วย ด้วยเหตุนี้ คำว่า “ข้าม TLS ด้วย LVR1” จึงไม่ใช่คำอธิบายความปลอดภัยของแอปส่งข้อความที่เหมาะสม
ใบรับรองรากทำให้การตรวจสอบเป็นไปได้อย่างไร?
ในการเชื่อมต่อ HTTPS อุปกรณ์จะตรวจสอบสายโซ่ใบรับรองของเซิร์ฟเวอร์และชื่อโฮสต์ หากตัวกลางแสดงใบรับรองที่แอปยอมรับว่าถูกต้อง ตัวกลางอาจสร้างการเชื่อมต่อแยกกันสองชุด ชุดหนึ่งกับผู้ใช้และอีกชุดกับเซิร์ฟเวอร์จริง ในกรณีนี้ ตัวกลางเป็นปลายทางของการเชื่อมต่อ TLS ชุดหนึ่ง ไม่ใช่ผู้ดักฟังที่ถอดการเข้ารหัสได้เพียงแค่มองแพ็กเก็ต
การติดตั้งใบรับรองใดก็ได้เพียงอย่างเดียวไม่พอ แอปต้องเชื่อถือใบรับรองนั้น และการตรวจสอบการเชื่อมต่อต้องผ่านด้วย เอกสารการกำหนดค่าความปลอดภัยเครือข่ายของ Android อธิบายว่านโยบายความเชื่อถืออาจต่างกันในแต่ละแอป แอปที่กำหนดเป้าหมายเป็น Android 7.0 ขึ้นไปจะไม่เชื่อถือใบรับรองที่ผู้ใช้เพิ่มโดยค่าเริ่มต้น เว้นแต่จะกำหนดค่าไว้เป็นอย่างอื่น
นี่เป็นกลไกทางเทคนิคทั่วไป ไม่อาจใช้กลไกนี้ตัดสินเกี่ยวกับผู้ให้บริการ ประเทศ หรือเหตุการณ์ใดโดยไม่มีหลักฐาน การขัดข้องหรือการกรองเพียงอย่างเดียวไม่ใช่ข้อพิสูจน์ว่าตรวจสอบ TLS ได้สำเร็จ
หากเปิดชั้น TLS ได้ จะเห็นอะไร?
| ประเภทข้อมูลหรือสถานการณ์ | ผลที่อาจเกิดจากการตรวจสอบ TLS |
|---|---|
| เนื้อหาที่ปกป้องด้วย HTTPS เท่านั้น | ตัวกลางที่ได้รับความเชื่อถืออาจเห็นข้อความได้ |
| ข้อความที่เข้ารหัสด้วยกุญแจที่ถูกต้องของผู้รับไว้แล้ว | โดยทั่วไปตัวกลางจะพบข้อความเข้ารหัส ไม่ใช่เนื้อหาข้อความ |
| ข้อมูลเส้นทาง เซสชัน หรือคำขอเสริม | ระดับการเปิดเผยขึ้นกับรูปแบบและการออกแบบบริการ |
| โค้ดเวอร์ชันเว็บที่ส่งมาผ่านเส้นทางเดียวกัน | การแก้ไขโค้ดอาจคุกคามความปลอดภัยของอุปกรณ์ปลายทาง |
| บริการใช้งานไม่ได้หรือการรับส่งข้อมูลถูกบล็อก | การเข้ารหัสเพียงอย่างเดียวไม่ทำให้เชื่อมต่อได้ |
การปกป้องเนื้อหาด้วย E2EE ยังขึ้นกับความแท้ของกุญแจผู้รับและความสมบูรณ์ปลอดภัยของซอฟต์แวร์ทั้งสองฝ่ายด้วย หากผู้โจมตีแทนที่กุญแจเริ่มต้น หรือแอปที่เห็นข้อความก่อนเข้ารหัสถูกดัดแปลง การมี AES หรือ ML-KEM เพียงอย่างเดียวก็ไม่พอ
ทำไมเวอร์ชันเว็บจึงต้องใช้ TLS ที่ปลอดภัย?
โดยทั่วไปเว็บแอปรับโค้ดที่ใช้ทำงานจากเซิร์ฟเวอร์ หากโค้ดนั้นเป็นอันตราย ก็อาจเข้าถึงเนื้อหาก่อนเข้ารหัสหรือหลังถอดรหัสได้ จึงไม่สามารถประเมินการเข้ารหัสจากต้นทางถึงปลายทางโดยแยกจากวิธีส่งมอบและเรียกใช้โค้ด
สำหรับเวอร์ชันที่ติดตั้ง ความแท้ของแพ็กเกจ การอัปเดต และความสมบูรณ์ปลอดภัยของระบบปฏิบัติการก็สำคัญ ลายเซ็นแพ็กเกจและการตรวจสอบแฮชมีประโยชน์ แต่ไม่ใช่การทดสอบความปลอดภัยของแอปอย่างครบถ้วน แบบจำลองภัยคุกคามของ Livara ระบุเช่นกันว่า หากผู้โจมตีเปลี่ยนทั้งไฟล์และค่าแฮชที่แสดง การที่ค่าแฮชตรงกันเพียงอย่างเดียวไม่พิสูจน์ความแท้
Livara อ้างว่าอย่างไร?
ตามเอกสารความปลอดภัยของ Livara ข้อความโดยตรงใช้ LVR1 และกลุ่มส่วนตัวที่รองรับใช้ LGS1 เอกสารอธิบายการใช้ P-256 ร่วมกับ ML-KEM-768 และการเข้ารหัสเนื้อหาข้อความ คำอธิบายเหล่านี้เป็นข้ออ้างของผลิตภัณฑ์ ไม่ใช่ผลการตรวจสอบอิสระในบทความนี้
หน้าเดียวกันยังระบุว่ามีการเก็บข้อมูลเมตาสำหรับการกำหนดเส้นทาง และช่องเผยแพร่เป็นสาธารณะ ดังนั้นข้อสรุปที่ถูกต้องจึงไม่ใช่ “ข้อมูลทั้งหมดถูกซ่อน” หรือ “ไม่จำเป็นต้องเชื่อถือเครือข่ายใดเลย” แต่คือ ต้องพิจารณาการปกป้องเนื้อหาส่วนตัวแยกจากการเชื่อมต่อ การส่งมอบกุญแจ โค้ดแอป และข้อมูลเมตา
ควรทำอย่างไรเมื่อมีคำเตือนใบรับรอง?
- อย่าเพิกเฉยต่อคำเตือนของเบราว์เซอร์หรือแอปเพื่อสนทนาเรื่องละเอียดอ่อนต่อ
- ตรวจสอบวันที่ของอุปกรณ์และที่อยู่บริการให้ตรงทุกตัว ข้อผิดพลาดใบรับรองไม่ได้หมายถึงการโจมตีทุกครั้ง
- หากเป็นอุปกรณ์ขององค์กร ให้ถามผู้ดูแลที่ได้รับอนุญาตเกี่ยวกับนโยบายการจัดการและใบรับรองที่ติดตั้ง อย่าเปลี่ยนการตั้งค่าที่องค์กรจัดการเองโดยพลการ
- อย่าติดตั้งใบรับรองหรือโปรไฟล์เพียงเพราะข้อความจากคนไม่รู้จักร้องขอ
- ในการสนทนาเรื่องละเอียดอ่อน ให้เทียบลายนิ้วมือกุญแจกับคู่สนทนาผ่านช่องทางอิสระ การเทียบกุญแจไม่ใช่สิ่งทดแทนการแก้ไขคำเตือน TLS
คำถามที่พบบ่อย
VPN แก้ปัญหาเหล่านี้ได้ทั้งหมดหรือไม่?
ไม่ VPN อาจเปลี่ยนเส้นทางที่ผู้สังเกตเห็นการรับส่งข้อมูล แต่ไม่แก้อุปกรณ์ที่ติดมัลแวร์ ใบรับรองอันตรายที่ได้รับความเชื่อถือ หรือโค้ดเว็บที่ถูกดัดแปลงโดยอัตโนมัติ
การยืนยันตัวตนโดยไม่ส่งรหัสผ่านเพียงพอหรือไม่?
ไม่ โปรโตคอลยืนยันตัวตน การจัดการเซสชัน และการเข้ารหัสข้อความทำหน้าที่ต่างกัน หน้าลงชื่อเข้าใช้ปลอมหรือโค้ดอันตรายอาจรับข้อมูลที่ผู้ใช้ป้อนก่อนโปรโตคอลจะทำงาน
หลักปฏิบัติ: E2EE เป็นชั้นป้องกันที่มีคุณค่า อย่าถือเป็นใบอนุญาตให้ละเลยใบรับรอง ความแท้ของแอป หรือการยืนยันกุญแจ
