HTTPS

Hypertext Transfer Protocol Secure (HTTPS) é uma extensão do Hypertext Transfer Protocol (HTTP). Ele usa criptografia para comunicação segura em uma rede de computadores e é amplamente usado na Internet. No HTTPS, o protocolo de comunicação é criptografado usando Transport Layer Security (TLS) ou, anteriormente, Secure Sockets Layer (SSL). O protocolo também é conhecido como HTTP sobre TLS ou HTTP sobre SSL.

As principais motivações para o HTTPS são a autenticação do site acessado e a proteção da privacidade e integridade dos dados trocados enquanto estão em trânsito. Ele protege contra ataques man-in-the-middle, e a criptografia de cifra de bloco bidirecional de comunicações entre um cliente e servidor protege as comunicações contra espionagem e adulteração. O aspecto de autenticação do HTTPS exige que um terceiro confiável assine certificados digitais do lado do servidor. Historicamente, essa era uma operação cara, o que significava que conexões HTTPS totalmente autenticadas geralmente eram encontradas apenas em serviços de transações de pagamento seguras e outros sistemas de informações corporativas seguras na World Wide Web. Em 2016, uma campanha da Electronic Frontier Foundation com o apoio de desenvolvedores de navegadores da web fez com que o protocolo se tornasse mais prevalente. O HTTPS agora é usado com mais frequência pelos usuários da Web do que o HTTP original e não seguro, principalmente para proteger a autenticidade da página em todos os tipos de sites, contas seguras e manter as comunicações, a identidade e a navegação na Web do usuário privadas.

Visão geral

URL começando com o esquema HTTPS e o rótulo de nome de domínio WWW

O esquema Uniform Resource Identifier (URI) HTTPS tem sintaxe de uso idêntica ao esquema HTTP. No entanto, o HTTPS sinaliza ao navegador para usar uma camada de criptografia adicional de SSL/TLS para proteger o tráfego. O SSL/TLS é especialmente adequado para HTTP, pois pode fornecer alguma proteção mesmo se apenas um lado da comunicação for autenticado. É o caso das transações HTTP pela Internet, onde normalmente apenas o servidor é autenticado (pelo cliente examinando o certificado do servidor).

O HTTPS cria um canal seguro em uma rede insegura. Isso garante proteção razoável contra espiões e ataques man-in-the-middle, desde que sejam usados conjuntos de cifras adequados e que o certificado do servidor seja verificado e confiável.

Como o HTTPS pega carona o HTTP inteiramente em cima do TLS, todo o protocolo HTTP subjacente pode ser criptografado. Isso inclui o URL da solicitação, parâmetros de consulta, cabeçalhos e cookies (que geralmente contêm informações de identificação sobre o usuário). No entanto, como os endereços de sites e os números de porta são necessariamente parte dos protocolos TCP/IP subjacentes, o HTTPS não pode proteger sua divulgação. Na prática, isso significa que, mesmo em um servidor da Web configurado corretamente, os invasores podem inferir o endereço IP e o número da porta do servidor da Web e, às vezes, até o nome do domínio (por exemplo, www.example.org, mas não o restante da URL) que com quem um usuário está se comunicando, juntamente com a quantidade de dados transferidos e a duração da comunicação, mas não o conteúdo da comunicação.

Os navegadores da Web sabem como confiar em sites HTTPS com base em autoridades de certificação que vêm pré-instaladas em seu software. As autoridades de certificação estão, desta forma, sendo confiáveis pelos criadores de navegadores da web para fornecer certificados válidos. Portanto, um usuário deve confiar em uma conexão HTTPS para um site se e somente se todas as condições a seguir forem verdadeiras:

