Existe algum motivo para não aplicar o HTTPS em um site?

Um site que eu frequentei finalmente decidiu ativar o TLS para seus servidores, apenas para não o exigir, como muitos sites por aí fazem. O mantenedor afirma que o TLS deve ser opcional. Por quê?

No meu próprio site, há muito tempo eu configuro o TLS e o HSTS obrigatórios por longos períodos, e os pacotes de codificação mais fracos estão desativados. É garantido que o acesso ao texto sem formatação seja protegido com um HTTP 301 para a versão protegida por TLS. Isso afeta meu site negativamente?

Existem várias boas razões para usar o TLS

(e apenas algumas razões marginais para não fazer isso).

• Se o site tiver alguma autenticação, use HTTP expor para roubar sessões e senhas.

• Mesmo em sites estáticos, meramente informativos, o uso do TLS garante que ninguém adulterou os dados.

• Desde o Google I / O 2014 , o Google tomou várias medidas para incentivar todos os sites a usar HTTPS:

  • O Google ajudou os webmasters a configurar seus servidores de forma mais segura, mas também usou o HTTPS como um sinal de classificação .
  • Mais recentemente, o Google Chrome começou a marcar sites HTTP como não seguros , como parte de um plano de longo prazo para marcar todos os sites HTTP como não seguros .
  • A palestra Mythbusting HTTPS da equipe de desenvolvedores do Google Chrome afirma claramente sua atitude.

• O Mozilla Security Blog também anunciou a suspensão do uso do HTTP não seguro , disponibilizando todos os novos recursos apenas para sites seguros e eliminando gradualmente o acesso aos recursos do navegador para sites não seguros, especialmente os que apresentam riscos à segurança e à privacidade dos usuários .

Existem também várias boas razões para aplicar o TLS

Se você já possui um certificado amplamente confiável, por que nem sempre o usa? Praticamente todos os navegadores atuais suportam TLS e possuem certificados raiz instalados. O único problema de compatibilidade que realmente vi nos últimos anos foram os dispositivos Android e a falta de autoridade de certificação intermediária, pois o Android confia apenas nas CAs raiz. Isso pode ser facilmente evitado configurando o servidor para enviar a cadeia de certificados de volta à CA raiz.

Se o seu mantenedor ainda deseja permitir conexões HTTP sem uso direto 301 Moved Permanently, por exemplo, para garantir o acesso de alguns navegadores ou dispositivos móveis realmente antigos, não há como o navegador saber que você tem o HTTPS configurado . Além disso, você não deve implantar o HTTP Strict Transport Security (HSTS) sem 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

O problema de vários sites configurados para ambos os protocolos é reconhecido pelo The Tor Project e pela Electronic Frontier Foundation e solucionado por uma extensão HTTPS Everywhere de multibrowser:

Muitos sites na Web oferecem suporte limitado à criptografia por HTTPS, mas dificultam o uso. Por exemplo, eles podem usar como padrão HTTP não criptografado ou preencher páginas criptografadas com links que retornam ao site não criptografado.

O conteúdo misto também foi um grande problema devido a possíveis ataques XSS a sites HTTPS através da modificação de JavaScript ou CSS carregado por meio de conexão HTTP não segura. Portanto, hoje em dia todos os navegadores convencionais alertam os usuários sobre páginas com conteúdo misto e se recusam a carregá-lo automaticamente. Isso dificulta a manutenção de um site sem os 301redirecionamentos no HTTP: você deve garantir que toda página HTTP carregue apenas conteúdo HTTP (CSS, JS, imagens etc.) e toda página HTTPS carregue apenas conteúdo HTTPS. Isso é extremamente difícil de conseguir com o mesmo conteúdo em ambos.

Atualmente, TLS + HSTS são marcadores em que seu site é gerenciado por profissionais confiáveis ​​para saber o que estão fazendo. Esse é um padrão mínimo emergente de confiabilidade, conforme evidenciado pelo Google, afirmando que eles fornecerão uma classificação positiva para sites que o fizerem.

Por outro lado, é a máxima compatibilidade. Ainda existem clientes mais antigos por aí, especialmente em partes do mundo que não são os Estados Unidos, Europa ou China. HTTP simples sempre funcionará (embora nem sempre funcione bem ; isso é outra história).

TLS + HSTS: Otimize para classificação do mecanismo de pesquisa
HTTP simples: Otimize para compatibilidade

Depende do que importa mais para você.

