Existe alguma razão para não impor HTTPS em um site?

Question

Um site que frequentei decidiu finalmente habilitar o TLS para seus servidores, apenas para não obrigá-lo como muitos sites por aí. O mantenedor afirma que o TLS deve ser opcional. Por quê?

No meu próprio site, configurei TLS e HSTS obrigatórios por longos períodos, e os conjuntos de criptografia mais fracos estão desabilitados. É garantido que o acesso a texto sem formatação será feito com um HTTP 301 para a versão protegida por TLS. Isso afeta negativamente o meu site?

    

Answer 1

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

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

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

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

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

  • O Google tem ajudando os webmasters a configurar os servidores deles com mais segurança, mas também usou 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 Mythbossing HTTPS da equipe do Google Chrome Developers declara claramente sua atitude.

• O Blog de Segurança da Mozilla também anunciou o Deprecating Non- Proteja o HTTP tornando todos os novos recursos disponíveis apenas para proteger sites e eliminando gradualmente o acesso a recursos do navegador para sites não seguros, especialmente recursos que representam riscos à segurança e à segurança dos usuários privacidade .

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

Se você já tem 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 tenho visto em anos tem sido dispositivos Android e Autoridade de certificação intermediária ausente como o Android confia somente 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 301 Moved Permanently direto, 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 HTTPS configurado . Além disso, você não deve implantar Segurança de Transporte Estrito HTTP (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 Electronic Frontier Foundation e endereçado por um multibrowser HTTPS Everywhere extension:

Many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may default to unencrypted HTTP, or fill encrypted pages with links that go back to the unencrypted site.

O conteúdo misto também foi um grande problema devido a possíveis ataques XSS a sites HTTPS por meio da modificação de JavaScript ou CSS carregados por meio de uma 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á-los automaticamente. Esse dificulta a manutenção de um site sem os redirecionamentos 301 no HTTP: você deve garantir que cada página HTTP carregue apenas o contêiner HTTP (CSS, JS, imagens etc.) e cada página HTTPS carregue apenas Conteúdo HTTPS. Isso é extremamente difícil de conseguir com o mesmo conteúdo em ambos.

    

Answer 2

Neste dia e idade, TLS + HSTS são marcadores de que seu site é gerenciado por profissionais que podem ser confiáveis para saber o que estão fazendo. Esse é um padrão mínimo emergente para confiabilidade, conforme evidenciado pelo Google, afirmando que eles fornecerão uma classificação positiva para sites que fazem isso.

No outro extremo está a compatibilidade máxima. Ainda existem clientes mais antigos, 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: Otimize a classificação do mecanismo de pesquisa
HTTP simples: Otimize a compatibilidade

Depende do que é mais importante para você.

    

Answer 3

Há uma boa razão para que sites simples somente de leitura não usem HTTPS.

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

Answer 4

The maintainer claims that TLS must be optional. Why?

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

Em ambientes corporativos, é comum que o departamento de TI instale um firewall que inspecione 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 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 executar a descriptografia e inspeção do MitM.
3. Por atacado bloqueie o tráfego criptografado.

Para um administrador de sistemas 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, o bloqueio de muitos sites eleva inteiramente a ira dos usuários, e a instalação de uma autoridade de certificação raiz pode parecer um pouco suspeita, já que introduz considerações de privacidade e segurança para os usuários. Lembro-me de ver (desculpem, não consigo achar o tópico) um reddit de petição de sysadmin quando eles estavam ligando HSTS porque ele estava exatamente nessa situação, e não queria bloquear todo o reddit simplesmente porque ele estava compelido pelo negócio para bloquear os subreddits focados em pornografia.

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

    

Answer 5

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

Não permitindo que eu faça downgrade explicitamente para HTTP inseguro quando julguei que seu post sobre porque você gosta mais do Python do que do Ruby (não dizendo nada, apenas um exemplo genérico) não é algo que eu me importo com os spooks ou o público sabendo que eu acessei está apenas ficando no meu caminho sem uma boa razão, supondo que o HTTPS seja 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 que é muito ruim que isso seja verdade, mas como um usuário avançado de [insira o dispositivo embutido aqui], às vezes não consigo alterar isso).

