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

Hoje em dia, TLS + HSTS são marcadores de 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 fornecerá classificação positiva para sites que o fizerem.

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

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

Depende do que é mais importante para você.

Há uma boa razão para sites simples somente leitura não usarem HTTPS.

• Os 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, dependa dos caches.
• Hospedar imagens de outro domínio requer habilidades que você não pode esperar que os operadores de pequenos sites somente leitura tenham.

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

Para realmente saber a resposta a esta pergunta, você deve perguntar a eles. Podemos, no entanto, fazer algumas suposições.

Em ambientes corporativos, é comum a TI instalar um firewall que inspeciona o tráfego de entrada e saída em busca de malware, atividades suspeitas do tipo CnC, conteúdo considerado impróprio para o trabalho (por exemplo, pornografia) etc. Isso se torna 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 que você possa realizar a descriptografia e inspeção do MitM.
3. Tráfego criptografado de bloqueio por atacado.

Para um administrador de sistema preocupado, nenhuma dessas opções é particularmente atraente. Existem muitas ameaças que atacam uma rede corporativa e é seu trabalho proteger a empresa contra elas. No entanto, bloquear um grande número de sites aumenta totalmente a ira dos usuários, e instalar uma CA raiz pode parecer um pouco desagradável, 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) uma petição do reddit de administrador de sistema quando eles estavam ligando o HSTS pela primeira vez porque ele estava exatamente nessa situação e não queria bloquear todo o reddit simplesmente porque foi compelido pelo negócio para bloquear os subreddits focados em pornografia.

As rodas da tecnologia continuam girando, e você encontrará muitos que argumentam que esse tipo de proteção é antiquado e deve ser eliminado gradualmente. Mas ainda há muitos que o praticam, e talvez sejam eles que preocupam seu misterioso mantenedor.

Existem vários bons motivos para usar o TLS

(e apenas algumas razões marginais para não fazê-lo).

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

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

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

  • O Google tem ajudado 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 substituição 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 recursos que representam riscos à segurança e privacidade dos usuários .

Há também vários bons motivos para aplicar o TLS

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

Se o seu mantenedor ainda quiser permitir conexões HTTP sem direto 301 Moved Permanently, digamos para garantir o acesso de alguns navegadores realmente antigos ou dispositivos móveis, não há como o navegador saber que você tem HTTPS configurado . Além disso, você não deve implantar 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 resolvido por uma extensão multibrowser HTTPS Everywhere :

Muitos sites na Web oferecem algum suporte limitado para 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 era um grande problema devido a possíveis ataques XSS a sites HTTPS por meio da modificação de JavaScript ou CSS carregado por conexão HTTP não segura. Portanto, hoje em dia, todos os navegadores convencionais avisam 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 301redirecionamentos em 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.

Tudo se resume aos seus requisitos de segurança, escolha do usuário e risco de rebaixamento implícito. Desativar cifras antigas do lado do servidor é amplamente necessário porque os navegadores cairão alegremente 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 é, obviamente, também muito bom.

Não me permitindo fazer downgrade explicitamente para HTTP inseguro quando considerei que sua postagem no blog sobre por que você gosta mais de Python do que de Ruby (não estou dizendo que gosta, apenas um exemplo genérico) não é algo que me importe que os fantasmas ou o público saibam Eu acessei está apenas atrapalhando sem um bom motivo, presumindo que o HTTPS será trivial para mim.

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

Aqui está um experimento divertido: tente baixar uma versão recente do LibreSSL do site upstream do OpenBSD por HTTPS com uma implementação TLS/SSL suficientemente antiga. Você não será capaz. Eu tentei outro dia em um dispositivo com uma compilação OpenSSL mais antiga de 2012 ou mais, porque queria atualizar este sistema incorporado para coisas novas e mais seguras 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 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 corrigir o problema sozinho compilando a partir do código-fonte, você 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 em corpos HTTP descrevendo os pacotes disponíveis para download nas páginas da Web em que você navega, mas ainda é útil no muito caso mais comum.

A maioria de nós não está a um download inseguro de ser propriedade de um APT (Advanced Persistent Thread: jargão de segurança para agências nacionais de inteligência e outras ameaças cibernéticas com recursos extremamente bons). Às vezes, eu só quero wgetalguma documentação de texto simples ou um pequeno programa cuja fonte eu possa auditar rapidamente (meus próprios utilitários/scripts minúsculos no GitHub, por exemplo) em uma caixa que não oferece suporte aos conjuntos de cifras mais recentes.

Pessoalmente, eu perguntaria o seguinte: o seu conteúdo é tal que uma pessoa pode legitimamente decidir "Estou bem em acessar o conhecimento público"? Existe uma chance plausível de risco real para pessoas não técnicas fazerem downgrade acidentalmente para HTTP para o seu conteúdo? Pondere seus requisitos de segurança, os requisitos de privacidade imposta para seus usuários e o risco de downgrades implícitos em relação à capacidade dos usuários que entendem os riscos de fazer uma escolha informada caso a caso para não serem seguros. É totalmente legítimo dizer que, para o seu site, não há um bom motivo para não aplicar o HTTPS - mas acho justo dizer que ainda existem bons casos de uso para HTTP simples por aí.

Há muita discussão aqui sobre por que o tls é bom - mas isso nunca foi perguntado 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 para o Maxthon atender apenas 301 respostas a solicitações http

Com relação à primeira pergunta, não sabemos por que os provedores optaram por manter os 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 integração de conteúdo e como evitar mensagens feias do navegador sobre o conteúdo ser inseguro. Como Alvaro apontou, o TLS é apenas a ponta do iceberg no que diz respeito à segurança.

A segunda pergunta, no entanto, é respondível. Expor qualquer parte do seu site via http quando na verdade 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 em seu site e corrigir a causa. Ou seja, há tanto um impacto negativo quanto a oportunidade de um impacto positivo, o resultado líquido depende se você está fazendo seu trabalho como administrador.

Sysadmin1138 diz que o https afeta as classificações de SEO. Embora o Google tenha declarado que isso 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, uma vez que os sites mais bem classificados têm maior probabilidade de ter uma presença https, uma presença https, portanto, melhora as classificações.

Esta não é uma boa razão, pois significa que você tem clientes ruins/quebrados/inseguros, mas se houver processos automatizados acessando recursos através das http://urls existentes, é possível que alguns deles nem sequer suportem https (por exemplo , busybox wget, que não 'não tem suporte TLS internamente e apenas o adicionou mais recentemente por meio de um processo filho openssl) e seria interrompido se recebesse um redirecionamento para um URL https que não pode seguir.

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

No passado, eu precisava usar HTTP em vez de HTTPS porque queria <embed>páginas de outros lugares que eram servidas por HTTP, e elas não funcionariam de outra forma.

Existem muito poucos bons motivos 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 absolutamente usar HTTPS se quiser que esses dados sejam seguros. A única razão decente que eu veria 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 suportem HTTPS, mas realmente, em 2017, deveriam.