Todos os sites deveriam usar SSL por padrão?

Question

Estamos no processo de mover nossa arquitetura web para um novo ambiente.Estão incluídos dezenas de sites diferentes, desde sites quase completamente estáticos até sites dinâmicos que exigem autenticação e contêm conteúdo confidencial.Nossos administradores de servidores web (sem qualquer contribuição da equipe de desenvolvimento) decidiram tornar um padrão no novo ambiente forçar SSL para tudo.Não concordo com esta decisão e gostaria de ter o máximo de conhecimento possível quando me sentar para discutir o assunto.Aqui está o que tenho até agora:

• Para cada site, um certificado SSL tem um custo direto.Temos um ambiente de desenvolvimento, controle de qualidade e produção e, portanto, são necessários três certificados para cada site
• Para a maioria das páginas, o conteúdo não é seguro e forçar o SSL faria com que as solicitações da página demorassem mais no servidor devido à criptografia e descriptografia
• Pelo que entendi, a maioria dos navegadores não armazena em cache páginas com SSL e, portanto, novamente, as solicitações de páginas levarão mais tempo
• Navegadores mais antigos têm problemas com downloads de arquivos quando são SSL

Não tenho problemas em forçar SSL quando os usuários estão se autenticando ou solicitando dados confidenciais.No entanto, acho que forçar o SSL por padrão em todos os sites é um pouco demais.

Answer 1

Ssl posso inibir o cache no nível da rede. Existem soluções alternativas para isso, mas isso pode significar que vários computadores na mesma rede precisam fazer o download de recursos da página. Isso pode aumentar a carga de rede nas duas extremidades. O cache no nível do navegador não é um problema nos navegadores modernos.

O SSL complica o uso dos chamados "domínios virtuais". Tradicionalmente, para formar uma conexão SSL, o navegador e o servidor precisam estar trabalhando com o mesmo nome de domínio. Isso tornou impossível hospedar mais de um certificado SSL em um único IP porque o servidor responderia com o certificado errado. As implementações de Indicação do nome do servidor (Uma extensão do protocolo TLS que o SSL usa) corrigiu muitos dos problemas com isso.

Em puro desempenho, a verificação simétrica de criptografia e integridade nos dados de túnel não é muito caro; Se o seu servidor não puder criptografar e descriptografar na velocidade da rede, você terá a própria fibra óptica de Deus ou deve pensar em substituir os i486. No entanto, o início de uma conexão SSL, conhecido como "aperto de mão", é um pouco mais caro e pode implicar um gargalo de desempenho em cargas pesadas (quando há centenas de conexões por segundo, ou mais). Felizmente, uma determinada instância do navegador reutilizará túneis e sessões SSL, portanto, isso não é um problema se você tiver apenas algumas dezenas de usuários.

No geral, colocar o SSL em todos os lugares parece uma maneira de ter um "sentimento confuso" da segurança. Isto não é bom. Isso geralmente significa que, ao se concentrar nos irrelevantes, os administradores terão maior probabilidade de desconsiderar questões reais de segurança. Eles também tornarão o sistema mais complexo de manter, dificultando o diagnóstico e os problemas corrigidos. Observe que, do ponto de vista dos administradores, isso torna seu trabalho mais seguro, pois aumenta o custo de dispará -los e substituí -los.

Answer 2

Em resposta a A resposta de Thomas:

Para cada site, um certificado SSL tem um custo direto. Temos um ambiente de dev, controle de qualidade e produto e, portanto, são três certificados necessários para cada site

Dificilmente verdadeiro. Você não precisa ter todos os desenvolvedores e QA atrás do SSL com certificados atuais válidos. Você - talvez - deseja um site de preparação com um certificado válido. Mas, além do front-end do Apache, seu back-end não deve saber que há SSL envolvido. Você não está testando nada único ou especial comprando certificados de dev.

Além disso, o custo é nominal. Você está gastando mais dinheiro na conversa do que os certificados realmente custam.

Para a maioria das páginas, o conteúdo não é seguro e forçar o SSL faria as solicitações de página levarem mais tempo no servidor devido a criptografar e descriptografar

Um pouco. Você mediu? Você pode achar que é difícil medir porque a variabilidade das velocidades da Internet supera o custo do processamento SSL.

Pelo que entendi, a maioria dos navegadores para não fazer páginas de cache que são SSL'ed e, assim, novamente, as solicitações de página levarão mais tempo

Novamente, você mediu isso?

Os navegadores mais antigos têm problemas com downloads de arquivos quando são SSL'ed