• O usuário confia que seu dispositivo, hospedando o navegador e o método para obter o próprio navegador, não é comprometido (ou seja, não há nenhum ataque de cadeia de suprimentos).
• O usuário confia que o software do navegador implemente corretamente HTTPS com autoridades de certificados pré-instaladas corretamente.
• O usuário confia na autoridade de certificação para garantir apenas sites legítimos (ou seja, a autoridade de certificação não está comprometida e não há erro de emissão de certificados).
• O site fornece um certificado válido, o que significa que foi assinado por uma autoridade confiável.
• O certificado identifica corretamente o site (por exemplo, quando o navegador visita "https://example.com", o certificado recebido é corretamente para "example.com" e não para outra entidade).
• O usuário confia que a camada de criptografia do protocolo (SSL/TLS) é suficientemente segura contra os eavesdroppers.

HTTPS é especialmente importante em redes inseguras e redes que podem estar sujeitas a adulteração. Redes inseguras, como pontos de acesso Wi-Fi públicos, permitem que qualquer pessoa na mesma rede local detecte pacotes e descubra informações confidenciais não protegidas por HTTPS. Além disso, algumas redes WLAN gratuitas e pagas foram observadas adulterando páginas da Web, envolvendo-se na injeção de pacotes para veicular seus próprios anúncios em outros sites. Essa prática pode ser explorada de forma maliciosa de várias maneiras, como injetar malware em páginas da Web e roubar a identidade dos usuários. informação privada.

O HTTPS também é importante para conexões pela rede Tor, pois os nós Tor maliciosos podem danificar ou alterar o conteúdo que passa por eles de maneira insegura e injetar malware na conexão. Esta é uma das razões pelas quais a Electronic Frontier Foundation e o Tor Project iniciaram o desenvolvimento do HTTPS Everywhere, que está incluído no Tor Browser.

À medida que mais informações são reveladas sobre vigilância em massa global e criminosos que roubam informações pessoais, o uso da segurança HTTPS em todos os sites está se tornando cada vez mais importante, independentemente do tipo de conexão com a Internet usada. Embora os metadados sobre páginas individuais que um usuário visita possam não ser considerados confidenciais, quando agregados, eles podem revelar muito sobre o usuário e comprometer a privacidade do usuário.

A implantação de HTTPS também permite o uso de HTTP/2 e HTTP/3 (e seus antecessores SPDY e QUIC), que são novas versões de HTTP projetadas para reduzir o tempo de carregamento, o tamanho e a latência da página.

Recomenda-se usar HTTP Strict Transport Security (HSTS) com HTTPS para proteger os usuários contra ataques man-in-the-middle, especialmente remoção de SSL.

HTTPS não deve ser confundido com o HTTP Seguro (S-HTTP) raramente usado especificado na RFC 2660.

Uso em sites

Em abril de 2018, 33,2% dos 1.000.000 principais sites da Alexa usam HTTPS como padrão, 57,1% dos 137.971 sites mais populares da Internet têm uma implementação segura de HTTPS e 70% dos carregamentos de página (medidos pelo Firefox Telemetria) usam HTTPS. No entanto, apesar do lançamento do TLS 1.3 em 2018, a adoção tem sido lenta, com muitos ainda permanecendo no protocolo TLS 1.2 mais antigo.

Integração do navegador

A maioria dos navegadores exibe um aviso se receber um certificado inválido. Navegadores mais antigos, ao se conectarem a um site com um certificado inválido, apresentariam ao usuário uma caixa de diálogo perguntando se deseja continuar. Os navegadores mais recentes exibem um aviso em toda a janela. Os navegadores mais recentes também exibem com destaque as informações de segurança do site na barra de endereço. Os certificados de validação estendida mostram a entidade legal nas informações do certificado. A maioria dos navegadores também exibe um aviso ao usuário ao visitar um site que contém uma mistura de conteúdo criptografado e não criptografado. Além disso, muitos filtros da web retornam um aviso de segurança ao visitar sites proibidos.

A Electronic Frontier Foundation, opinando que "Em um mundo ideal, cada solicitação da web poderia ser padronizada para HTTPS", forneceu um complemento chamado HTTPS Everywhere para Mozilla Firefox, Google Chrome, Chromium e Android, que habilita o HTTPS por padrão para centenas de sites usados com frequência.

