O registro que o receptor não conseguia guardar: como o TLS tornou o limite local

Resumo

• O TLS começou com teto de 16 KiB e depois ofereceu um fragmento menor escolhido pelo cliente e aplicado nos dois sentidos. A simetria escondia que receber o registro protegido inteiro costuma ser a obrigação crítica de memória.
• O RFC 8449 transformou o tamanho em duas declarações direcionais: cada ponta informa o que aceita receber, e o emissor fragmenta apenas os registros enviados para ela.

A diferença aparece quando o fluxo muda de sentido

Um sensor pode alimentar um acelerador criptográfico aos poucos e retirar o ciphertext conforme ele é produzido. Para receber, não deveria liberar plaintext antes de autenticar o registro protegido completo. Se uma parte falsificada chegar à aplicação antes da verificação final, a rejeição posterior não desfaz uma ação já executada.

O tamanho do registro distribui um custo. O emissor escolhe quanto colocar em uma unidade protegida; o receptor assume a memória atômica para guardá-la e verificá-la. Falar o mesmo protocolo não iguala o hardware. O avanço do RFC 8449 foi fazer o número representar a capacidade de quem recebe.

O teto geral e a primeira negociação

O TLS 1.2 organiza dados superiores em TLSPlaintext de até 2^14 bytes. Uma mensagem pode ocupar vários registros, e várias mensagens do mesmo tipo podem ser reunidas. Registro TLS não é mensagem da aplicação, segmento TCP nem pacote IP.

Registros grandes amortizam cabeçalhos e criptografia, mas exigem preparação para o pior caso. Proteção e compressão podem ampliar o objeto na rede. Em um dispositivo de pouca RAM, o buffer de recepção podia dominar o projeto.

max_fragment_length, criado nas extensões de 2006 e mantido pelo RFC 6066, permitia ao cliente pedir 512, 1024, 2048 ou 4096 bytes. O servidor que aceitasse repetia exatamente o valor, e ambos passavam a fragmentar dados e handshake dentro do mesmo teto. O acordo valia durante a sessão, inclusive na retomada conforme o modelo da época.

O perfil IoT RFC 7925 destacou a economia de RAM: o cliente limitado não precisava aceitar registros próximos dos 16 KiB do TLS/DTLS comum. A limitação interna finalmente virava informação compartilhada.

Um valor comum não servia a dois receptores diferentes

O formato antigo criava desincentivos. Seu maior código era 4096, não os 16384 normais. Um cliente capaz que oferecesse a extensão poderia reduzir o desempenho sem necessidade, multiplicando cabeçalhos, expansão criptográfica e processamento.

O servidor também não podia responder com um limite menor próprio. A proposta era do cliente e a cifra valia para ida e volta. Só que a restrição costuma estar no recebimento: é possível cifrar progressivamente e, ao mesmo tempo, não conseguir autenticar um registro grande de entrada sem mantê-lo inteiro.

A simetria parecia simples, mas transformava duas máquinas em uma capacidade e deixava uma delas sem voz.

record_size_limit aponta para quem anuncia

O novo valor é o maior plaintext de registro protegido que a ponta anunciante aceita receber. O par precisa respeitá-lo ao enviar naquela direção. No sentido contrário, o anunciante pode produzir registros maiores, desde que obedeça à declaração do outro lado e ao teto da versão.

Uma conexão pode ter dois limites. Um sensor pede respostas pequenas ao serviço e ainda envia registros maiores para uma infraestrutura com memória. Um servidor limitado também declara sua capacidade. Mesmo pontas sem limitação são aconselhadas a oferecer a extensão, pois assim o outro lado pode responder e saber que seu valor será obedecido.

Ultrapassar a declaração em TLS exige record_overflow fatal. Em DTLS, o receptor também pode descartar o registro. Valores abaixo de 64 são ilegais; 64 não é recomendação. Registros mínimos demais elevam trabalho, reduzem vazão e podem aumentar exposição a negação de serviço.

O orçamento é do interior protegido

Em TLS 1.2 e anteriores, o limite cobre a entrada de compressão e cifragem; padding acrescentado pela cifra não entra da mesma forma. No TLS 1.3, conta todo o TLSInnerPlaintext: conteúdo, tipo interno e padding do registro.

O padding pode esconder formatos de tráfego, mas não contorna a memória declarada. Privacidade e carga útil consomem o mesmo orçamento. Mensagens não protegidas ficam fora da extensão. Em retomada ou renegociação antiga, o valor é negociado de novo e segue o handshake que gerou as chaves do registro.

Limite local não é PMTU

Tanto uma PMTU pequena quanto um limite de registro pequeno produzem unidades menores, mas a evidência é diferente. O limite vem da ponta e fica fixado no handshake. A PMTU vem do caminho, limita pacotes e pode mudar. Vários registros DTLS pequenos ainda podem ocupar um datagrama UDP.

O mecanismo também não limita uma resposta HTTP, cadeia de certificados ou mensagem, que pode atravessar registros. Não resolve tamanho de código, CPU, banda, bateria ou toda falta de memória. Delimita apenas o plaintext protegido que o receptor aceita processar como unidade.

Hoje a IANA marca record_size_limit (28) como Recommended e max_fragment_length (1) como não recomendado. O registro organiza interoperabilidade; não prova adoção nem a qualidade de um produto.

O TLS não precisou igualar as pontas. Precisou deixar cada receptor dizer a fronteira que só ele conhecia e fazer o emissor respeitá-la no sentido em que o custo chegaria.

Fontes e limites da evidência

Foram usados RFC 4366, RFC 5246, RFC 6066, RFC 7925, RFC 8446, RFC 8449 e o registro IANA. Eles não medem implantação atual, RAM de produtos ou tamanho ótimo universal.