TLS 1.3: 0-RTT ข้อมูลล่วงหน้า และการกลับมาใช้เซสชันต่อ

TLS 1.3 (RFC 8446, 2018) ออกแบบการจับมือของ TLS ใหม่เพื่อลดเวลาแฝงและนำส่วนเกินจากระบบเดิมออก การจับมือ TLS 1.3 แบบเต็มเสร็จสิ้นภายใน 1-RTT โดยไคลเอนต์ส่ง ClientHello พร้อม key_shares ที่รองรับ (กุญแจสาธารณะ ECDH ชั่วคราว) ในการส่งชุดแรก เซิร์ฟเวอร์ตอบกลับด้วย ServerHello, key_share ของตน, ส่วนขยายที่เข้ารหัส, ใบรับรอง และข้อความเสร็จสิ้น ทั้งหมดในการตอบกลับครั้งเดียว จากนั้นไคลเอนต์ส่งข้อความเสร็จสิ้นของตนและสามารถส่งข้อมูลแอปพลิเคชันได้ทันที เมื่อเทียบกับการจับมือแบบ 2-RTT ของ TLS 1.2 วิธีนี้ลดเวลาตั้งค่าการเชื่อมต่อใหม่ลงครึ่งหนึ่ง

TLS 1.3 ใช้ HKDF (ฟังก์ชันสร้างกุญแจที่อิง HMAC) พร้อมตารางการสร้างกุญแจที่มีโครงสร้าง หลังการแลกเปลี่ยนกุญแจ ECDHE ความลับร่วมจะถูกป้อนเข้าสู่ลำดับชั้นดังนี้: Extract(early_secret, DHE) -> handshake_secret จากนั้น Extract(handshake_secret, 0) -> master_secret จากค่าเหล่านี้ HKDF-Expand-Label จะสร้างกุญแจแยกกันสำหรับการรับส่งข้อมูลการจับมือของไคลเอนต์และเซิร์ฟเวอร์ การรับส่งข้อมูลแอปพลิเคชัน และการกลับมาใช้เซสชันต่อ การแยกส่วนอย่างชัดเจนนี้ทำให้การที่กุญแจในชั้นหนึ่งถูกบุกรุกไม่ส่งผลกระทบต่อชั้นอื่น ซึ่งเป็นการปรับปรุงครั้งสำคัญเมื่อเทียบกับการสร้างกุญแจแบบ PRF ที่ค่อนข้างเฉพาะกิจของ TLS 1.2

การกลับมาใช้เซสชันต่อของ TLS 1.3 ใช้กุญแจที่แชร์ล่วงหน้า (PSK) ซึ่งสร้างจากเซสชันก่อนหน้า หลังการจับมือเสร็จสิ้น เซิร์ฟเวอร์จะส่งข้อความ NewSessionTicket ที่มีข้อมูลระบุ PSK และค่าตั๋ว (ข้อมูลก้อนเข้ารหัสที่เก็บความลับสำหรับการกลับมาใช้เซสชันต่อ) เมื่อเชื่อมต่ออีกครั้ง ไคลเอนต์จะใส่ข้อมูลระบุ PSK ไว้ใน ClientHello หากเซิร์ฟเวอร์จำข้อมูลนี้ได้ ทั้งสองฝ่ายจะสร้างกุญแจเซสชันใหม่จาก PSK ร่วมกับ ECDHE ชุดใหม่ ทำให้กลับมาใช้เซสชันต่อได้ภายใน 1-RTT พร้อมการรักษาความลับแบบส่งต่อ ตั๋วมีอายุการใช้งานที่กำหนดค่าได้ โดยทั่วไปคือ 24 ชั่วโมง และควรเข้ารหัสด้วยกุญแจฝั่งเซิร์ฟเวอร์ที่มีการสับเปลี่ยนเป็นระยะ

TLS 1.3 อนุญาตให้ส่งข้อมูลระยะแรกแบบ 0-RTT สำหรับเซสชันที่กลับมาใช้ต่อ ไคลเอนต์ใช้ PSK จากเซสชันก่อนหน้าเพื่อเข้ารหัสข้อมูลแอปพลิเคชันที่ส่งในการส่งชุดแรก ก่อนที่เซิร์ฟเวอร์จะตอบรับใด ๆ วิธีนี้ตัดการรับส่งไปกลับออกหนึ่งรอบสำหรับการเชื่อมต่อไปยังเซิร์ฟเวอร์ที่เคยเข้าชม ทำให้การเชื่อมต่อซ้ำมีเวลาแฝงเกือบเป็นศูนย์ เซิร์ฟเวอร์จะแจ้งการรองรับ 0-RTT ใน NewSessionTicket ผ่านส่วนขยาย early_data พร้อมค่า max_early_data_size เซิร์ฟเวอร์ต้องมีกลไกสำหรับยอมรับหรือปฏิเสธข้อมูล 0-RTT และส่งสัญญาณการยอมรับใน EncryptedExtensions