Forçar um navegador da Web a carregar apenas conteúdo HTTPS foi suportado no Firefox a partir da versão 83. A partir da versão 94, o Google Chrome pode "sempre usar conexões seguras" se alternado nas configurações do navegador.

Segurança

A segurança do HTTPS é a do TLS subjacente, que normalmente usa chaves públicas e privadas de longo prazo para gerar uma chave de sessão de curto prazo, que é usada para criptografar o fluxo de dados entre o cliente e o servidor. Os certificados X.509 são usados para autenticar o servidor (e às vezes também o cliente). Como consequência, as autoridades certificadoras e os certificados de chave pública são necessários para verificar a relação entre o certificado e seu proprietário, bem como para gerar, assinar e administrar a validade dos certificados. Embora isso possa ser mais benéfico do que verificar as identidades por meio de uma rede de confiança, as divulgações de vigilância em massa de 2013 chamaram a atenção para as autoridades de certificação como um potencial ponto fraco que permite ataques man-in-the-middle. Uma propriedade importante nesse contexto é o sigilo de encaminhamento, que garante que comunicações criptografadas gravadas no passado não possam ser recuperadas e descriptografadas caso chaves ou senhas secretas de longo prazo sejam comprometidas no futuro. Nem todos os servidores da Web fornecem sigilo de encaminhamento.

Para que o HTTPS seja eficaz, um site deve ser totalmente hospedado em HTTPS. Se algum conteúdo do site for carregado por HTTP (scripts ou imagens, por exemplo) ou se apenas uma determinada página que contém informações confidenciais, como uma página de login, for carregada por HTTPS enquanto o restante o site for carregado em HTTP simples, o usuário ficará vulnerável a ataques e vigilância. Além disso, os cookies em um site servido por HTTPS devem ter o atributo seguro ativado. Em um site que contém informações confidenciais, o usuário e a sessão serão expostos sempre que esse site for acessado com HTTP em vez de HTTPS.

Técnico

Diferença de HTTP

URLs HTTPS começam com "https://" e use a porta 443 por padrão, enquanto os URLs HTTP começam com "http://" e use a porta 80 por padrão.

O HTTP não é criptografado e, portanto, é vulnerável a ataques man-in-the-middle e espionagem, que podem permitir que invasores obtenham acesso a contas de sites e informações confidenciais e modifiquem páginas da Web para injetar malware ou anúncios. O HTTPS foi projetado para resistir a esses ataques e é considerado seguro contra eles (com exceção das implementações de HTTPS que usam versões obsoletas do SSL).

Camadas de rede

HTTP opera na camada mais alta do modelo TCP/IP—a camada de aplicação; assim como o protocolo de segurança TLS (operando como uma subcamada inferior da mesma camada), que criptografa uma mensagem HTTP antes da transmissão e descriptografa uma mensagem na chegada. Estritamente falando, HTTPS não é um protocolo separado, mas se refere ao uso de HTTP comum em uma conexão SSL/TLS criptografada.

HTTPS criptografa todo o conteúdo da mensagem, incluindo os cabeçalhos HTTP e os dados de solicitação/resposta. Com exceção do possível ataque criptográfico CCA descrito na seção de limitações abaixo, um invasor deve, no máximo, descobrir que uma conexão está ocorrendo entre duas partes, junto com seus nomes de domínio e endereços IP.

Configuração do servidor

Para preparar um servidor web para aceitar conexões HTTPS, o administrador deve criar um certificado de chave pública para o servidor web. Este certificado deve ser assinado por uma autoridade de certificação confiável para que o navegador da web o aceite sem aviso. A autoridade certifica que o titular do certificado é o operador do servidor web que o apresenta. Os navegadores da Web geralmente são distribuídos com uma lista de certificados de assinatura das principais autoridades de certificação para que possam verificar os certificados assinados por eles.

Aquisição de certificados

Existem várias autoridades de certificação comercial, oferecendo certificados SSL/TLS pagos de vários tipos, incluindo certificados de validação estendida.

