HTTP Strict Transport Security - HTTP Strict Transport Security

HTTP Strict Transport Security ( HSTS ) é um mecanismo de política que ajuda a proteger sites contra ataques man-in-the-middle , como ataques de downgrade de protocolo e sequestro de cookies . Ele permite que os servidores da web declarem que os navegadores da web (ou outros agentes de usuário compatíveis ) devem interagir automaticamente com ele usando apenas conexões HTTPS , que fornecem Segurança da Camada de Transporte (TLS / SSL), ao contrário do HTTP inseguro usado sozinho. HSTS é um protocolo de rastreamento de padrões IETF e é especificado no RFC 6797.

A política HSTS é comunicada pelo servidor ao agente do usuário por meio de um campo de cabeçalho de resposta HTTP denominado " Strict-Transport-Security ". A Política HSTS especifica um período de tempo durante o qual o agente do usuário deve acessar o servidor apenas de maneira segura. Os sites que usam HSTS geralmente não aceitam HTTP de texto não criptografado, rejeitando conexões por HTTP ou redirecionando sistematicamente os usuários para HTTPS (embora isso não seja exigido pela especificação). A consequência disso é que um agente de usuário incapaz de fazer TLS não será capaz de se conectar ao site.

A proteção só se aplica após um usuário ter visitado o site pelo menos uma vez, contando com o princípio de confiança no primeiro uso. A forma como essa proteção funciona é que um usuário que insere ou seleciona um URL para o site que especifica HTTP, atualizará automaticamente para HTTPS, sem fazer uma solicitação HTTP, o que evita que o ataque HTTP man-in-the-middle ocorra.

Histórico de especificações

A especificação HSTS foi publicada como RFC 6797 em 19 de novembro de 2012 após ser aprovada em 2 de outubro de 2012 pelo IESG para publicação como um RFC padrão proposto . Os autores o submeteram originalmente como um rascunho da Internet em 17 de junho de 2010. Com a conversão para um rascunho da Internet, o nome da especificação foi alterado de "Strict Transport Security" (STS) para "HTTP Strict Transport Security", porque a especificação se aplica apenas a HTTP . O campo de cabeçalho de resposta HTTP definido na especificação HSTS, entretanto, permanece com o nome "Strict-Transport-Security".

A última chamada "versão da comunidade" da especificação então chamada "STS" foi publicada em 18 de dezembro de 2009, com revisões baseadas no feedback da comunidade.

O rascunho da especificação original por Jeff Hodges do PayPal , Collin Jackson e Adam Barth foi publicado em 18 de setembro de 2009.

A especificação HSTS é baseada no trabalho original de Jackson e Barth, conforme descrito em seu artigo "ForceHTTPS: Protegendo sites de alta segurança contra ataques de rede".

Além disso, o HSTS é a realização de uma faceta de uma visão geral para melhorar a segurança da web, apresentada por Jeff Hodges e Andy Steingruebl em seu artigo de 2010, The Need for Coherent Web Security Policy Framework (s) .

Visão geral do mecanismo HSTS

Um servidor implementa uma política HSTS fornecendo um cabeçalho em uma conexão HTTPS (cabeçalhos HSTS em HTTP são ignorados). Por exemplo, um servidor pode enviar um cabeçalho de modo que futuras solicitações para o domínio para o próximo ano (máximo de idade é especificado em segundos; 31536000 é igual a um ano não bissexto) use apenas HTTPS: Strict-Transport-Security: max-age=31536000.