ข้อมูล 0-RTT มีข้อจำกัดด้านความปลอดภัยที่สำคัญ นั่นคือเสี่ยงต่อการโจมตีแบบเล่นซ้ำ ผู้โจมตีที่อยู่บนเส้นทางซึ่งดักจับการส่งชุดแรกไว้ได้สามารถส่งข้อมูลนั้นซ้ำไปยังเซิร์ฟเวอร์ ทำให้เซิร์ฟเวอร์ประมวลผลข้อมูลระยะแรกอีกครั้ง นี่เป็นข้อจำกัดโดยธรรมชาติ เพราะเซิร์ฟเวอร์ยังไม่ได้ส่งข้อความใด ๆ จึงไม่มีค่าความใหม่ที่เซิร์ฟเวอร์มีส่วนสร้าง วิธีบรรเทาความเสี่ยงมีดังนี้: (1) ตั๋วใช้ครั้งเดียว (เซิร์ฟเวอร์ทำให้ตั๋วใช้ไม่ได้หลังการใช้งานครั้งแรก โดยใช้แคชแบบกระจาย เช่น memcached/Redis) (2) ตั๋วจำกัดเวลา (ปฏิเสธ 0-RTT หลังช่วงเวลาสั้น ๆ เช่น 5 วินาที) (3) การทำให้การดำเนินการในระดับแอปพลิเคชันทำซ้ำได้อย่างปลอดภัย (อนุญาต 0-RTT เฉพาะการดำเนินการที่ปลอดภัยและเทียบเท่า GET)

กลไกป้องกันการเล่นซ้ำของ 0-RTT ที่มีความทนทานมากที่สุดคือตั๋วเซสชันแบบใช้ครั้งเดียว เซิร์ฟเวอร์จะเก็บคลังข้อมูล "ตั๋วที่ใช้แล้ว" ไว้ ซึ่งเป็นแคชแบบกระจายสำหรับการติดตั้งที่มีหลายเซิร์ฟเวอร์ เมื่อข้อมูล 0-RTT มาถึง เซิร์ฟเวอร์จะตรวจสอบว่าตั๋วนี้เคยถูกพบมาก่อนหรือไม่ หากเคยพบแล้ว เซิร์ฟเวอร์จะปฏิเสธข้อมูลระยะแรกและใช้ทางเลือกสำรองเป็น 1-RTT หากยังไม่เคยพบ เซิร์ฟเวอร์จะทำเครื่องหมายว่าตั๋วถูกใช้แล้วและประมวลผลข้อมูลระยะแรก เพื่อให้ถูกต้อง เซิร์ฟเวอร์ทั้งหมดในคลัสเตอร์ต้องใช้แคชตั๋วที่ใช้แล้วร่วมกัน Redis ที่มี TTL สั้น ๆ ซึ่งสอดคล้องกับอายุการใช้งานของตั๋ว เป็นการนำไปใช้ที่พบได้ทั่วไป หากไม่มีกลไกนี้ 0-RTT จะไม่ปลอดภัยสำหรับการดำเนินการที่ทำซ้ำแล้วไม่ได้ผลเดิม เช่น การชำระเงิน

การกลับมาใช้เซสชันต่อด้วย PSK ของ TLS 1.3 โดยไม่มี DHE จะขาดการรักษาความลับแบบส่งต่อสำหรับเซสชันที่กลับมาใช้ต่อ หาก PSK ถูกบุกรุกในภายหลัง การรับส่งข้อมูลทั้งหมดของเซสชันที่กลับมาใช้ต่อจะถูกถอดรหัสได้ เพื่อรักษาความลับแบบส่งต่อ TLS 1.3 รองรับ PSK-with-DHE โดย ClientHello จะมีทั้งข้อมูลระบุ PSK และ key_share ชุดใหม่ เซิร์ฟเวอร์จะรวม PSK กับผลลัพธ์ ECDHE เพื่อสร้างกุญแจเซสชัน แม้ PSK จะถูกบุกรุก ผลลัพธ์จาก ECDHE ก็ยังช่วยให้ข้อมูลที่รับส่งในอดีตได้รับการปกป้อง RFC 8446 แนะนำให้ใช้ PSK-with-DHE ในทุกกรณีของการกลับมาใช้เซสชันต่อที่ต้องการการรักษาความลับแบบส่งต่อ