O Let's Encrypt, lançado em abril de 2016, fornece serviço gratuito e automatizado que fornece certificados SSL/TLS básicos para sites. De acordo com a Electronic Frontier Foundation, o Let's Encrypt tornará a troca de HTTP para HTTPS "tão fácil quanto emitir um comando ou clicar em um botão". A maioria dos hosts da Web e provedores de nuvem agora utiliza o Let's Encrypt, fornecendo certificados gratuitos para seus clientes.

Usar como controle de acesso

O sistema também pode ser usado para autenticação de clientes, a fim de limitar o acesso a um servidor da Web a usuários autorizados. Para fazer isso, o administrador do site normalmente cria um certificado para cada usuário, que o usuário carrega em seu navegador. Normalmente, o certificado contém o nome e o endereço de e-mail do usuário autorizado e é verificado automaticamente pelo servidor em cada conexão para verificar a identidade do usuário, possivelmente sem exigir uma senha.

Em caso de chave secreta (privada) comprometida

Uma propriedade importante neste contexto é o sigilo de encaminhamento perfeito (PFS). Possuir uma das chaves secretas assimétricas de longo prazo usadas para estabelecer uma sessão HTTPS não deve facilitar a derivação da chave de sessão de curto prazo para descriptografar a conversa, mesmo posteriormente. A troca de chaves Diffie-Hellman (DHE) e a troca de chaves Diffie-Hellman da curva elíptica (ECDHE) são em 2013 os únicos esquemas conhecidos por terem essa propriedade. Em 2013, apenas 30% das sessões dos navegadores Firefox, Opera e Chromium o usaram e quase 0% das sessões do Safari e do Microsoft Internet Explorer da Apple. O TLS 1.3, publicado em agosto de 2018, abandonou o suporte para cifras sem sigilo direto. Em fevereiro de 2020, 96,6% dos servidores da Web pesquisados oferecem suporte a alguma forma de sigilo de encaminhamento e 52,1% usarão sigilo de encaminhamento com a maioria dos navegadores.

Revogação de certificado

Um certificado pode ser revogado antes de expirar, por exemplo, porque o sigilo da chave privada foi comprometido. Versões mais recentes de navegadores populares como Firefox, Opera e Internet Explorer no Windows Vista implementam o Protocolo de Status de Certificado Online (OCSP) para verificar se esse não é o caso. O navegador envia o número de série do certificado para a autoridade certificadora ou seu representante via OCSP (Online Certificate Status Protocol) e a autoridade responde, informando ao navegador se o certificado ainda é válido ou não. A CA também pode emitir uma CRL para informar às pessoas que esses certificados foram revogados. As CRLs não são mais exigidas pelo fórum CA/Browser, no entanto, elas ainda são amplamente utilizadas pelas CAs. A maioria dos status de revogação na Internet desaparece logo após a expiração dos certificados.

Limitações

A criptografia SSL (Secure Sockets Layer) e TLS (Transport Layer Security) pode ser configurada em dois modos: simples e mútuo. No modo simples, a autenticação é realizada apenas pelo servidor. A versão mútua exige que o usuário instale um certificado de cliente pessoal no navegador da web para autenticação do usuário. Em ambos os casos, o nível de proteção depende da exatidão da implementação do software e dos algoritmos criptográficos em uso.

SSL/TLS não impede a indexação do site por um rastreador da Web e, em alguns casos, o URI do recurso criptografado pode ser inferido conhecendo apenas o tamanho da solicitação/resposta interceptada. Isso permite que um invasor tenha acesso ao texto simples (o conteúdo estático disponível publicamente) e ao texto criptografado (a versão criptografada do conteúdo estático), permitindo um ataque criptográfico.

Como o TLS opera em um nível de protocolo abaixo do HTTP e não tem conhecimento dos protocolos de nível superior, os servidores TLS podem apresentar estritamente apenas um certificado para um determinado endereço e combinação de porta. No passado, isso significava que não era possível usar hospedagem virtual baseada em nome com HTTPS. Existe uma solução chamada Server Name Indication (SNI), que envia o nome do host para o servidor antes de criptografar a conexão, embora muitos navegadores antigos não suportem essa extensão. O suporte para SNI está disponível desde Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 e Internet Explorer 7 no Windows Vista.

