Entenda o que é HTTPS, como HTTP é protegido por um canal seguro, o papel de certificados e TLS e como HTTPS aparece no ecossistema ONVIF.
Confira!
O HTTPS — Hypertext Transfer Protocol Secure é a forma segura de utilizar as semânticas do HTTP sobre um canal protegido. Ele não substitui o HTTP por um conjunto completamente diferente de métodos e respostas; preserva a lógica de aplicação e acrescenta requisitos de autenticação do servidor, confidencialidade e integridade da comunicação.
O que é HTTPS
O esquema https é definido atualmente no RFC 9110, que também consolida as semânticas do HTTP. O documento estabelece que uma requisição destinada a um recurso HTTPS deve ser comunicada por um canal protegido e que o cliente deve aceitar apenas respostas igualmente protegidas.
Historicamente, o uso de HTTP sobre TLS foi documentado no RFC 2818. Esse RFC é hoje obsoleto e foi substituído pelo RFC 9110. Por isso, utilizar o RFC 2818 como referência principal atual para HTTPS já não é tecnicamente correto.
Como funciona o HTTPS
Em um cenário tradicional de HTTP sobre TCP, o cliente primeiro estabelece a conexão de transporte e depois negocia uma sessão TLS com o servidor. Somente após a criação do canal seguro as mensagens HTTP são transmitidas.
A negociação TLS envolve autenticação do servidor por certificado, acordo sobre parâmetros criptográficos e derivação de chaves de sessão. Depois disso, requisições e respostas HTTP trafegam protegidas pelo protocolo de segurança.
O que o HTTPS protege
Quando corretamente implementado, HTTPS busca fornecer três propriedades centrais: confidencialidade, para dificultar que terceiros leiam o conteúdo; integridade, para detectar alterações não autorizadas; e autenticação do servidor, para permitir que o cliente verifique a identidade do endpoint com o qual está se comunicando.
Essas propriedades não significam que a aplicação esteja automaticamente segura. HTTPS não corrige credenciais fracas, vulnerabilidades no software, permissões inadequadas, APIs mal projetadas ou comprometimento do endpoint.
Certificados e identidade do servidor
O certificado apresentado pelo servidor vincula uma chave pública a uma identidade validada dentro de uma cadeia de confiança. O cliente precisa verificar se o certificado é confiável, está dentro da validade, corresponde ao nome esperado e atende às políticas criptográficas aplicáveis.
Em redes corporativas e sistemas de segurança eletrônica, certificados autoassinados são comuns em equipamentos de campo. Eles podem fornecer criptografia, mas não oferecem automaticamente a mesma validação de identidade de uma cadeia de confiança corretamente administrada. O projeto precisa definir como os certificados serão provisionados, renovados e confiados.
Porta 443 e HTTPS
A porta TCP 443 é a porta padrão associada ao HTTPS em implementações tradicionais, mas ela não define o protocolo por si só. Um serviço pode operar em outra porta, desde que cliente e servidor estejam configurados adequadamente.
Além disso, a arquitetura moderna do HTTP mostra que HTTPS não deve ser reduzido à fórmula “HTTP + TCP + TLS”. HTTP/3 utiliza QUIC sobre UDP e ainda oferece o esquema HTTPS, com segurança incorporada ao transporte QUIC.
HTTPS no ONVIF
No ONVIF, HTTPS é especialmente relevante porque protege chamadas de serviço e pode ser utilizado no streaming conforme as capacidades implementadas. O Profile T cobre especificações ONVIF para HTTPS streaming em dispositivos e clientes que oferecem essa funcionalidade.
Isso ajuda a explicar por que a expressão “Secure Streaming” pode causar confusão. HTTPS protege um canal utilizado por HTTP e por determinados modos de streaming, mas não é sinônimo de SRTP e tampouco significa que todo fluxo ONVIF utilize o mesmo mecanismo criptográfico.
HTTPS versus HTTP
| Característica | HTTP | HTTPS |
| Semânticas de aplicação | HTTP | HTTP |
| Proteção do canal | Não inerente | Obrigatória |
| Confidencialidade | Não | Sim, quando o canal seguro é válido |
| Integridade criptográfica | Não | Sim |
| Autenticação do servidor | Não inerente | Sim, conforme o mecanismo de segurança |
| Esquema URI | http | https |
A diferença principal está na segurança do canal, não em uma nova semântica de métodos ou códigos de status.
HTTPS e TLS são a mesma coisa?
Não. TLS é um protocolo de segurança que cria um canal protegido para protocolos de aplicação. HTTPS é o uso das semânticas HTTP em uma origem segura. Em HTTP/1.1 e HTTP/2, isso normalmente envolve TLS sobre TCP; em HTTP/3, a segurança faz parte da arquitetura QUIC.
Essa distinção é importante em troubleshooting. Uma falha pode estar no DNS, TCP ou QUIC, na negociação TLS, no certificado, na configuração HTTP ou na aplicação.
Boas práticas em sistemas de vídeo IP
Em câmeras, VMS e demais componentes, não basta habilitar HTTPS. É necessário controlar versões de TLS, suites criptográficas suportadas, cadeia de certificados, nomes dos equipamentos, sincronismo de horário, renovação de certificados e política de desativação de interfaces inseguras.
Em ambientes ONVIF, o engenheiro também deve verificar o Profile efetivamente suportado e as capabilities anunciadas pelo dispositivo, porque a presença de HTTPS não implica que todas as funções de streaming sejam protegidas da mesma forma.
Referências técnicas
[1] FIELDING, R.; NOTTINGHAM, M.; RESCHKE, J. RFC 9110: HTTP Semantics. RFC Editor, 2022.
[2] RESCORLA, E. RFC 2818: HTTP Over TLS. RFC Editor, 2000. Documento obsoleto pelo RFC 9110.
[3] ONVIF. Profile T — For advanced video streaming.
Perguntas frequentes
HTTPS é o uso das semânticas HTTP em um canal seguro, com requisitos de confidencialidade, integridade e autenticação do servidor.
O esquema HTTPS é definido no RFC 9110. O antigo RFC 2818 foi formalmente obsoleto por esse documento.
Não. TLS é um protocolo de segurança; HTTPS é a utilização segura do HTTP. Em HTTP/1.1 e HTTP/2, TLS normalmente protege a conexão; HTTP/3 usa QUIC com segurança integrada.
Sim. O Profile T cobre especificações ONVIF para HTTPS streaming quando a funcionalidade é suportada pelo dispositivo e pelo cliente.