Sério? Qual "navegador mais antigo" você está planejando apoiar esse problema? Se você não consegue encontrar um e está pensando que alguém, em algum lugar pode ter esse problema, você pode estar excessivamente engenharia. Verifique seus logs e veja o que navega seus clientes na realidade Use e, em seguida, determine se você tem um problema.

Eu concordo que "SSL em todos os lugares" não é uma abordagem muito boa. Eu acho que você precisa de pelo menos uma página não-SSL da porta-80 "Welcome". Mas não tenho certeza se o seu conjunto atual de problemas são razões sólidas. Eu acho que você precisa de mais medidas consideravelmente para argumentar que o SSL realmente envolve o custo real ou os acertos reais de desempenho.

Answer 3

A partir de 2012, os sites devem usar SSL apenas se tiverem informações de identificação pessoal (PII) ou informações comercialmente importantes, ou se tiverem algum conceito de login.

Sites que publicam apenas informações públicas somente leitura de baixo valor e baixa confiança são um pouco discutíveis, mas provavelmente ainda poderiam servir tudo de forma útil por HTTPS.Os invasores podem tentar inserir malware ou adware, ou redirecionamentos, no conteúdo HTTP.

Uma política corporativa de "tudo sobre SSL, sem isenção específica" é razoável.

Você também deve considerar a implantação Segurança de transporte estrita HTTP para garantir que até mesmo a primeira solicitação do usuário ao digitar example.com é enviado por HTTPS.

Os ataques man-in-the-middle são um problema do mundo real, especialmente em redes Wi-Fi, mas também no ISP e no nível do país.Se você fizer apenas a fase de login por SSL e depois passar um cookie de sessão não criptografado, esse cookie de sessão será roubado.Ver Ovelha de fogo para uma demonstração clara.

O SSL pode ser armazenado em cache com segurança por usuário, seja para a sessão ou indefinidamente.Os caches proxy do cliente agora são raros e a otimização para esse caso não é importante.Quando eles existem, geralmente erram e vale a pena contorná-los por meio de SSL.

SSL ou SPDY implementado corretamente pode ser rápido:a sobrecarga do servidor não é alta e pode ser facilmente movida para uma máquina proxy reversa separada.Existem CDNs SSL.

Não há necessidade de comprar certificados reais para sites destinados apenas a desenvolvedores e testadores.O custo dos certificados, na casa das dezenas de dólares, é insignificante mesmo para sites não comerciais.

A criptografia de dados na rede é uma camada útil de defesa profunda.Obviamente não é suficiente por si só para tornar o serviço seguro, mas elimina alguns tipos de problemas e tem baixo custo.

Mesmo para dados somente leitura, há valor em os clientes saberem que estão obtendo o site autêntico:por exemplo, se eles estiverem baixando binários, você não deseja que trojans sejam inseridos.

Distinguir com segurança as páginas que precisam ser sobre SSL daquelas que não exigem esforço do desenvolvedor que quase certamente poderia ser melhor utilizado.

Tornar os padrões uma camisa de força para diversos sistemas, especialmente sem consulta, nunca é bom.Mas dizer que todos os sites devem estar em SSL, a menos que haja um motivo específico para fazer o contrário em um caso, faz sentido para mim.Bons exemplos de exceções caso a caso, onde você ainda deve oferecer SSL, mas não forçar um redirecionamento:

• o site está servindo grandes downloads binários (distribuições de música/vídeo/software), portanto, é importante permitir mais armazenamento em cache e downloads mais rápidos (mostrar dados)
• os clientes são IE arcaicos ou clientes incorporados que simplesmente não conseguem fazer SSL adequadamente (novamente, mostre que é realmente um problema)
• há muitos recursos no site e você deseja que os robôs os indexem por HTTPS

Se você usar SSL em todos os lugares, usará mais alguns recursos da máquina, de maneiras que podem ser otimizadas caso se tornem importantes.Se você não usar SSL, gastará mais recursos de desenvolvedor para considerar a segurança caso a caso ou provavelmente estará mais sujeito a roubo de conta.

Adam Langley, do Google, escreveu em 2010:

Se há um ponto que queremos comunicar ao mundo, é que SSL/TLS não é mais caro do ponto de vista computacional.Há dez anos isso poderia ter sido verdade, mas não é mais o caso.Você também pode habilitar HTTPS para seus usuários.

