Todos os servidores precisam usar o protocolo HTTPS ou apenas servidores públicos?

38

Eu tenho um servidor Web front-end executando sobre HTTPS - isso é voltado para o público - ou seja, a porta está aberta.

Também tenho um servidor de API back-end no qual meu servidor da Web faz solicitações de API - isso é voltado para o público e requer autenticação - a porta está aberta.

Esses 2 servidores rodam sobre HTTPS.

Por trás do servidor da API, existem muitos outros servidores. O servidor da API reverte proxies para esses servidores. As portas para esses outros servidores não estão abertas ao tráfego de entrada. Eles só podem ser consultados através do servidor da API.

Minha pergunta ... Os "muitos outros servidores" precisam executar sobre HTTPS ou, como não podem ser acessados ​​externamente, eles podem executar sobre HTTP com segurança?

Eu pensei que isso seria uma pergunta comum, mas não consegui encontrar uma resposta para ela. Obrigado. Se isso é uma bobagem, por favor, aponte-me para a resposta certa.

linux https danday74
fonte
35
À luz de como a NSA utilizou os links externos que o Google e o Yahoo usavam para se comunicar entre seus datacenters não criptografados, recomendo que você sempre assuma que uma conexão é suspeita. Você nunca sabe onde alguém pode estar ouvindo, e é melhor prevenir do que remediar. A única vez em que eu consideraria usar o HTTP sozinho é um serviço em execução na mesma máquina que o utiliza, aberto apenas para conexões locais.
childofsoong 29/08/16
7
Isso é conhecido como descarregamento de ssl e terminação de ssl, se você desejar fazer pesquisas adicionais.
Esben Skov Pedersen
31
É como perguntar "todas as portas precisam de fechaduras ou apenas portas externas"? Somente você pode responder a essa pergunta ao considerar ameaças dentro e fora da sua rede.
Ryan Griggs
5
Como o FAQ da Security.SE diz : "A segurança é um tópico muito contextual: as ameaças consideradas importantes em seu ambiente podem ser irrelevantes para as de outras pessoas e vice-versa. Você está tentando proteger algo de valor global contra ameaças persistentes avançadas? Ou você está procurando uma abordagem econômica para uma pequena empresa de perfil baixo? Para obter as respostas mais úteis, você deve nos dizer: quais ativos você está tentando proteger; quem usa o ativo que você está tentando proteger e quem você acho que pode querer abusar dela (e porquê); ...
DW
2
quais etapas você já tomou para proteger esse ativo; quais riscos você acha que ainda precisa mitigar. "Esse tipo de contexto é essencial. Sugiro que você edite sua pergunta para incluir essas informações."
DW

Respostas:

50

Isso é uma questão de opinião e também tem a ver com questões regulatórias (se você enfrentar alguma).

Mesmo que atualmente não seja necessário, sou um grande defensor de manter o HTTPS ativado entre os firewalls / balanceadores de carga / servidores de front-end no nível do aplicativo e os servidores de back-end. É uma superfície a menos de ataque. Contratei lugares que precisavam ser convertidos à medida que informações mais sensíveis começaram a ser transmitidas - é melhor começar por aí.

O que eu geralmente sugeriria é o uso de uma autoridade de certificação interna (se disponível) ou de autoassinatura (se não houver autoridade de certificação interna) nos servidores back-end. Definimos a data de validade agradável e distante no futuro para evitar alterações desnecessárias.

Tim Brigham
fonte
1
é melhor começar por aí - as palavras que lhe deram os pontos :)
danday74
12
Essa é uma boa ideia. Você não quer que a NSA faça desenhos engraçados de sua topologia de rede .
Kevin
3
A criptografia de todas as suas comunicações também protege contra a interceptação interna - seja na forma do computador do estagiário que pegou um trojan enquanto navega nas fotos de gatos ou de um pequeno sniffer conectado a uma porta de rede atrás de uma mesa não utilizada ou de uma senha wifi compartilhada um pouco vagamente.
Doktor J
8
" We'd set the expiration date nice and far into the future to avoid unnecessary changes." e adicione uma regra ao seu pacote de monitoramento preferido para avisá-lo quando ele estiver prestes a expirar. Por favor!
GnP 30/08/16
2
@GnP Eu também faço isso - se for um certificado com um período de 10 anos, nossa política sempre exige que o servidor back-end seja substituído dentro desse período. Torna-o um pouco redundante e não parece necessário mencionar na resposta.
Tim Brigham
19

TL; DR, você deve criptografar o tráfego, a menos que esteja no mesmo host.

