Por que não usar HTTPS para tudo?

Se eu estava configurando um servidor e tinha o (s) certificado (s) SSL, por que não utilizaria o HTTPS para todo o site, e não apenas para compras / logins? Eu acho que faria mais sentido criptografar todo o site e proteger o usuário completamente. Impediria problemas como decidir o que deve ser protegido porque tudo seria, e não é realmente um inconveniente para o usuário.

Se eu já estava usando um HTTPS para parte do site, por que não gostaria de usá-lo para todo o site?

Esta é uma pergunta relacionada: Por que o https é usado apenas para login? , mas as respostas não são satisfatórias. As respostas pressupõem que você não conseguiu aplicar https a todo o site.

Eu posso pensar em algumas razões.

• Alguns navegadores podem não suportar SSL.
• O SSL pode diminuir um pouco o desempenho. Se os usuários estiverem baixando arquivos públicos grandes, pode haver uma sobrecarga no sistema para criptografá-los a cada vez.

Além dos outros motivos (principalmente relacionados ao desempenho), você pode hospedar apenas um único domínio por endereço IP * ao usar HTTPS.

Um único servidor pode suportar vários domínios em HTTP porque o servidor HTTP cabeçalho permite que o servidor saber qual domínio para responder com.

Com o HTTPS, o servidor deve oferecer seu certificado ao cliente durante o handshake TLS inicial (que é antes do início do HTTP). Isso significa que o cabeçalho do servidor ainda não foi enviado, portanto não há como o servidor saber com qual domínio está sendo solicitado e com qual certificado (www.foo.com ou www.bar.com) responderá.

* Nota de rodapé: Tecnicamente, você pode hospedar vários domínios se os hospedar em portas diferentes, mas isso geralmente não é uma opção. Você também pode hospedar vários domínios se o seu certificado SSL tiver um curinga. Por exemplo, você pode hospedar foo.example.com e bar.example.com com o certificado * .example.com

SSL / TLS não é usado com bastante frequência. O HTTPS deve ser usado para toda a sessão ; em nenhum momento um ID da sessão pode ser enviado por HTTP. Se você estiver usando apenas https para fazer login, estará violando claramente as 10 principais OWASP de 2010 "A3: autenticação quebrada e gerenciamento de sessões".

Por que não enviar todas as mensagens de correio tradicional em um envelope opaco à prova de violação pelo correio registrado? Alguém da agência postal sempre teria sua custódia pessoal, portanto você pode ter certeza de que ninguém está bisbilhotando suas correspondências. Obviamente, a resposta é que, enquanto alguns e-mails valem a despesa, a maioria deles não. Eu não me importo se alguém lê o meu "Que bom que você saiu da cadeia!" cartão postal para o tio Joe.

A criptografia não é gratuita e nem sempre ajuda.

Se uma sessão (como compras, bancos, etc.) for encerrada usando HTTPS, não há uma boa razão para não tornar a sessão inteira HTTPS o mais cedo possível.

Minha opinião é que o HTTPS deve ser usado somente quando inevitavelmente necessário, porque a solicitação ou a resposta precisa ser protegida contra a espionagem intermediária. Como exemplo, vá para o Yahoo! pagina inicial. Mesmo que você esteja logado, a maior parte da sua interação será por HTTP. Você se autentica em HTTPS e obtém cookies que comprovam sua identidade, portanto não precisa de HTTPS para ler notícias.

O maior motivo, além da carga do sistema, é que ele quebra a hospedagem virtual baseada em nome. Com o SSL, é um site - um endereço IP. Isso é muito caro, além de mais difícil de administrar.

Para links de alta latência, o handshake TLS inicial requer viagens de ida e volta adicionais para validar a cadeia de certificados (incluindo o envio de certificados intermediários), concordar com conjuntos de cifras e estabelecer uma sessão. Depois que uma sessão é estabelecida, os pedidos subsequentes podem utilizar o cache da sessão para reduzir o número de viagens de ida e volta, mas mesmo nesse melhor caso, ainda há mais viagens de ida e volta do que uma conexão HTTP normal exige. Mesmo que as operações de criptografia sejam gratuitas, as viagens de ida e volta não são e podem ser bastante perceptíveis em links de rede mais lentos, especialmente se o site não alavancar o pipelining http. Para usuários de banda larga em um segmento bem conectado da rede, isso não é um problema. Se você faz negócios com solicitações internacionais de https, pode facilmente causar atrasos visíveis.

Existem considerações adicionais, como a manutenção do estado da sessão no servidor, exigindo potencialmente mais memória e, é claro, operações de criptografia de dados. Qualquer site pequeno praticamente não precisa se preocupar com a capacidade do servidor ou com o custo do hardware atual. Qualquer site grande poderia facilmente comprar placas de descarga ou complemento de CPU / w AES para fornecer funcionalidade semelhante.

Todos esses problemas estão se tornando cada vez mais problemáticos, à medida que o tempo passa e os recursos de hardware e de rede melhoram. Na maioria dos casos, duvido que exista alguma diferença tangível hoje.