Em janeiro deste ano (2010), o Gmail passou a usar HTTPS para tudo por padrão.Anteriormente, ele havia sido introduzido como uma opção, mas agora todos os nossos usuários usam HTTPS para proteger seus e-mails entre seus navegadores e o Google, o tempo todo.Para fazer isso não tivemos que implantar máquinas adicionais nem hardware especial.Em nossas máquinas front-end de produção, o SSL/TLS representa menos de 1% da carga da CPU, menos de 10 KB de memória por conexão e menos de 2% da sobrecarga da rede.Muitas pessoas acreditam que SSL consome muito tempo de CPU e esperamos que os números acima (públicos pela primeira vez) ajudem a dissipar isso.

Answer 4

Então eu vi alguns fantástico Respostas a esta pergunta, mas depois de alguns dias, vi que existem Algumas coisas faltando. Portanto, há algumas coisas que quero mencionar:

Por que usar o SSL em tudo

• Segurança - Se apenas algumas páginas forem criptografadas SSL, é mais fácil "cheirar" quais páginas contêm dados confidenciais. Agora, o SSL é bastante seguro, então isso não é algo para se preocupar, mas no caso de sua chave privada se comprometer, é uma boa prática ter essa camada adicional de segurança, para que seja mais difícil para os bandidos chegarem no Coisas suculentas.
• Confiabilidade - Há pessoas que argumentam que, quando você visita um site com um certificado verificado, é mais fácil confiar. Como um certificado verificado custa dinheiro, é mais fácil confiar em um site, sabendo que o proprietário investiu em um símbolo de confiança.
• Problema - Cobrar tudo no SSL é muito mais fácil. Tudo que você precisa fazer é cortar o http: No início de todos os links de recursos e você é bom.
• Configuração do SEO - Você não terá que se preocupar com a configuração do SEO. Ouvi dizer que o índice dos mecanismos de pesquisa http:// e https:// Como entradas separadas, portanto, para consistência (tanto no comportamento do SEO quanto na página), cobre o SSL sobre tudo e a configuração de um redirecionamento 301 parece uma solução fácil e agradável.
• Consistência - você terá um site muito mais consistente se você apenas https:// tudo. Muitas estruturas quebram quando você tenta fazer um híbrido de SSL e não-SSL. Além disso, plugins e código dependentes de URL serão realmente maus se você tentar saltar para frente e para trás entre http e https.
• Aquele sentimento seguro e confuso - Você tem que admitir, aquele pequeno bar verde no canto superior esquerdo que diz "domínio verificado" é uma sensação muito boa.

Por que não SSL tudo

• Velocidade - SSL é mais lento. Não muito, é claro, e na maioria das vezes o custo é insignificante. É um fato inevitável, no entanto, que o SSL sempre será mais lento.
• Compatibilidade do navegador - Isso provavelmente é insignificante, mas se você quiser apoiar verdade Navegadores antigos que não armazenam em cache sobre o SSL, você terá que ficar com a porta 80.
• Plugins - Um monte de plugins não funciona corretamente sobre o SSL, então você terá que ter cuidado com isso. Se você deseja adicionar um novo plug -in, precisará reconfigurar suas configurações SSL ou procurar outro plug -in.
• Profissionalismo - Agora, embora algumas pessoas argumentem que ver um domínio SSL verificado parece confiável, outras o veem como uma solução muito amadora e preguiçosa. Na verdade, é realmente fácil e barato (me custou cerca de US $ 10) para obter um certificado SSL verificado que atinge até 96% dos navegadores!
• Problema - Então eu disse que é mais fácil SSL tudo, mas ao mesmo tempo você terá que garantir que todos os recursos sejam carregados https:// (ou faça o http:// -> // solução rápida). Pode ser um pouco tedioso se você tiver um monte de links ou até incompatível se tiver conteúdo submitido pelo usuário hospedado em um site que não suporta SSL. Nesses casos, seu navegador reclamará de você. Se você já viu esse aviso que diz "Esta página tem conteúdo inseguro", saberá o quão irritante isso é e o quão ruim isso parece.

Então, em suma, é realmente situacional, mas eu tendem a evitar cobertores de SSL. Claro, é preciso um pouco mais de configuração, mas no final você obtém um sistema muito mais flexível. Pessoalmente, acho que toda a coisa do "profissionalismo" é besteira (Twitter e Google SSL tudo). No entanto, se você tiver conteúdo hospedado externamente ou conteúdo postado pelo usuário, geralmente é uma ideia muito ruim para SSL tudo. Você também pode começar a tudo e encontrar vários problemas.

Mas sou só eu. : D

Answer 5