Aqui está uma experiência divertida: tente baixar uma versão recente do LibreSSL a partir do site do OpenBSD upstream através de 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 mais antiga do OpenSSL de 2012 ou mais, porque eu queria atualizar esse sistema embarcado para coisas novas e mais seguras a partir do código-fonte - eu 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 seja porque meu OpenSSL mais antigo não suportava as coisas certas.

Este é um exemplo em que a migração do único HTTPS pode prejudicar as pessoas: se você não tiver o luxo de pacotes pré-compilados recentes e quiser corrigir o problema criando a partir da origem, estará bloqueado . Felizmente, no caso LibreSSL, você pode voltar a solicitar explicitamente HTTP. Claro, isso não salvará você de um invasor que já está reescrevendo seu tráfego, capaz de substituir pacotes de código-fonte 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, mas ainda é útil caso mais comum.

A maioria de nós não é um download desprotegido para não pertencer a um APT (Advanced Persistent Thread: jargão de segurança para agências de inteligência nacionais e outras ameaças cibernéticas com recursos excelentes). Às vezes, eu só quero wget alguma documentação de texto simples ou um pequeno programa cuja origem eu possa auditar rapidamente (meus pequenos utilitários / scripts no GitHub, por exemplo) em uma caixa que não suporta os pacotes de criptografia mais recentes. / p>

Pessoalmente, eu perguntaria: 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 fazendo downgrade acidental de HTTP para o seu conteúdo? Pondere os seus requisitos de segurança, os requisitos de privacidade aplicada aos seus usuários e o risco de downgrades implícitos contra a capacidade de os usuários que entendem os riscos fazerem uma escolha informada caso a caso se tornarem inseguros. É totalmente legítimo dizer que, para o seu site, não há uma boa razão para não impor HTTPS - mas acho que é justo dizer que ainda existem bons casos de uso para o HTTP simples por aí.

    

Answer 6

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

Maxthon fez duas 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 atendendo 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, caching distribuído e algumas dicas sobre acessibilidade geopolítica, há também uma consideração sobre integração de conteúdo e evitar mensagens de navegador feias sobre o conteúdo estar inseguro. Como Alvaro apontou, o TLS é apenas a ponta do iceberg no que diz respeito à segurança.

A segunda questão, no entanto, é responsável. Expor qualquer parte do site 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 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 de você estar fazendo seu trabalho como administrador.

Sysadmin1138 diz que o https impacta as classificações de SEO. Embora o Google tenha declarado que isso afeta os rankings, os únicos estudos confiáveis que eu vi sugerem que a diferença é pequena. Isso não é ajudado por pessoas que devem saber melhor , alegando que, como os sites mais bem classificados são mais propensos a ter uma presença https, um A presença de https portanto melhora os rankings.

    

Answer 7

No passado, eu tive que usar HTTP em vez de HTTPS porque queria <embed> páginas de outro lugar que foram servidas por HTTP, e elas não funcionarão de outra forma.

    

Answer 8

Este não é um motivo bom , pois significa que você tem clientes ruins / quebrados / inseguros, mas se houver processos automatizados acessando recursos por meio dos http:// URLs existentes, é possível que alguns deles eles nem sequer suportam https (por exemplo, busybox wget, que não tem suporte a TLS internamente e só o adicionou mais recentemente por meio de um processo filho openssl) e quebrariam se recebessem um redirecionamento para um https url que eles não podem seguir.

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

    

Answer 9

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 os dados sejam seguros. A única razão decente que eu veria para não impingir o HTTPS é se o seu site confia no cache, já que o HTTPS não funciona com o cache. No entanto, muitas vezes vale a pena sacrificar um pouco o desempenho para garantir a segurança do seu site. Também é possível que seus clientes não ofereçam suporte a HTTPS, mas, na verdade, em 2017, eles deveriam.