O objetivo do HTTP Strict Transport Security, que é descrito em detalhes em RFC 6797 , é garantir que as solicitações sejam enviado com segurança, conforme determinado pela política do respectivo site. Não é um protocolo de segurança em si mesmo; ele simplesmente instrui o navegador da Web a forçar o uso de transporte seguro (HTTPS) em vez de transporte inseguro (HTTP) para um host específico e por um período de tempo predeterminado.
Existem algumas possibilidades de desabilitar a HSTS para um host, mas todas elas exigem acesso aos dados de texto simples do fluxo HTTPS criptografado. Isso basicamente significa que, se você estiver em uma posição de desabilitar o HSTS para um host, já estará em posição de poder manipular as comunicações com esse host e, portanto, não precisará desabilitar o HSTS para esse host.
A possibilidade mais óbvia seria a que está explicitada na seção 6.1.1 , definindo a diretiva max-age como 0. Isso fará com que um cliente compatível (navegador da Web) remova o nome do host de sua lista de hosts HSTS conhecidos.
Uma alternativa pode ser manipular diretamente a loja HSTS do navegador . Isso pode ser dificultado pelo fornecedor do navegador usando várias técnicas criptográficas (o código para o qual já foi escrito, já que é necessário para o HTTPS) ou pela separação de privilégios.
No entanto, mesmo se você fizer isso, o cabeçalho HSTS e / ou um redirecionamento permanente para usar HTTPS provavelmente serão retransmitidos na próxima solicitação para o mesmo host, que fará com que o status seguro do host seja restabelecido pelo cliente pela duração especificada pelo servidor.
A seção 12 da RFC fornece conselhos de implementação para os clientes. Particularmente, a seção 12.1 diz que não deve haver recurso do usuário em caso de erros relacionados à segurança.
No entanto, é claro, como a HSTS é simplesmente um mecanismo para dizer ao cliente para usar HTTPS em vez de HTTP para um determinado nome de host, todos os ataques relevantes contra HTTPS permanecem. Isso significa, por exemplo, que, se você puder controlar o armazenamento de certificados raiz do cliente ou se conseguir obter um certificado para o host para o qual controla a chave privada, terá a capacidade de realizar MITM com êxito nessa sessão. Isto não é afetado pela presença ou ausência de HSTS no nome do host específico.
Muitos ataques contra HTTPS podem ser consideravelmente dificultados com a implementação adequada do DNSSEC em combinação com o cliente fazendo a devida DANE ( RFC 6698 , RFC 7218 ) validação. Por exemplo, a combinação de HSTS, a validação adequada do DNSSEC e a validação adequada do DANE provavelmente teriam feito o SSL do Superfish da Lenovo -interceptando proxy impossível.