Do ponto de vista arquitetônico:

• Uma conexão SSL/TLS é gerenciada pela primeira máquina frontal que inicia a conexão TLS. Se, por qualquer motivo (rote, otimização de tráfego, etc.), esta máquina frontal não é o servidor de aplicativos e tem de decifrar dados, as soluções devem ser encontradas para propagar informações de autenticação do usuário ou certificado para o servidor de aplicativos, o que precisa saber quem vai ser conectado.
• Para SSL/TLS com autenticação mútua, a sessão SSL/TLS é gerenciada pelo primeiro servidor que inicia a conexão. Em situações em que a criptografia tem de ser propagada ao longo de servidores em cadeia, o gerenciamento de timeout de sessão torna-se extremamente complicado para implementar.
• A segurança é máxima com SSL/TLS mútuo, mas no lado do cliente não há nenhuma maneira de terminar corretamente a conexão SSL/TLS e desconectar o usuário, exceto esperando que a sessão do servidor expire ou fechando todas as aplicações de clientes relacionadas.

Um tipo sofisticado de ataque man-in-the-middle chamado SSL stripping foi apresentado na Conferência Blackhat de 2009. Esse tipo de ataque anula a segurança fornecida pelo HTTPS alterando o https: em um link http:, aproveitando o fato de que poucos internautas realmente digitam "https" na interface do navegador: eles acessam um site seguro clicando em um link e, portanto, são levados a pensar que estão usando HTTPS quando, na verdade, estão usando HTTP. O invasor então se comunica claramente com o cliente. Isso levou ao desenvolvimento de uma contramedida em HTTP chamada HTTP Strict Transport Security.

O HTTPS demonstrou ser vulnerável a uma variedade de ataques de análise de tráfego. Os ataques de análise de tráfego são um tipo de ataque de canal lateral que depende de variações no tempo e no tamanho do tráfego para inferir propriedades sobre o próprio tráfego criptografado. A análise de tráfego é possível porque a criptografia SSL/TLS altera o conteúdo do tráfego, mas tem um impacto mínimo no tamanho e no tempo do tráfego. Em maio de 2010, um trabalho de pesquisa de pesquisadores da Microsoft Research e da Universidade de Indiana descobriu que dados confidenciais detalhados do usuário podem ser inferidos a partir de canais laterais, como tamanhos de pacotes. Os pesquisadores descobriram que, apesar da proteção HTTPS em vários aplicativos da web de alto perfil e de primeira linha em saúde, tributação, investimento e pesquisa na web, um intruso poderia inferir as doenças/medicamentos/cirurgias do usuário, seu/sua sua renda familiar e segredos de investimento. Embora este trabalho tenha demonstrado a vulnerabilidade do HTTPS à análise de tráfego, a abordagem apresentada pelos autores exigia uma análise manual e focava especificamente em aplicações web protegidas por HTTPS.

O fato de que a maioria dos sites modernos, incluindo Google, Yahoo! e Amazon, usam HTTPS causa problemas para muitos usuários que tentam acessar pontos de acesso Wi-Fi públicos, porque uma página de login de ponto de acesso Wi-Fi falha ao carregar se o o usuário tenta abrir um recurso HTTPS. Vários sites, como neverssl.com, garantem que permanecerão sempre acessíveis por HTTP.

História

A Netscape Communications criou o HTTPS em 1994 para seu navegador Netscape Navigator. Originalmente, o HTTPS era usado com o protocolo SSL. À medida que o SSL evoluiu para o Transport Layer Security (TLS), o HTTPS foi formalmente especificado pela RFC 2818 em maio de 2000. O Google anunciou em fevereiro de 2018 que seu navegador Chrome marcaria sites HTTP como "Não seguros" após julho de 2018. Essa mudança foi para encorajar os proprietários de sites a implementar o HTTPS, como um esforço para tornar a World Wide Web mais segura.