Entenda o que é TLS, como funciona o handshake, certificados e criptografia e por que o RFC 9846 é a referência atual do TLS 1.3 desde 2026.
Confira!
O TLS — Transport Layer Security é um protocolo criptográfico utilizado para estabelecer canais seguros entre aplicações. Seu objetivo é proteger a comunicação contra escuta, alteração não autorizada e falsificação de mensagens, além de permitir a autenticação das partes conforme o modelo adotado.
O que é o protocolo TLS
TLS opera entre a aplicação e o transporte subjacente, criando um canal protegido sobre o qual protocolos como HTTP podem funcionar. A especificação atual do TLS 1.3 está no RFC 9846, publicado em julho de 2026. Esse documento substituiu o RFC 8446, mantendo a versão TLS 1.3 e compatibilidade com implementações anteriores dessa mesma versão, mas consolidando correções e requisitos atualizados.
Esse ponto é importante porque materiais técnicos ainda citam o RFC 8446 como a referência vigente do TLS 1.3. A partir de 2026, a referência principal deve ser o RFC 9846.
O que o TLS protege
Um canal TLS busca fornecer confidencialidade, integridade e autenticação. A confidencialidade protege o conteúdo contra leitura por terceiros; a integridade permite detectar modificações; e a autenticação permite verificar a identidade do servidor e, opcionalmente, também do cliente.
Essas propriedades dependem de configuração correta, algoritmos aceitos, gestão de certificados, proteção das chaves privadas e validação de identidade. TLS não elimina vulnerabilidades existentes acima ou abaixo de sua camada.
Como funciona o handshake TLS
Antes de transmitir dados de aplicação protegidos, os peers executam um handshake. Nessa fase, negociam versão e parâmetros criptográficos, validam informações de identidade e derivam segredos que serão utilizados para proteger os registros seguintes.
No TLS 1.3, o handshake foi simplificado em relação a versões anteriores, reduzindo combinações criptográficas legadas e buscando menor latência e maior segurança. Após a negociação, o protocolo de registro usa chaves derivadas para proteger os dados transmitidos.
Certificados digitais e autenticação
A autenticação do servidor é normalmente realizada por certificados X.509. O cliente verifica se o certificado corresponde ao nome esperado, se a cadeia é confiável e se as condições de validade e uso são aceitáveis.
O TLS também pode suportar autenticação do cliente, inclusive por certificado, e mecanismos baseados em chaves pré-compartilhadas em cenários específicos. A escolha depende do protocolo de aplicação e do desenho de segurança.
TLS 1.3 e versões anteriores
O RFC 9846 mantém o TLS 1.3 como versão atual e também consolida requisitos relacionados ao legado. O documento explicita que TLS 1.0 e TLS 1.1 não devem ser negociados e substitui especificações anteriores associadas ao TLS 1.2 e mecanismos legados.
Em projetos novos, a prática recomendada é priorizar TLS 1.3 e manter versões anteriores apenas quando houver necessidade de interoperabilidade devidamente avaliada. Equipamentos antigos de segurança eletrônica podem impor restrições, o que exige análise de risco e planejamento de atualização.
TLS versus SSL
SSL é o predecessor histórico do TLS e não deve ser tratado como sinônimo técnico atual. A expressão “certificado SSL” ainda aparece comercialmente, mas os sistemas modernos utilizam TLS.
Em documentação de engenharia, convém empregar TLS como termo principal e usar “SSL” apenas quando for necessário explicar nomenclatura legada ou interfaces de produtos.
TLS e HTTPS
TLS não é HTTPS. TLS é uma camada de segurança de propósito geral. HTTPS é a utilização de HTTP em um canal seguro.
Em HTTP/1.1 e HTTP/2, o modelo mais comum é HTTP sobre TLS sobre TCP. Em HTTP/3, a arquitetura utiliza QUIC sobre UDP e integra o handshake TLS 1.3 ao protocolo QUIC. Isso mostra por que a relação entre protocolos deve ser descrita em camadas, não como equivalências.
TLS no ONVIF
No ecossistema ONVIF, TLS pode proteger serviços expostos por HTTPS e aparece em mecanismos modernos de configuração segura. Em 2026, a ONVIF também disponibiliza especificações de TLS Configuration Add-on 2.0, evidenciando a evolução do tratamento de segurança além dos profiles tradicionais.
Ao analisar uma câmera ou VMS, não basta verificar a presença de uma opção chamada “HTTPS”. É necessário entender versões TLS suportadas, certificados, confiança, capabilities ONVIF e quais interfaces efetivamente utilizam o canal protegido.
TLS protege o streaming RTP?
Não automaticamente. Um fluxo RTP não se torna protegido apenas porque o dispositivo também oferece HTTPS. Para proteger RTP, pode ser utilizado SRTP, que aplica confidencialidade, autenticação e proteção contra replay ao tráfego RTP e RTCP.
Essa distinção é central para compreender expressões como “Secure Streaming”: proteger o plano de controle por TLS e proteger a mídia por SRTP são funções diferentes, ainda que possam coexistir no mesmo sistema.
O que verificar em uma implantação TLS
Em engenharia e operação, devem ser avaliados versão mínima aceita, algoritmos habilitados, cadeia de confiança, armazenamento da chave privada, validade dos certificados, sincronismo de relógio, renovação, revogação, nomes DNS ou IP utilizados e compatibilidade dos clientes.
A ausência de governança de certificados é uma das causas recorrentes de ambientes em que HTTPS ou TLS está tecnicamente habilitado, mas a validação de identidade é ignorada ou contornada.
Referências técnicas
[1] RESCORLA, E. RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3. RFC Editor, 2026.
[2] RESCORLA, E. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. RFC Editor, 2018. Obsoleto pelo RFC 9846.
[3] ONVIF. Client Test Specifications — TLS Configuration Add-on 2.0.
Perguntas frequentes
É um protocolo criptográfico que cria um canal seguro entre aplicações, fornecendo confidencialidade, integridade e autenticação conforme a configuração.
Desde julho de 2026, a especificação atual é o RFC 9846, que substituiu o RFC 8446 sem alterar o número da versão TLS 1.3.
Não. TLS cria o canal seguro; HTTPS é o uso de HTTP em uma origem protegida.
Não. RTP pode ser protegido por SRTP. TLS pode proteger outros canais e mecanismos de negociação, mas não transforma um fluxo RTP comum em SRTP.
