อุโมงค์เข้ารหัสอะไร และอะไรที่ยังอ่านได้

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

อุโมงค์ครอบคลุมอะไรจริง ๆ

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

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

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

กุญแจ nonce และความสมบูรณ์ในภาษาง่าย ๆ

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

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

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

อุโมงค์สิ้นสุดที่ใด

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

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

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

ทำไมการไม่ระบุตัวตนจึงเป็นผลิตภัณฑ์อีกแบบ

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

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

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

ตรวจสอบอุโมงค์และเว็บไซต์แยกกัน

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

รันการตรวจสอบกับโฮสต์ที่คุณได้รับอนุญาตให้ทดสอบ และอ่านผลลัพธ์ไม่ใช่บทสรุป

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

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