Pode haver considerações operacionais, como restrições administrativas no tráfego https (pense em filtros de conteúdo intermediários ... etc.), possivelmente alguns regulamentos corporativos ou governamentais. Algum ambiente corporativo exige descriptografia de dados no perímetro para evitar vazamento de informações ... interferência em pontos de acesso e sistemas de acesso semelhantes baseados na Web, incapazes de injetar mensagens em transações https. No final do dia, na minha opinião, os motivos para não acessar https por padrão provavelmente serão muito pequenos.

https requer mais recursos do que o http normal.

Exige mais dos servidores e dos clientes.

Se a sessão inteira estiver criptografada, você não poderá usar o cache para recursos estáticos, como imagens e js no nível de proxy, por exemplo, ISP.

Você deve usar HTTPS em qualquer lugar, mas perderá o seguinte:

1. Definitivamente, você não deve usar compactação SSL ou compactação HTTP sobre SSL, devido a ataques BREACH e CRIME. Portanto, não haverá compactação se sua resposta contiver identificadores de sessão ou csrf. Você pode atenuar isso colocando seus recursos estáticos (imagens, js, css) em um domínio sem cookies e usar a compactação. Você também pode usar a minificação de HTML.

2. Um certificado SSL, um endereço IP, a menos que seja usado o SNI, que não funciona em todos os navegadores (Android antigo, Blackberry 6, etc.).

3. Você não deve hospedar nenhum conteúdo externo em suas páginas que não seja SSL.

4. Você perde o cabeçalho de referência HTTP de saída quando o navegador acessa uma página HTTP, o que pode ou não ser um problema para você.

Bem, a razão óbvia é o desempenho: todos os dados precisarão ser criptografados pelo servidor antes da transmissão e depois descriptografados pelo cliente após o recebimento, o que é uma perda de tempo se não houver dados confidenciais. Também pode afetar a quantidade de cache do seu site.

Também é potencialmente confuso para os usuários finais se todos os endereços usarem https://e não o familiar http://. Além disso, veja esta resposta:

Por que não usar sempre https ao incluir um arquivo js?

https exige que o servidor criptografe e descriptografe solicitações e respostas do cliente. O impacto no desempenho aumentará se o servidor estiver atendendo muitos clientes. É por isso que a maioria das implementações atuais de https é limitada apenas à autenticação de senha. Porém, com o aumento do poder de computação, isso pode mudar, afinal o Gmail usa SSL para todo o site.

Além da resposta da WhirlWind, você deve considerar o custo e a aplicabilidade dos certificados SSL, os problemas de acesso (é possível, embora improvável, que um cliente possa não conseguir se comunicar via porta SSL), etc.

Usar SSL não é um cobertor garantido de segurança. Esse tipo de proteção precisa ser incorporado à arquitetura do aplicativo, em vez de tentar confiar em alguma bala mágica.

Foi-me dito que em um projeto da nossa empresa, eles descobriram que a largura de banda ocupada pelas mensagens SSL era significativamente maior do que as mensagens simples. Acredito que alguém me disse que eram 12 vezes mais dados surpreendentes. Eu mesmo não verifiquei isso e parece muito alto, mas se houver algum tipo de cabeçalho adicionado a cada página e a maioria das páginas tiver uma pequena quantidade de conteúdo, isso pode não estar tão distante.

Dito isto, o incômodo de ir e voltar entre http e https e acompanhar quais páginas são as que me parecem muito esforço. Apenas uma vez tentei construir um site que os misturasse e acabamos abandonando o plano quando fomos atropelados por coisas complexas, como janelas pop-up criadas por Javascript, conectando o protocolo errado a elas e esse tipo de coisa. Acabamos tornando o site inteiro https como menos problemas. Eu acho que em casos simples em que você apenas tem uma tela de login e uma tela de pagamento que precisam ser protegidas e são páginas simples, não seria um grande problema misturar e combinar.

Eu não me preocuparia muito com a carga que o cliente teria de descriptografar. Normalmente, o cliente gasta muito mais tempo aguardando a chegada dos dados do que o necessário para processá-los. Até que os usuários rotineiramente tenham conexões de Internet gigabit / s, o poder de processamento do cliente provavelmente é bastante irrelevante. A energia da CPU solicitada pelo servidor para criptografar páginas é um problema diferente. Pode haver problemas em não conseguir acompanhar centenas ou milhares de usuários.

Outro ponto pequeno (talvez alguém possa verificar): se um usuário digitar dados em um item de formulário, como uma caixa de texto e, por algum motivo, atualizar a página ou o servidor travar por um segundo, os dados digitados pelo usuário serão perdidos usando HTTPS, mas é preservado usando HTTP.

Nota: Não tenho certeza se isso é específico do navegador, mas certamente acontece com o meu navegador Firefox.

O Windows Server 2012 com IIS 8.0 agora oferece SNI, que é a indicação do nome do servidor, que permite que vários aplicativos da Web SSL no IIS sejam hospedados em um endereço IP.