Quando um aplicativo da web emite política HSTS para agentes de usuário, os agentes de usuário em conformidade se comportam da seguinte maneira (RFC 6797):

  1. Transforme automaticamente quaisquer links inseguros que façam referência ao aplicativo da web em links seguros (por exemplo http://example.com/some/page/, serão modificados https://example.com/some/page/ antes de acessar o servidor).
  2. Se a segurança da conexão não puder ser garantida (por exemplo, o certificado TLS do servidor não é confiável), o agente do usuário deve encerrar a conexão (RFC 6797 seção 8.4, Erros no estabelecimento de transporte seguro) e não deve permitir que o usuário acesse o aplicativo da web (seção 12.1, Sem recurso do usuário).

A política HSTS ajuda a proteger os usuários de aplicativos da web contra alguns ataques passivos ( espionagem ) e ativos à rede . Um invasor man-in-the-middle tem uma capacidade bastante reduzida de interceptar solicitações e respostas entre um usuário e um servidor de aplicativos da web, enquanto o navegador do usuário tem a política HSTS em vigor para esse aplicativo da web.

Aplicabilidade

A vulnerabilidade de segurança mais importante que o HSTS pode corrigir são os ataques man-in-the-middle de remoção de SSL , introduzidos publicamente pela primeira vez por Moxie Marlinspike em sua palestra BlackHat Federal de 2009 "Novos truques para derrotar o SSL na prática". O ataque de remoção de SSL (e TLS ) funciona convertendo de forma transparente uma conexão HTTPS segura em uma conexão HTTP simples. O usuário pode ver que a conexão não é segura , mas, principalmente, não há como saber se a conexão deve ser segura. No momento da palestra de Marlinspike, muitos sites não usavam TLS / SSL, portanto não havia como saber (sem conhecimento prévio) se o uso de HTTP simples era devido a um ataque ou simplesmente porque o site não havia implementado TLS / SSL. Além disso, nenhum aviso é apresentado ao usuário durante o processo de downgrade, tornando o ataque bastante sutil para todos, exceto os mais vigilantes. A ferramenta sslstrip de Marlinspike automatiza totalmente o ataque.

O HSTS soluciona esse problema informando ao navegador que as conexões com o site sempre devem usar TLS / SSL. O cabeçalho HSTS pode ser removido pelo invasor se esta for a primeira visita do usuário. Google Chrome , Mozilla Firefox , Internet Explorer e Microsoft Edge tentam limitar esse problema incluindo uma lista "pré-carregada" de sites HSTS. Infelizmente, essa solução não pode ser dimensionada para incluir todos os sites da Internet. Veja as limitações abaixo.

O HSTS também pode ajudar a evitar que as credenciais de login de um site com base em cookies sejam roubadas por ferramentas amplamente disponíveis, como Firesheep .

Como o HSTS é limitado no tempo, ele é sensível a ataques que envolvem a alteração do horário do computador da vítima, por exemplo, usando pacotes NTP falsos .

Limitações

A solicitação inicial permanece desprotegida de ataques ativos se usar um protocolo inseguro, como HTTP simples, ou se o URI da solicitação inicial foi obtido por meio de um canal inseguro . O mesmo se aplica à primeira solicitação após o período de atividade especificado na política HSTS anunciada max-age (os sites devem definir um período de vários dias ou meses, dependendo da atividade e do comportamento do usuário). O Google Chrome , Mozilla Firefox e Internet Explorer / Microsoft Edge corrigem essa limitação implementando uma "lista pré-carregada de HSTS", que é uma lista que contém sites conhecidos que suportam HSTS. Essa lista é distribuída com o navegador para que ele também use HTTPS para a solicitação inicial dos sites listados. Conforme mencionado anteriormente, essas listas pré-carregadas não podem ser dimensionadas para cobrir toda a web. Uma solução potencial pode ser alcançada usando registros DNS para declarar a Política HSTS e acessando-os com segurança via DNSSEC , opcionalmente com impressões digitais de certificado para garantir a validade (o que requer a execução de um resolvedor de validação para evitar problemas de última milha ).

Junade Ali observou que o HSTS é ineficaz contra o uso de domínios falsos; usando ataques baseados em DNS, é possível para um interceptor Man-in-the-Middle servir o tráfego de um domínio artificial que não está na lista de pré-carregamento do HSTS. Isso pode ser possível por ataques de spoofing de DNS, ou simplesmente um domínio nome que enganosamente se assemelha ao nome de domínio real, como www.example.org em vez de www.example.com .

Mesmo com uma "lista pré-carregada de HSTS", o HSTS não pode impedir ataques avançados contra o próprio TLS, como os ataques BEAST ou CRIME introduzidos por Juliano Rizzo e Thai Duong. Os ataques contra o próprio TLS são ortogonais à aplicação da política de HSTS. Ele também não pode proteger contra ataques ao servidor - se alguém o comprometer, ele fornecerá qualquer conteúdo por TLS.

Consulte a RFC  6797 para obter uma discussão sobre as considerações gerais de segurança do HSTS.

Questões de privacidade

O HSTS pode ser usado para marcar quase indelevelmente os navegadores visitantes com dados de identificação recuperáveis ​​( supercookies ) que podem persistir dentro e fora dos modos de privacidade " incógnitos " do navegador . Ao criar uma página da web que faz várias solicitações HTTP para domínios selecionados, por exemplo, se vinte solicitações de navegador para vinte domínios diferentes forem usadas, teoricamente mais de um milhão de visitantes podem ser distinguidos (2 20 ) devido às solicitações resultantes que chegam via HTTP vs. HTTPS; sendo o último os "bits" binários registrados anteriormente, estabelecidos anteriormente por meio dos cabeçalhos HSTS.

Suporte de navegador

Página de configurações para HTTPS Strict Transport Security no Chromium 45, mostrando o status da política de segurança para o domínio "en.wikipedia.org".

Práticas recomendadas de implantação

Dependendo da implantação real, existem certas ameaças (por exemplo, ataques de injeção de cookies) que podem ser evitadas seguindo as práticas recomendadas.

  • Os hosts HSTS devem declarar a política HSTS em seu nome de domínio de nível superior. Por exemplo, um host HSTS em https://sub.example.com também deve responder com o cabeçalho HSTS em https://example.com. O cabeçalho deve especificar a includeSubDomainsdiretiva.
  • Além da implantação do HSTS, um host para https://www.example.com deve incluir uma solicitação para um recurso de https://example.com para garantir que o HSTS para o domínio pai seja definido e proteja o usuário de possíveis ataques de injeção de cookie executados por um MITM que injetaria uma referência ao domínio pai (ou mesmo http://nonexistentpeer.example.com), que o invasor então responderia.

Veja também

Referências

links externos