Cei 16 KiB (ca $2^{14}$B este, evident, 16 KiB) limitarea dimensiunii înregistrărilor a fost valabilă pentru fiecare specificație TLS începând cu TLS 1.0, prima care nu a fost dezvoltată de Netscape, care a dezvoltat versiunile SSL până la 3.0.Rețineți că compresia mesajelor (până la TLS 1.2) și criptarea pot crește dimensiunea peste 16 KiB - cât de mult depinde de versiunea TLS.
Până acum am văzut acest lucru explicat ca o limitare practică a tamponării. Puteți / ar trebui să începeți decriptarea / decompresia numai după ce a fost primită întreaga înregistrare și pentru asta trebuie să alocați un buffer. Nu toate dispozitivele suportă o dimensiune mai mare a bufferului, iar suprasarcina introdusă de stratul de înregistrare este deja nesemnificativă în comparație cu datele conținute în înregistrări.
Rețineți că datele dintr-o înregistrare nu ar trebui să utilizeze cu siguranță 64 kiB, deoarece aceasta este dimensiunea implicită a ferestrei TCP. Înregistrarea criptată ar deveni mai mare decât această fereastră și asta ar necesita o dimensiune mai mare a memoriei tampon pe, de ex. dispozitive încorporate. Pe de altă parte, nu ar trebui să fie prea mic sau mesajele de strângere de mână nu s-ar mai potrivi (din cauza lanțurilor de certificate incluse, în principal).
Doar pentru a oferi o susținere pentru afirmația mea, iată un text în RFC 8449: Extensie limită pentru dimensiunea înregistrării pentru TLS
Primirea de înregistrări protejate mari poate fi deosebit de dificilă pentru un dispozitiv cu memorie de operare limitată. Versiunile TLS 1.2 [RFC5246] și anterioare permit expeditorilor să genereze înregistrări cu o dimensiune de 16384 octeți, plus orice extindere de la compresie și protecție până la 2048 octeți (deși de obicei această extindere este de doar 16 octeți). TLS 1.3 reduce permisiunea de extindere la 256 de octeți. Alocarea a până la 18K de memorie pentru text cifrat depășește capacitatea unor implementări.
Rețineți că acest RFC permite utilizatorilor să limiteze și mai mult dimensiunea înregistrării, nu permite implementărilor să crească dimensiunea înregistrării peste ceea ce este permis.
Și acum pentru puțină istorie, specificațiile SSL 0.2:
Unde byte[0] reprezintă primul octet primit și byte[1] al doilea octet primit. Când este utilizat antetul de 3 octeți, lungimea înregistrării este calculată după cum urmează (folosind o notație asemănătoare „C”):
RECORD-LENGTH = ((octet[0] și 0x3f) << 8)) | octet[1];
IS-ESCAPE = (octet[0] & 0x40) != 0;
PADDING = octet[2];
care duce la:
Pentru un antet de doi octeți, lungimea maximă a înregistrării este de 32767 de octeți. Pentru antetul de trei octeți, lungimea maximă a înregistrării este de 16383 de octeți. Mesajele SSL Handshake Protocol sunt limitate să se încadreze într-o singură înregistrare SSL Record Protocol. Mesajele protocolului de aplicație au permisiunea de a consuma mai multe înregistrări SSL Record Protocol.
Așadar, se pare că specificațiile ulterioare ale protocolului au decis să folosească lungimea mai mică a înregistrării (excluzând supraîncărcarea).
Disclaimer: K înseamnă Kelvin, k înseamnă kilo - care se traduce literal prin mie în greacă veche - și Ki înseamnă Kibi, echivalentul binar (aproape) care înseamnă 1024. b înseamnă biți și B înseamnă octeți. Astfel, 1 KiB este 1024 de octeți. Octeții și octeții sunt același lucru în zilele noastre.