TLS 1.2 มีชุดการเข้ารหัสมากกว่า 300 รูปแบบ ซึ่งหลายรูปแบบไม่ปลอดภัย TLS 1.3 ลดจำนวนลงเหลือ 5 ชุดการเข้ารหัส โดยทั้งหมดใช้ AEAD ได้แก่ TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 และ TLS_AES_128_CCM_8_SHA256 การแลกเปลี่ยนกุญแจและการยืนยันตัวตนจะเจรจาแยกกันผ่านส่วนขยาย supported_groups และ signature_algorithms การแยกส่วนนี้ขจัดความซับซ้อนแบบผสมผสานของ TLS 1.2 และทำให้มั่นใจว่าการเชื่อมต่อ TLS 1.3 ทุกครั้งใช้การเข้ารหัสที่ยืนยันตัวตน

ในทางปฏิบัติ 0-RTT มีประโยชน์มากที่สุดสำหรับการเชื่อมต่อ HTTP/2 ที่ไคลเอนต์ส่งคำขอ GET ซ้ำ (ปลอดภัยและทำซ้ำแล้วได้ผลเดิม) ไปยังเซิร์ฟเวอร์ที่เคยเข้าชม เบราว์เซอร์ใช้ 0-RTT อย่างระมัดระวัง โดย Chrome เปิดใช้งานสำหรับวิธีการ HTTP ที่ปลอดภัย และจะไม่ส่งคำขอ POST เป็นข้อมูล 0-RTT เด็ดขาด HTTP/3 ที่ทำงานบน QUIC ผสาน TLS 1.3 ไว้โดยตรง โดย 0-RTT ของ QUIC นำกลไกของ TLS 1.3 กลับมาใช้ ใน QUIC นั้น 0-RTT ยังคืนค่าพารามิเตอร์การขนส่งจากเซสชันก่อนหน้า เช่น การควบคุมการไหลและขีดจำกัดสตรีม จึงช่วยลดค่าใช้จ่ายในการตั้งค่าได้มากขึ้น ไม่ใช่เฉพาะในชั้น TLS เท่านั้น

TLS 1.3 มีกลไกป้องกันการโจมตีแบบลดระดับเวอร์ชัน ฟิลด์ random ของ ServerHello จะมีค่าตัวบ่งชี้เมื่อมีการเจรจา TLS 1.3 โดยไบต์ 8 ตัวสุดท้ายจะถูกกำหนดเป็นค่าคงที่ (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 สำหรับทางเลือกสำรองเป็น TLS 1.2) ไคลเอนต์ที่รองรับ TLS 1.3 จะตรวจสอบค่าตัวบ่งชี้นี้เมื่อเซิร์ฟเวอร์เจรจา TLS 1.2 เพื่อจับความพยายามลดระดับที่เกิดจากผู้โจมตี นอกจากนี้ แฮชของบันทึกการจับมือที่เสร็จสิ้นยังครอบคลุมการจับมือทั้งหมด รวมถึงการเจรจาเวอร์ชัน จึงตรวจจับการดัดแปลงใด ๆ ได้ SCSV (ค่าชุดการเข้ารหัสสำหรับส่งสัญญาณ) เช่น TLS_FALLBACK_SCSV จะให้สัญญาณการลดระดับแยกต่างหากสำหรับ TLS เวอร์ชันเก่า

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

เหตุใดข้อมูลระยะแรกแบบ 0-RTT จึงเสี่ยงต่อการโจมตีแบบเล่นซ้ำใน TLS 1.3

TLS 1.3 ทำให้การจับมือแบบเต็มเสร็จสิ้นภายใน 1-RTT และกลับมาใช้เซสชันต่อภายใน 0-RTT ผ่านตั๋วเซสชัน PSK การสร้างกุญแจใช้ HKDF พร้อมตารางที่มีโครงสร้าง ซึ่งสร้างกุญแจแยกกันสำหรับการรับส่งข้อมูลแต่ละชั้น ข้อมูลระยะแรกแบบ 0-RTT ตัดการรับส่งไปกลับออกหนึ่งรอบ แต่เสี่ยงต่อการเล่นซ้ำ โดยบรรเทาความเสี่ยงได้ด้วยตั๋วใช้ครั้งเดียวและการจำกัด 0-RTT ไว้สำหรับการดำเนินการที่ทำซ้ำแล้วได้ผลเดิม PSK-with-DHE รักษาความลับแบบส่งต่อสำหรับการกลับมาใช้เซสชันต่อ TLS 1.3 จำกัดชุดการเข้ารหัสไว้ที่ตัวเลือก AEAD 5 รูปแบบ จึงขจัดรูปแบบที่ไม่ปลอดภัยจากระบบเดิม การป้องกันการลดระดับใช้ค่าตัวบ่งชี้ในฟิลด์ random ของเซิร์ฟเวอร์