การแลกเปลี่ยนคีย์ TLS กับการรับรองไคลเอนต์: อะไรคือการเข้าสู่ระบบ
แยกข้อตกลงเรื่องคีย์ออกจากการพิสูจน์ตัวตนไคลเอนต์และตัวตนของแอปพลิเคชัน แล้วอ่านข้อความแฮนด์เชกที่บอกว่าการเชื่อมต่อใช้สิ่งใดจริง
การพาค่าการแลกเปลี่ยนคีย์สาธารณะไปในแฮนด์เชกไม่ใช่เหตุการณ์เดียวกับการที่ไคลเอนต์เข้าสู่ระบบ อย่างแรกสร้างสถานะการเข้ารหัสสำหรับการเชื่อมต่อ ส่วนอีกอย่างบอกว่าไคลเอนต์เป็นใคร และเกิดขึ้นเฉพาะเมื่อเซิร์ฟเวอร์ขอและชุดการแลกเปลี่ยนรองรับ การมองอย่างแรกเป็นอย่างหลังนำไปสู่ข้อสรุปผิดเกี่ยวกับสิ่งที่ VPN ซ่อนและไม่ซ่อน อ่านข้อความเหล่านี้ แล้วตัดสินว่าคุณสังเกตคุณสมบัติใดจากสี่ข้อจริง
สองวัตถุที่ดูคล้ายกันในการดักจับ
ไคลเอนต์ TLS 1.3 สามารถส่งวัสดุแลกเปลี่ยนคีย์ในการบินครั้งแรกโดยไม่แสดงใบรับรองใด ๆ การมีส่วนร่วมนั้นเปิดเผยตามการออกแบบ เพราะเซิร์ฟเวอร์ต้องใช้เพื่อสร้างความลับร่วม ใบรับรองไคลเอนต์เป็นข้อความอีกชนิดและส่งเฉพาะเมื่อเซิร์ฟเวอร์ขอ มันพาตัวตนที่เซิร์ฟเวอร์ตรวจสอบภายหลัง และการพิสูจน์ตัวตนทั้งสองฝ่ายเป็นการตัดสินใจของเซิร์ฟเวอร์ ไม่ใช่คุณสมบัติที่ชุดการเข้ารหัสบ่งบอก ตัวตนของแอปพลิเคชันเป็นเรื่องที่สามโดยสิ้นเชิง: แบบฟอร์มเข้าสู่ระบบ โทเค็นแบบพกพา คุกกี้ ไม่มีสิ่งใดปรากฏในแฮนด์เชก และทั้งหมดอยู่รอดเมื่อเส้นทางเครือข่ายเปลี่ยน
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
สี่แถวเป็นอิสระต่อกัน การเชื่อมต่อหนึ่งสามารถมีแถวหนึ่งและสอง ข้ามแถวสาม และยังพาแถวสี่ไปในส่วนหัวคุกกี้ได้
ตัดสินว่าแฮนด์เชกที่บันทึกไว้พิสูจน์อะไรได้
จากแฮนด์เชกเพียงอย่างเดียว ผู้สังเกตเรียนรู้เวอร์ชันที่เจรจา ชุดการเข้ารหัส ใบรับรองของเซิร์ฟเวอร์ และค่าแลกเปลี่ยนคีย์สาธารณะ เท่านี้พอจะเก็บลายนิ้วมือของการใช้งานไคลเอนต์และดูว่าเชื่อมต่อไปยังเซิร์ฟเวอร์ใด สิ่งที่ไม่ได้ให้คือสถานะส่วนตัวที่จำเป็นในการถอดรหัสการเชื่อมต่อ ซึ่งความลับนั้นอาศัยการแลกเปลี่ยนชั่วคราวไม่ใช่ส่วนสาธารณะ และไม่ได้ให้ตัวตนบัญชีซึ่งไม่เคยอยู่ในแฮนด์เชกตั้งแต่แรก
ดังนั้นข้อสรุปที่ซื่อสัตย์จึงแคบ: ไม่มีการแสดงใบรับรองไคลเอนต์ในการแลกเปลี่ยนนี้ ไม่ใช่เรื่องที่ไคลเอนต์ไม่ได้ส่งสิ่งใดที่เชื่อมโยงได้ และแน่นอนไม่ใช่เรื่องที่เซสชันไม่มีตัวระบุใด ๆ
อ่านข้อความ ไม่ใช่ชื่อการเข้ารหัส
ถามเซิร์ฟเวอร์ว่าขออะไร แทนที่จะอนุมานจากชุดการเข้ารหัส แฮนด์เชก TLS 1.3 ที่มีคำขอใบรับรองปรากฏในบันทึก และการไม่มีก็เห็นได้ชัดเท่ากัน
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'จากนั้นทำซ้ำโดยตั้งค่าใบรับรองไคลเอนต์และเปรียบเทียบ การรันครั้งที่สองควรแสดงว่าใบรับรองถูกส่งและยอมรับ ส่วนครั้งแรกไม่ควรแสดงอะไรเลย และนั่นคือความแตกต่างที่เป็นรูปธรรมของข้อโต้แย้งนี้
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quietหากต้องการเพียงกรณีการท่องเว็บทั่วไป เอาต์พุตแบบละเอียดของไคลเอนต์ก็เพียงพอที่จะเห็นเวอร์ชันโปรโตคอล ผลการตรวจสอบ และว่าเสนอใบรับรองไคลเอนต์หรือไม่ เซิร์ฟเวอร์ที่ไม่เคยส่งคำขอใบรับรองย่อมไม่สามารถได้รับ
ที่ซึ่งการกลับมาใช้ซ้ำเปลี่ยนคำตอบ
การกลับมาใช้ซ้ำใน TLS 1.3 ใช้ตั๋วที่ผูกกับสถานะลับ ทำให้การเชื่อมต่อภายหลังเสร็จได้โดยไม่ต้องแลกเปลี่ยนใบรับรองเต็มรูปแบบ สิ่งนี้ลดสิ่งที่ผู้สังเกตเห็นและเปลี่ยนสิ่งที่บันทึกพิสูจน์ มันไม่ได้สร้างตัวตนในที่ที่ไม่เคยมี เซสชันที่กลับมาใช้ซ้ำยังเป็นของเซสชันแอปพลิเคชันเดียวกัน และคุกกี้หรือโทเค็นใดในเซสชันนั้นยังคงเป็นตัวระบุที่สำคัญ
นี่คือเหตุผลที่การทบทวนความเป็นส่วนตัวซึ่งหยุดที่ "ไม่มีใบรับรองไคลเอนต์" พลาดส่วนที่น่าสนใจ คำถามที่ต้องถามคือฝ่ายใดมีตัวระบุที่มั่นคง ไม่ใช่ข้อความใดหายไปจากแฮนด์เชกครั้งเดียว
บันทึกสี่คุณสมบัติ ไม่ใช่คำตัดสินเดียว
จดข้อตกลงเรื่องคีย์ การตรวจสอบเซิร์ฟเวอร์ การพิสูจน์ตัวตนไคลเอนต์ และตัวตนของแอปพลิเคชันเป็นสี่บรรทัดแยกกัน พร้อมหลักฐานของแต่ละข้อ จากนั้นเพิ่มสิ่งที่เส้นทางเครือข่ายมีส่วน ส่วน VPN เปลี่ยนที่อยู่ต้นทางที่บริการเห็น มันไม่ได้ ลบการเข้าสู่ระบบ คุกกี้ หรือลายนิ้วมืออุปกรณ์ที่แอปพลิเคชันมีอยู่แล้ว
บันทึกเวอร์ชันที่เจรจาของการเชื่อมต่อและผลของคำขอใบรับรองไว้ด้วยกัน เพราะคู่นี้คือสิ่งที่ผู้ทบทวนต้องการเพื่อสร้างข้อสรุปของคุณซ้ำโดยไม่ต้องดักจับเอง