Resumo

  • Na RFC 9846, close_notify encerra ordenadamente uma direção de envio TLS e fornece ao receptor uma fronteira criptográfica contra truncamento. Não confirma análise, persistência, efeito ou liquidação na aplicação.
  • Um registro confiável de encerramento associa o último registro TLS e o alerta a um identificador de transação, resultado e regra de repetição mantidos separadamente. Proximidade no tempo não autoriza inferir um do outro.

Imagine um cliente de pagamentos que envia uma instrução, esvazia o buffer e recebe close_notify do servidor. A biblioteca TLS informa fim de dados sem erro de protocolo. Se o cliente grava “pago” nesse instante, qual fato sustenta a decisão? Não o alerta. O servidor pode ter lido os bytes e recusado a ordem, analisado a ordem e falhado antes do commit, ou confirmado o efeito sem conseguir devolver a resposta. Todas essas histórias cabem no que a camada de transporte consegue observar.

A RFC 9846, Proposed Standard de julho de 2026 para TLS 1.3, substitui a RFC 8446 mantendo a versão do protocolo e incorporando esclarecimentos compatíveis. Ela atribui uma função precisa a close_notify: indicar o encerramento ordeiro de uma direção da conexão. Quem envia declara que não transmitirá outras mensagens TLS naquela conexão. Depois que o alerta chega, dados posteriores devem ser ignorados e a implementação TLS deve informar fim de dados à aplicação.

“Uma direção” concentra a consequência operacional. Qualquer parte pode enviar close_notify para encerrar seu lado de escrita sem afetar seu lado de leitura. Um cliente pode parar de enviar e continuar esperando uma resposta. Um servidor pode terminar sua saída e ainda receber. Um alerta não promove o fechamento a desmontagem simétrica nem transforma dois alertas em votos de commit distribuído.

Cada parte deve mandar close_notify antes de fechar seu lado de escrita, salvo se já tiver enviado um alerta de erro. Nenhuma das partes, porém, precisa esperar o alerta do par para fechar seu lado de leitura, embora a RFC diga que essa escolha introduz risco de truncamento. As duas direções produzem fatos de encerramento independentes, não um recibo conjunto da operação.

O alerta protege a cauda do canal. Se o transporte fechar antes dele, o receptor não sabe se recebeu tudo o que o par enviou. O encerramento autenticado separa um fim ordenado de uma perda inexplicada dos bytes finais. É uma garantia importante, mas limitada: nada revela sobre o que o programa receptor fez com os dados entregues antes dessa fronteira.

O registro de parâmetros TLS da IANA atribui o código de descrição do alerta. A RFC 9846 restabelece a exigência de enviá-lo com o nível legado warning. Esse rótulo não quer dizer opcional e tampouco é um estado do negócio. Obrigação de envio, severidade do alerta e resultado da operação são perguntas diferentes. Alertas de erro encerram de modo abortivo e impedem dados posteriores; não são equivalentes a um fim ordenado.

O TLS 1.3 também corrige um acoplamento prejudicial de versões anteriores. Uma reação antiga podia obrigar o receptor de close_notify a descartar gravações pendentes, responder imediatamente e fechar, truncando a direção na qual ele ainda precisava enviar. A regra atual mantém leitura e escrita independentes e permite que o perfil de uso termine a saída relevante.

Uma aplicação pode esvaziar seu buffer e responder imediatamente ao receber o alerta. A RFC 9846 adverte, contudo, que um atacante consegue influenciar o que o par recebe ao atrasar o encerramento ou os pacotes da aplicação. Por isso a aplicação precisa definir a própria regra: recusar novas entradas depois de iniciar o fechamento, por exemplo, ou exigir resposta completa antes de classificar a operação.

Essa é a diferença entre ordem de entrega e autoridade sobre o efeito. TLS protege registros e fornece um final autenticado para a sequência. Um transporte confiável e ordenado sustenta a hipótese de que dados pendentes sejam entregues antes da destruição da conexão. Nenhuma dessas camadas define o parser da aplicação, valida um identificador de transação, cria uma chave de idempotência, efetiva armazenamento ou emite recibo comercial.

A RFC 9293 oferece o modelo TCP sob muitas conexões TLS, inclusive o fechamento independente do lado de envio. A RFC 9110 e a RFC 9112 tratam da semântica HTTP e do enquadramento de mensagens HTTP/1.1 acima dele. A composição das camadas não apaga suas condições próprias de conclusão.

Em HTTP, a evidência adequada pode ser uma resposta final associada à solicitação, com corpo completo segundo o enquadramento e semântica de status aplicável. Em uma fila, pode ser a confirmação do broker depois da colocação durável. Em pagamentos, um recibo de domínio com identificador estável. O alerta TLS não entrega nenhuma dessas evidências.

O erro de direção contrária também importa. Ausência de close_notify não prova que a operação falhou. A aplicação pode ter feito commit e enviado um recibo antes de o transporte desaparecer. Falta a garantia TLS contra truncamento naquela direção, não necessariamente o efeito comercial. Repetir toda operação após um fechamento não ordenado pode duplicar ações não idempotentes.

user_canceled tampouco corrige a leitura. Na RFC 9846, ele indica cancelamento de handshake não relacionado a falha de protocolo, deve ser seguido por close_notify, e o receptor deve continuar lendo até o encerramento. Esses sinais descrevem o estado TLS. Não codificam estorno, cancelamento de pedido nem retirada de consentimento na aplicação.

O padrão preserva a autoridade do perfil de uso. Se um protocolo permite dados não TLS no mesmo transporte depois do fim de TLS, a implementação deve receber close_notify antes de informar o fim dos dados TLS para cima. De forma mais ampla, a RFC 9846 não determina como um perfil gerencia o transporte subjacente nem quando abre e fecha conexões.

Essa fronteira evita generalizações. A RFC 9001 usa TLS para proteger o handshake do QUIC, mas substitui a proteção de registros TLS e usa mecanismos próprios para fechar a conexão. A RFC 9147 dá ao DTLS 1.3 seu contexto de datagramas. Um controle criado para fluxo TLS ordenado não deve ser aplicado automaticamente a todo transporte criptografado.

Identidade também permanece separada. A RFC 9525 explica como protocolos de aplicação especificam a verificação da identidade do serviço com TLS. Um fechamento ordeiro não reautentica as partes, não prolonga autorização, não identifica o operador humano e não aprova o último efeito.

Três marcas costumam aparecer próximas na investigação: última escrita da aplicação, último registro TLS aceito e alerta de encerramento. A proximidade ajuda a reconstituir a sequência, mas não vira recibo causal. O servidor pode encerrar após enfileirar um trabalho, antes de seu commit, ou depois de decidir não executá-lo. Só a máquina de estados da aplicação conhece o resultado autorizado.

A RFC 5116 delimita a interface de criptografia autenticada. Autenticidade de cifra e dados associados não representa intenção comercial. O alerta protegido pelo estado atual demonstra que a mensagem pertence àquele canal; não demonstra que um subsistema remoto realizou uma mudança durável.

O registro de publicação da RFC 9846 e a página de erratas permitem rastrear estado e correções, enquanto a RFC 8446 conserva o texto substituído. São provas documentais sobre a norma, não base para afirmar adoção, comportamento de fornecedor ou incidente específico.

Fontes