Hyper Text Transfer Protocol Secure

Pilha de protocolos TCP/IP
Camada de aplicação
DHCP DNS FTP HTTP HTTPS IMAP LDAP MGCP NNTP NTP POP ONC/RPC RTP SIP SMTP SNMP SSH Telnet TLS/SSL XMPP outros…
Camada de transporte
TCP UDP DCCP SCTP RSVP outros…
Camada de rede
OSPF IP IPv4 IPv6 ICMP ICMPv6 ECN IGMP IPsec
Camada de enlace de dados
NDP ARP túneis… L2TP PPP MAC Ethernet DSL RDIS FDDI outros…

HTTPS (Hyper Text Transfer Protocol Secure - protocolo de transferência de hipertexto seguro) é uma implementação do protocolo HTTP sobre uma camada adicional de segurança que utiliza o protocolo TLS/SSL. Essa camada adicional permite que os dados sejam transmitidos por meio de uma conexão criptografada e que se verifique a autenticidade do servidor e do cliente por meio de certificados digitais. A porta TCP usada por norma para o protocolo HTTPS é a 443.

O protocolo HTTPS é utilizado, em regra, quando se deseja evitar que a informação transmitida entre o cliente e o servidor seja visualizada por terceiros, como por exemplo no caso de compras online. A existência na barra de endereços de um cadeado (que pode ficar do lado esquerdo ou direito, dependendo do navegador utilizado) demonstra a certificação de página segura (TLS/SSL). A existência desse certificado indica o uso do protocolo HTTPS e que a comunicação entre o browser e o servidor se dará de forma segura. Para verificar a identidade do servidor é necessário um duplo clique no cadeado para exibição do certificado.

Nas URLs dos sites o início ficaria https://.

Um exemplo de conexão via HTTPS é o próprio site da Wikimedia Foundation, em que é possível acessar e editar o conteúdo dos sites através de uma conexão segura. Através da URL https://secure.wikimedia.org/wikipedia/pt/wiki/Página_principal é possível editar a Wikipédia em língua portuguesa.

Conexões HTTPS são frequentemente usadas para transações de pagamentos na World Wide Web e para transações sensíveis em sistemas de informação corporativos. Porém, o HTTPS não deve ser confundido com o protocolo "Secure HTTP" (S-HTTP), especificado na RFC 2660 e raramente utilizado.

Visão geral

Ver artigo principal: Transport Layer Security

Ilustração do protocolo de rede https e das letras www

HTTPS é um esquema URI, isto é, com exceção do esquema de tokens, é sintaticamente idêntico ao esquema HTTP utilizado para conexões normais HTTP, mas sinaliza ao navegador para utilizar uma camada adicional de criptografia utilizando o protocolo TLS (ou seu antecessor SSL) e para proteger o tráfego. TLS é especialmente adequado a HTTP porque pode fornecer proteção mesmo se apenas uma das partes comunicantes esteja autenticada. Este é o caso das transações HTTP na Internet, em que tipicamente apenas o servidor está autenticado, através da verificação de seu certificado realizada pelo cliente.

A ideia principal do HTTPS é criar um canal seguro sobre uma rede insegura. Isso garante uma proteção razoável de pessoas que realizam escutas ilegais (os chamados eavesdroppers) e de ataques de homem-no-meio (man-in-the-middle), dado que a cifragem foi adequadamente utilizada e que o certificado do servidor é verificável e confiável.

A confiança fornecida pelo HTTPS é baseada em autoridades de certificação que vêm pré-instaladas no navegador (isto é equivalente a dizer "Eu confio na autoridade de certificação VeriSign/Microsoft/etc. para me dizer em quem devo confiar"). Portanto, uma conexão HTTPS pode ser confiável se e somente se todos os itens a seguir são verdade:

1. O usuário confia que o navegador implementa corretamente HTTPS com autoridades certificadoras pré-instaladas adequadamente;
2. O usuário confia que as autoridades verificadoras só irão confiar em páginas legítimas, que não possuem nomes enganosos;
3. A página acessada fornece um certificado válido, o que significa que ele foi assinado por uma autoridade de certificação confiável;
4. O certificado identifica corretamente a página (por exemplo, quando o navegador acessa "https://exemplo.com", o certificado recebido é realmente de "Exemplo Inc." e não de alguma outra entidade);
5. Ou o tráfego na internet é confiável, ou o usuário crê que a camada de encriptação do protocolo SSL/TLS é suficientemente segura contra escutas ilegais (eavesdropping).

Utilização nos websites

Em 2017, o HTTPS era utilizado por somente 9,69% do total de domínios brasileiros registrados e 14,51% dos domínios portugueses.. Já em 2024, o HTTPS é utilizado por 86,4% do total de domínios na internet