Você não pode confiar na sua rede. Malwares em sua própria rede podem interceptar / modificar solicitações http.

Não são ataques teóricos, mas exemplo da vida real:

Tom
fonte
16

Os "muitos outros servidores" precisam executar o HTTPS ou, como não podem ser acessados ​​externamente, eles podem executar o HTTP com segurança?

Isso realmente depende do que você está tentando realizar. Entender o objetivo do uso do HTTPS é proteger os dados em trânsito entre dois pontos. Se você está preocupado com a detecção de dados dentro da sua rede, talvez seja melhor cuidar primeiro deles. Se você precisar proteger os dados em trânsito dentro da sua rede, o que você está dizendo é que você tem uma preocupação com a segurança dos dados que atravessam seus sistemas na rede ou há algum motivo relacionado à conformidade para criptografar os dados em trânsito.

Esta é realmente mais uma pergunta de opinião, mas a resposta é que depende. O que você está tentando fazer? Que tipo de dados você está criptografando? De que ameaças você está tentando se defender? Você tem um requisito legal (por exemplo, PCI-DSS, HIPAA etc.) que diz que você precisa criptografar os dados em trânsito? Se os dados forem confidenciais e você estiver preocupado, ele poderá ser mal utilizado quando estiver sendo transmitido dentro da sua rede, então eu sugiro que você se junte à gerência para corrigir o problema. Então, no final, o que você está tentando proteger e por que está tentando protegê-lo?

user5870571
fonte
13

Naquela época, as pessoas supunham que as redes internas eram seguras como casas. Certa vez, entrei em uma disputa com um supervisor que estava horrorizado que meus servidores internos estavam executando seus firewalls internos. "Se você não pode confiar na sua rede interna, em quem pode confiar?" Eu indiquei que tínhamos laptops estudantis em nossa rede interna e que não havia firewall entre os laptops estudantis e meus servidores. Ele, sendo novo na academia, parecia ter seu universo em frangalhos diante dessa informação.

As redes internas não são mais consideradas tão seguras, mesmo se você não tiver laptops de estudantes em sua rede. Veja a resposta de Tom para alguns exemplos.

Dito isto, sim, depende de quais informações estão sendo transmitidas, de quaisquer questões de conformidade legal, etc. Você pode decidir que não se importa se alguém cheira, por exemplo, dados meteorológicos. Dito isso, é possível que, mesmo que os dados enviados não sejam confidenciais agora , alguém possa decidir adicionar recursos ao seu aplicativo posteriormente que sejam confidenciais, por isso recomendo maior paranóia (incluindo HTTPS).

Katherine Villyard
fonte
Os dados de clima severo podem ser suficientemente sensíveis: alguém pode basear suas decisões erradas em dados violados de clima temperado.
Hagen von Eitzen
1
Justo, depende do que você está usando os dados meteorológicos. Eu estava tentando pensar em algo inócuo. :)
Katherine Villyard 01/09/16
1
O @HagenvonEitzen ou o invasor injetaria malware / anúncios lá, para que a avó seja atacada quando ela verifica o clima usando sua máquina Windows XP.
André Borie 02/09
8

Hoje, com instruções especializadas da CPU para acelerar a criptografia e novos protocolos de transporte que não operam nem operam com desempenho degradado em um link não criptografado (HTTP / 2, gRPC, etc ...), talvez a melhor pergunta seja: existe alguma motivo pelo qual você precisa fazer o downgrade de um link de rede para HTTP? Se não houver um motivo específico, a resposta é permanecer com HTTPS.

Aaron
fonte
Processo de pensamento agradável
danday74
5

O único motivo para desativar a criptografia em que consigo pensar é no desempenho. No entanto, no seu caso, os servidores internos têm interface via HTTP, o que significa que eles já suportam o custo de desempenho da execução de um servidor da Web, suportando o protocolo HTTP e codificando dados em HTTP / JSON / qualquer que seja. A desativação da criptografia liberará talvez 100 KB de RAM e você ganhará alguns microssegundos por KB de dados transmitidos, o que não terá impacto visível no desempenho geral. Por outro lado, você precisará prestar muito mais atenção à segurança, já que agora executa o HTTP na sua intranet. De fato, é possível que uma configuração mais rigorosa do firewall atrase as coisas mais do que a desativação da criptografia as tenha acelerado, resultando em pior desempenho percebido pelos usuários finais.

Será como colocar um spoiler em um trator: você ganha quase nada teoricamente e muitos inconvenientes na prática.

Dmitry Grigoryev
fonte