Há um bom motivo para sites simples de somente leitura não usarem HTTPS.

• Caches da Web não podem armazenar em cache imagens que são transportadas por HTTPS.
• Algumas partes do mundo têm conexões internacionais de velocidade muito baixa, portanto dependem dos caches.
• Hospedar imagens de outro domínio requer habilidades que você não pode esperar que os operadores tenham em sites pequenos de leitura .

O mantenedor afirma que o TLS deve ser opcional. Por quê?

Para realmente conhecer a resposta a esta pergunta, você deve perguntar a eles. No entanto, podemos fazer algumas suposições.

Em ambientes corporativos, é comum a TI instalar um firewall que inspeciona o tráfego de entrada e saída de malware, atividades suspeitas do tipo CnC, conteúdo considerado inadequado para o trabalho (por exemplo, pornografia) etc. Isso fica muito mais difícil quando o tráfego é criptografado. Existem essencialmente três respostas possíveis:

1. Desista de monitorar esse tráfego.
2. Instale uma CA raiz nas máquinas dos usuários para poder executar a descriptografia e inspeção do MitM.
3. Wholesale bloqueia o tráfego criptografado.

Para um administrador de sistemas em questão, nenhuma dessas opções é particularmente atraente. Existem muitas ameaças que atacam uma rede corporativa, e é seu trabalho proteger a empresa contra eles. No entanto, o bloqueio de muitos sites aumenta totalmente a ira dos usuários, e a instalação de uma CA raiz pode parecer um pouco complicada, pois introduz considerações de privacidade e segurança para os usuários. Lembro-me de ter visto (desculpe, não consigo encontrar o tópico) um reddit de petição de administrador de sistema quando eles estavam ativando o HSTS pela primeira vez porque ele estava exatamente nessa situação e não queria bloquear todo o reddit simplesmente porque ele era obrigado pela empresa para bloquear os subreddits voltados para pornografia.

As rodas da tecnologia continuam girando à frente e você encontrará muitos que argumentam que esse tipo de proteção é antiquado e deve ser eliminado gradualmente. Mas ainda existem muitos que praticam isso, e talvez sejam eles com quem seu misterioso mantenedor está preocupado.

Tudo se resume a seus requisitos de segurança, escolha do usuário e risco de rebaixamento implícito. Desabilitar as cifras antigas do lado do servidor é amplamente necessário, pois os navegadores terão prazer em cifras absolutamente horríveis do lado do cliente em nome da experiência / conveniência do usuário. Certificar-se de que nada seu que dependa de um canal seguro para o usuário não possa ser alcançado com um método inseguro também é muito bom.

Não permitir que eu faça um downgrade explícito para HTTP inseguro quando considero que seu post no blog sobre o porquê você gosta mais de Python do que Ruby (sem dizer que sim, apenas um exemplo genérico) não é algo que me importo com os fantasmas ou com o público Eu acessei está apenas entrando no meu caminho sem uma boa razão, supondo que o HTTPS será trivial para mim.

Atualmente, existem sistemas embarcados que não têm a capacidade de usar o TLS pronto para uso ou que estão presos em implementações antigas (acho muito ruim que seja assim, mas como um usuário avançado do [insert incorporado aqui], às vezes não consigo mudar isso).

Aqui está um experimento divertido: tente fazer o download de uma versão recente do LibreSSL do site OpenBSD upstream via HTTPS com uma implementação TLS / SSL suficientemente antiga. Você não será capaz. Tentei outro dia em um dispositivo com uma versão mais antiga do OpenSSL a partir de 2012, porque queria atualizar esse sistema incorporado para coisas mais seguras e novas da fonte - não tenho o luxo de um pacote pré-construído. As mensagens de erro quando tentei não eram exatamente intuitivas, mas presumo que foi porque meu OpenSSL mais antigo não suportava as coisas certas.

Este é um exemplo em que a mudança do único HTTPS pode realmente prejudicar as pessoas: se você não tem o luxo de pacotes pré-construídos recentes e deseja resolver o problema construindo a partir da fonte, está bloqueado. Felizmente, no caso do LibreSSL, você pode voltar a solicitar HTTP explicitamente. Claro, isso não o salvará de um invasor que já está reescrevendo seu tráfego, capaz de substituir pacotes de origem por versões comprometidas e reescrever todas as somas de verificação nos corpos HTTP que descrevem os pacotes disponíveis para download nas páginas da web que você navega, mas ainda é útil em muitos aspectos. caso mais comum.