Integração com o navegador

Muitos navegadores mostram um aviso se recebem um certificado inválido. Navegadores mais antigos, quando se conectam a uma página com um certificado inválido, mostravam ao usuário um aviso em uma caixa de diálogo e perguntavam se ele desejava continuar. Navegadores mais recentes mostram o aviso preenchendo a janela inteira e também exibem as informações de segurança da página na barra de endereços. Certificados de validação estendida tornam verde a barra de endereço em navegadores mais recentes. A maioria dos navegadores exibe, também, um aviso ao usuário quando a página visitada contém uma mistura de conteúdo criptografado e não criptografado (uma página que utiliza HTTPS mas faz referência a links HTTP de alguma forma na página, por exemplo no link de uma foto).

A maioria dos navegadores, incluindo o Firefox (mostrado aqui), utiliza a barra de endereços para avisar ao usuário que sua conexão é segura, frequentemente colorindo o fundo.

A maioria dos navegadores, como essa imagem do Firefox, alerta o usuário quando uma página visitada possui um certificado de segurança inválido.

A Electronic Frontier Foundation opinou que "em um mundo ideal, toda requisição na web poderia utilizar HTTPS como padrão" e forneceu um complemento ao Firefox chamado "HTTPS Everywhere" (HTTPS em todo lugar) que funciona em várias páginas muito visitadas.

Aspectos técnicos

Diferenças para o HTTP

As URLs HTTPS começam com https:// e utilizam a porta 443 como padrão ou, alternativamente, 8443, enquanto as URLs HTTP começam com http:// e utilizam a porta 80 como padrão.

HTTP é inseguro e sujeito a ataques de homem-no-meio e escutas ilegais, que podem levar a atacantes ganharem acesso a informações sensíveis. O HTTPS foi projetado para proteger contra esses ataques e é considerado seguro contra eles (com exceção de versões mais antigas e obsoletas do SSL).

Camadas de rede

HTTP opera na camada superior do Modelo OSI, a camada de aplicação, mas o protocolo de segurança opera em uma subcamada inferior, criptografando uma mensagem HTTP antes de sua transmissão e decriptando a mensagem assim que ela chega ao destino. Estritamente falando, HTTPS não é um protocolo separado, mas se refere ao uso do HTTP sobre uma camada encriptada de conexão SSL/TLS.

Tudo na mensagem HTTPS é criptografado, incluindo os cabeçalhos, as requisições e respostas. Com a exceção de possíveis ataques criptográficos CCA descritos na seção de limitações abaixo, o atacante pode apenas conhecer o fato de que a conexão está sendo feita entre duas partes já conhecidas por ele, o nome do domínio e o endereço IP.

Configuração do Servidor

Para preparar uma página web de modo a aceitar conexões HTTPS, o administrador deve criar um certificado de chave pública para o servidor web. Esse certificado deve ser assinado por uma autoridade de certificação confiável para que o navegador aceite a conexão e não exiba avisos. A autoridade certifica que o proprietário do certificado é o operador do servidor web que o apresenta. Uma lista de autoridades de certificação de assinatura é geralmente distribuída aos navegadores web para que eles possam verificar certificados assinados por elas.

Adquirindo certificados

Certificados assinados por autoridades podem ser gratuitos ou custar entre 13 e 1.500 dólares por ano.

Organizações podem também ter sua própria autoridade de certificação, particularmente se são responsáveis por configurar navegadores para acessar suas próprias páginas (por exemplo, páginas de uma rede interna ou de uma grande universidade). Elas podem facilmente adicionar cópias de seus próprios certificados na lista de certificados distribuída no navegador.

Existe também uma autoridade de certificação ponto a ponto, a CACert.

Uso como controle de acesso

O sistema pode também ser utilizado para autenticação de clientes, com o objetivo de limitar o acesso a servidores web a usuários autorizados. Para fazê-lo, o administrador da página tipicamente cria um certificado para cada usuário, que é carregado em seu navegador. Normalmente, o certificado contém o nome e endereço de e-mail do usuário autorizado e é automaticamente verificado pelo servidor em cada reconexão para verificar a identidade do usuário, muitas vezes sem a necessidade de utilização de senhas.

Caso uma chave privada tenha sido comprometida

O certificado pode ser revogado antes de expirar, por exemplo por conta da chave privada ter sido comprometida. Versões mais recentes dos navegadores mais populares, como Google Chrome, Mozilla Firefox, Opera e Microsoft Internet Explorer, implementam o OCSP (Protocolo de Certificação Online de Estado) para verificar essa possível falha. O navegador envia, então, o número de série do certificado a uma autoridade de certificação via OCSP e a autoridade responde, informando ao navegador se o certificado ainda é válido.

