เหตุใดขนาดบันทึกสูงสุดใน TLS 1.3 จึงจำกัดไว้ที่ $2^{14}$ ไบต์

RFC 8446 จำกัดข้อมูลสูงสุดที่ดำเนินการภายในข้อความ TLSv1.3 เดียว $2^{14}$ ไบต์ โดยเฉพาะในส่วน 5.1:

เลเยอร์เรกคอร์ดจะแบ่งบล็อกข้อมูลเป็น TLSLaintext บันทึกการนำข้อมูลเป็นชิ้นขนาด 2^14 ไบต์หรือน้อยกว่า

ฟิลด์ความยาวในส่วนหัว TLS แสดงด้วย 16 บิต ดังนั้นความยาวสูงสุดในทางทฤษฎีอาจใหญ่กว่านี้ ฉันสงสัยว่าอะไรคือสาเหตุของสิ่งนี้

16 KiB (เช่น $2^{14}$เห็นได้ชัดว่า B คือ 16 KiB) ข้อจำกัดด้านขนาดบันทึกเป็นจริงสำหรับข้อกำหนด TLS ทุกรายการโดยเริ่มจาก TLS 1.0 ซึ่งเป็นเวอร์ชันแรกที่ไม่ได้พัฒนาโดย Netscape ซึ่งพัฒนา SSL เวอร์ชันสูงสุด 3.0โปรดทราบว่าการบีบอัดข้อความ (สูงสุด TLS 1.2) และการเข้ารหัสอาจเพิ่มขนาดเกิน 16 KiB - เท่าใดขึ้นอยู่กับเวอร์ชัน TLS

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

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

เพียงเพื่อสนับสนุนการอ้างสิทธิ์ของฉัน นี่คือข้อความใน RFC 8449: ส่วนขยายขีดจำกัดขนาดเรกคอร์ดสำหรับ TLS

การรับบันทึกที่มีการป้องกันขนาดใหญ่อาจเป็นเรื่องยากเป็นพิเศษสำหรับอุปกรณ์ที่มีหน่วยความจำปฏิบัติการจำกัด TLS เวอร์ชัน 1.2 [RFC5246] และเวอร์ชันก่อนหน้าอนุญาตให้ผู้ส่งสร้างเรคคอร์ดขนาด 16384 octets บวกกับการขยายจากการบีบอัดและการป้องกันสูงสุด 2048 octets (แม้ว่าโดยทั่วไปแล้วการขยายนี้จะมีเพียง 16 octets) TLS 1.3 ลดค่าเผื่อการขยายเป็น 256 ออคเต็ต การจัดสรรหน่วยความจำสูงสุด 18K สำหรับไซเฟอร์เท็กซ์นั้นเกินขีดความสามารถของการใช้งานบางอย่าง

โปรดทราบว่า RFC นี้อนุญาตให้ผู้ใช้จำกัดขนาดเรคคอร์ดเพิ่มเติมได้ ไม่อนุญาตให้การใช้งานขยายขนาดเรคคอร์ดเกินกว่าที่อนุญาต

และตอนนี้สำหรับประวัติบางอย่าง ข้อกำหนด SSL 0.2:

โดยที่ไบต์[0] หมายถึงไบต์แรกที่ได้รับและไบต์[1] ไบต์ที่สองที่ได้รับ เมื่อใช้ส่วนหัว 3 ไบต์ ความยาวของเร็กคอร์ดจะถูกคำนวณดังนี้ (โดยใช้สัญลักษณ์คล้าย "C"):

ความยาวบันทึก = ((byte[0] & 0x3f) << 8)) | ไบต์ [1];
IS-ESCAPE = (ไบต์[0] & 0x40) != 0;
PADDING = ไบต์ [2];

ซึ่งนำไปสู่:

สำหรับส่วนหัวสองไบต์ ความยาวบันทึกสูงสุดคือ 32767 ไบต์ สำหรับส่วนหัวสามไบต์ ความยาวบันทึกสูงสุดคือ 16383 ไบต์ ข้อความ SSL Handshake Protocol ถูกจำกัดให้พอดีกับบันทึก SSL Record Protocol เดียว ข้อความโปรโตคอลของแอปพลิเคชันได้รับอนุญาตให้ใช้บันทึก SSL Record Protocol หลายรายการ

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

ข้อจำกัดความรับผิดชอบ: K หมายถึงเคลวิน k หมายถึงกิโล ซึ่งแปลว่าพันในภาษากรีกโบราณ และ Ki หมายถึง Kibi ซึ่งเป็นเลขฐานสอง (เกือบ) ที่มีความหมายเทียบเท่า 1,024 b หมายถึงบิต และ B หมายถึงไบต์ ดังนั้น 1 KiB คือ 1024 ไบต์ ไบต์และออคเต็ตเป็นสิ่งเดียวกันในปัจจุบัน