A maioria de nós não está a um download desprotegido da propriedade de um APT (Advanced Persistent Thread: jargão de segurança para agências de inteligência nacionais e outras ameaças cibernéticas extremamente bem-providas de recursos). Às vezes, eu quero apenas wgetuma documentação em texto sem formatação ou um pequeno programa cuja fonte eu possa auditar rapidamente (meus próprios utilitários / scripts no GitHub, por exemplo) em uma caixa que não suporta os pacotes de criptografia mais recentes.

Pessoalmente, eu perguntaria o seguinte: o seu conteúdo é tal que uma pessoa pode legitimamente decidir "estou bem comigo acessando conhecimento público"? Existe uma chance plausível de risco real para pessoas não técnicas acidentalmente fazendo o downgrade para HTTP do seu conteúdo? Avalie seus requisitos de segurança, privacidade forçada para seus usuários e risco de rebaixamentos implícitos contra a capacidade dos usuários que entendem os riscos de fazer uma escolha informada caso a caso para ficarem desprotegidos. É totalmente legítimo dizer que, para o seu site, não há boas razões para não aplicar o HTTPS - mas acho justo dizer que ainda existem bons casos de uso de HTTP simples por aí.

Há muita discussão aqui sobre por que tls é bom - mas isso nunca foi perguntado como no post original.

Maxthon fez 2 perguntas:

1) por que um site aleatório e sem nome decidiu manter as presenças http e https

2) Existe um impacto negativo no Maxthon que atende apenas 301 respostas a solicitações http

Com relação à primeira pergunta, não sabemos por que os provedores optaram por manter sites http e https. Pode haver muitas razões. Além dos pontos sobre compatibilidade, cache distribuído e algumas dicas sobre acessibilidade geopolítica, há também uma consideração sobre a integração de conteúdo e a evitação de mensagens feias do navegador sobre o conteúdo ser inseguro. Como Alvaro apontou, o TLS é apenas a ponta do iceberg em relação à segurança.

A segunda pergunta, no entanto, é responsável. A exposição de qualquer parte do seu site via http quando ele realmente requer https para operação segura fornece um vetor explorável para ataques. No entanto, faz algum sentido manter isso para identificar onde o tráfego está sendo direcionado incorretamente para a porta 80 no site e corrigindo a causa. Ou seja, há um impacto negativo e a oportunidade de um impacto positivo; o resultado líquido depende se você está realizando seu trabalho como administrador.

Sysadmin1138 diz que https afeta o ranking de SEO. Embora o Google tenha afirmado que afeta as classificações, os únicos estudos confiáveis que vi sugerem que a diferença é pequena. Isso não é ajudado por pessoas que deveriam saber melhor alegando que, como os sites mais bem classificados têm maior probabilidade de ter uma presença https, uma presença https melhora, portanto, a classificação.

No passado, eu tive que usar HTTP em vez de HTTPS, porque eu queria <embed>páginas de outros lugares que foram veiculadas por HTTP e não funcionariam de outra maneira.

Esse não é um bom motivo, pois significa que você tem clientes ruins / com problemas / inseguros, mas se houver processos automatizados acessando recursos por meio dos http://URLs existentes , é possível que alguns deles nem mesmo suportem https (por exemplo, busybox wget, que não possui suporte TLS internamente e o adicionou apenas mais recentemente por meio de um processo filho openssl) e seria interrompido se recebessem um redirecionamento para um URL https que eles não podem seguir.

Eu ficaria tentado a lidar com essa possibilidade escrevendo a regra de redirecionamento para excluir o redirecionamento de strings de User-Agent desconhecidas (ou conhecidas) e permitir que eles acessem o conteúdo via http, se quiserem, para que todos os navegadores reais possam se beneficiar https / hsts forçados.

Existem muito poucas boas razões para usar HTTP em vez de HTTPS em um site. Se o seu site lida com transações de qualquer tipo ou armazena qualquer tipo de dados confidenciais ou pessoais, você deve usar absolutamente o HTTPS se quiser que esses dados sejam seguros. A única razão decente que eu consideraria para não aplicar o HTTPS é se o seu site depende do cache, pois o HTTPS não funciona com o cache. No entanto, muitas vezes vale a pena sacrificar um pouco de desempenho para garantir a segurança do seu site. Também é possível que seus clientes não ofereçam suporte a HTTPS, mas, em 2017, eles deveriam.