Limitações

O protocolo TLS se apresenta em duas versões: simples e mútua. A versão mútua é mais segura, porém requer que o usuário instale um certificado pessoal em seu navegador para que possa se autenticar.

Independente da estratégia utilizada (simples ou mútua), o nível de proteção depende fortemente da corretude da implementação do navegador, da implementação do servidor e dos algoritmos criptográficos suportados.

O TLS não previne a página inteira de ser indexada utilizando um web crawler e, em alguns casos, a URI do recurso criptografado pode ser inferida sabendo-se apenas o tamanho da requisição ou da resposta. Isso permite a um atacante ter acesso ao texto plano (o conteúdo propriamente dito) e ao texto encriptado (a versão criptografada do texto plano), permitindo um ataque criptográfico.

Por conta do TLS operar abaixo do HTTP e não ter conhecimento de protocolos de níveis superiores, servidores TLS podem apenas apresentar um certificado para uma combinação particular de IP/porta. Isto significa que, na maioria dos casos, não é factível usar Hospedagem Virtual Baseada em Nome com HTTPS. Existe uma solução denominada Indicação de Nomes para Servidores (SNI), que envia o nome do host ao servidor antes de encriptar a conexão, embora muitos navegadores mais antigos não suportam essa extensão. Suporte para o SNI está disponível desde o Mozilla Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 e Microsoft Internet Explorer 7.

Se controles parentais são ativados no Apple Mac OS X, páginas HTTPS devem ser explicitamente permitidas utilizando a lista Always Allow (Sempre Permitir).

De um ponto de vista arquitetural:

1. Uma conexão SSL/TLS é gerenciada pela máquina que inicializa a conexão TLS. Se. por algum motivo (roteamento, otimização de tráfego etc), essa máquina não é a aplicação do servidor e ela tem que decifrar dados, soluções têm de ser encontradas para propagar as informações de autenticação - ou certificado - do usuário para a aplicação do servidor, que necessita saber quem irá se conectar;
2. Para um TLS com autenticação mútua, a sessão SSL/TLS é gerenciada pelo primeiro servidor que inicializa a conexão. Em situações em que encriptação necessita ser propagada por servidores em cadeia, se torna mais difícil gerenciar o timeOut da sessão;
3. Com SSL/TLS com autenticação mútua, a segurança é maximal, mas no lado do cliente não há uma maneira de finalizar apropriadamente a conexão TLS e se desconectar. É preciso esperar que a sessão TLS expire ou finalize todas as aplicações do cliente;
4. Por motivos de desempenho, conteúdo estático que não é específico ao usuário ou à transação e, por isso, não privado, é normalmente entregue a um servidor não encriptado ou a uma outra instância sem TLS do servidor. Como consequência, esse conteúdo não fica protegido. Muitos navegadores alertam o usuário quando uma página misturou recursos criptografados e não criptografados.

Um ataque sofisticado de homem-no-meio foi apresentado na Blackhat Conference 2009. Esse tipo de ataque derrota a segurança fornecida pelo HTTPS modificando um link https: para um link http:, tirando proveito do fato de que poucos usuários da Internet digitam "https" nos seus navegadores. Os usuários normalmente alcançam páginas seguras clicando em um link, podendo ser, assim, levados a pensar que estão usando HTTPS quando de fato estão usando HTTP. O atacante, então, consegue se comunicar de modo não criptografado com o cliente.

Experiência do Usuário na navegação

Em julho de 2018 diversos navegadores incluindo Google Chrome (o mais utilizado no Brasil) começaram a deixar uma mensagem na barra do navegador para os Sites que não utilizam o Protocolo de segurança, colocando uma mensagem como "não seguro", e em páginas que utilizam dados dos usuários como e-mail, dados bancários e informações pessoais e não utilizam o HTTPS sofreram com a mensagem de forma explicita. A Google em sua plataforma de suporte e tutoriais aos desenvolvedores Web recomenda ações de segurança para melhorar a usabilidade e confiança dos usuários.

Ver também

• RSA (sistema criptográfico)
• Protocolo (ciência da computação)
• Handshake
• Transmission Control Protocol

História

A Netscape Communication criou o HTTPS em 1994 para seu navegador Netscape. Originalmente, o HTTPS foi utilizado com o protocolo SSL. À medida que o SSL evoluiu para o TLS (Protocolo de Segurança de Transporte), a versão atual do HTTPS foi especificada formalmente pela RFC 2818 em maio de 2000