TLS วิ่งอยู่ภายในช่องควบคุม ไม่ใช่ทั้งอุโมงค์

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

ซองข้อมูลมาเป็นอย่างแรก

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

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

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

ชั้นความน่าเชื่อถือเป็นของโพรโทคอล

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

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

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

แพ็กเก็ตข้อมูลใช้รูปแบบอื่น

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

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

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

ทำไมพร็อกซี HTTPS จึงช่วยไม่ได้

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

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

การอ่านร่องรอยอย่างถูกต้อง

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

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