Esta primeira coisa a se perguntar: o que SSL compra você? Ele compra a garantia de que ninguém e nenhum aplicativo pode "cheirar" o tráfego e ver o que está acontecendo entre o servidor da Web e o navegador. O custo é o custo real da compra de um certificado SSL e o custo de entrada de um ligeiro aumento na velocidade de download. Você menciona que o navegador mais antigo tem problemas para baixar arquivos sobre a comunicação SSL. Não posso falar com isso, e não me preocuparia muito com isso. Do ponto de vista da segurança, você tem outra preocupação. Os firewalls modernos monitoram o tráfego em busca de várias tentativas de hacker. O SSL impede que o firewall monitore essa comunicação; portanto, o desenvolvedor de aplicativos / Admin precisa se preocupar ainda mais em proteger seus aplicativos e sites de várias tentativas de hackers. Para encurtar a história, é preciso apenas criptografar comunicações que realmente precisam.

Answer 6

Em outra resposta à resposta de Thomas, especialmente porque está no topo.

Além disso, mais abaixo eu vinculei um white paper com práticas recomendadas para SSL.

SSL impede o cache, não apenas de navegadores, mas também de servidores proxy.Todo elemento da página da web deverá ser enviado pelo seu servidor principal, repetidamente.Isso aumenta a carga de rede.

Apenas parcialmente verdade.SSL impedirá o cache do proxy, mas não cache do navegador - veja também as respostas para essa questão.Não é um grande problema na minha opinião.

SSL impede o uso dos chamados “domínios virtuais”.[...]

Isto é parcialmente verdade.No entanto, os domínios virtuais funcionarão bem desde que você tenha apenas um certificado.Mesmo se você não, Indicação de nome de servidor (SNI) deveria ser uma alternativa viável (ou deveria ser, quando o Windows XP estiver fora da face do planeta).

[desempenho] ​​Entretanto, o início de uma conexão SSL, conhecida como "handshake", é um pouco mais caro, > e pode implicar em um gargalo de desempenho em cargas pesadas (quando há centenas de conexões por segundo, ou mais).Felizmente, uma determinada instância do navegador reutilizará túneis e sessões SSL, portanto, isso não é um problema se você tiver apenas algumas dezenas de usuários.

Mesmo o handshake não deve causar problemas de desempenho no lado do servidor se você tiver hardware moderno.O principal motivo do handshake ser "lento" é o fato de que os pacotes de rede precisam ser enviados e recebidos algumas vezes entre o servidor e o navegador - o poder computacional tem pouco a ver com isso.

Dito de outra forma:Configurar a conexão SSL será muito mais barato do que renderizar uma página PHP que busca dados de um banco de dados.

No geral, colocar SSL em todos os lugares parece uma maneira de obter uma "sensação calorosa" de segurança.>Isso não é bom.Isso geralmente significa que, concentrando-se no irrelevante,

NÃO É VERDADE.Ou você não precisa de SSL em seu site, porque é um conteúdo totalmente público.Ou você precisa de SSL por algum motivo (logins de usuários, áreas protegidas).Nesse caso, a melhor prática é colocá-lo em todos os lugares.

Ter SSL apenas em partes da sua página pode expor você a todos os tipos de riscos obscuros.E embora você possa encontrar e mitigar isso de outras maneiras, será mais complexo, sujeito a erros e demorado do que apenas ter SSL habilitado em todas as páginas.

Eu encontrei o este white paper sobre SSL.Não sou afiliado à empresa que o criou, mas achei um resumo muito conciso de todas as coisas que você precisa ter em mente ao implantar uma configuração SSL.

Nem é preciso dizer que a segurança tem mais de um componente.Mas já errar no primeiro não é um bom começo.

Answer 7

Eu não acho que você deva SSL em todos os seus sites e, definitivamente, não precisa comprar certificados para seus ambientes de desenvolvimento. Se você deseja/precisar de um certificado SSL para o Dev, ele pode ser facilmente gerado e que, na maioria dos casos, seria suficiente para esse ambiente. A outra possibilidade é que você possa comprar um certificado curinga e definir servidores de desenvolvimento em um dos subdomínios, dessa maneira você pode ter o mesmo certificado para ambos os ambientes, mas novamente: é um desperdício de dinheiro se você comprar um certificado curinga (que são mais caro) apenas para que o Dev trabalhe nele também. Faz sentido se você tiver vários subdomínios no PROD que precisam ser SSLED.

Quanto à velocidade: sim, é um pouco importante, mas não tão significativo. As respostas SSL não são armazenadas em cache, portanto, usá -las aumentará um pouco os servidores, mas acho que essa é a parte que o administrador deve estar ciente.