Tous les serveurs doivent-ils utiliser le protocole HTTPS ou uniquement les serveurs publics?

38

J'ai un serveur Web frontal fonctionnant sur HTTPS - il s'agit d'une connexion publique - le port est ouvert.

J'ai également un serveur d'API backend sur lequel mon serveur Web fait des demandes d'API - ceci est public et nécessite une authentification - le port est ouvert.

Ces 2 serveurs fonctionnent sur HTTPS.

Derrière le serveur API, il y a beaucoup d'autres serveurs. Le serveur d'API inverse les mandataires vers ces serveurs. Les ports de ces autres serveurs ne sont pas ouverts au trafic entrant. Ils ne peuvent être consultés que via le serveur API.

Ma question ... Est-ce que les "nombreux autres serveurs" doivent fonctionner sur HTTPS ou, étant donné qu'ils ne peuvent pas accéder à l'extérieur, peuvent-ils s'exécuter en toute sécurité sur HTTP?

Je pensais que ce serait une question courante, mais je n’ai pas trouvé de réponse. Merci. S'il s'agit d'une dupe, veuillez m'indiquer la bonne réponse.

linux https danday74
la source
35
Compte tenu de la façon dont la NSA a exploité les liens outre-mer que Google et Yahoo utilisaient pour communiquer entre leurs centres de données sans chiffrement, je vous recommanderais de toujours supposer qu'une connexion est suspecte. Vous ne savez jamais où quelqu'un pourrait écouter, et il vaut mieux prévenir que guérir. La seule fois où je voudrais envisager d'utiliser HTTP seul est un service qui s'exécute sur le même ordinateur que celui qui l'utilise, ouvert uniquement aux connexions locales.
childofsoong
7
Ceci est connu sous le nom de déchargement ssl et de terminaison ssl si vous souhaitez effectuer des recherches supplémentaires.
Esben Skov Pedersen
31
C'est comme si on demandait "toutes les portes ont-elles besoin de serrures ou seulement de portes donnant sur l'extérieur"? Vous seul pouvez répondre à cette question lorsque vous envisagez des menaces à l’intérieur et à l’extérieur de votre réseau.
Ryan Griggs
5
Comme le dit la FAQ Security.SE : "La sécurité est un sujet très contextuel: les menaces jugées importantes dans votre environnement peuvent être sans conséquence chez quelqu'un d'autre, et inversement. Essayez-vous de protéger un élément de valeur globale contre les menaces persistantes avancées? Ou recherchez-vous une solution rentable pour une petite entreprise discrète? Pour obtenir les réponses les plus utiles, vous devez nous indiquer quels actifs vous souhaitez protéger, qui utilise ces actifs et qui vous pense peut-être vouloir en abuser (et pourquoi); ...
DW
2
Quelles mesures avez-vous déjà prises pour protéger cet actif? Quels risques pensez-vous devoir-vous encore atténuer? "Ce genre de contexte est essentiel. Je vous suggère d'éditer votre question pour y inclure ces informations.
DW

Réponses:

50

C’est une question d’opinion et il s’agit également de questions de réglementation (le cas échéant).

Même si ce n'est pas nécessaire actuellement, je suis un ardent défenseur du maintien de l'activation du protocole HTTPS entre tous les pare-feu / équilibreurs de charge / serveurs frontaux d'application et les serveurs principaux. C'est une surface d'attaque de moins. J'ai passé un contrat avec des lieux qui devaient être convertis au fur et à mesure que des informations plus sensibles commençaient à être transmises - il est préférable de commencer par là.

En règle générale, je suggère d'utiliser une autorité de certification interne (si disponible) ou d'auto-signer (si aucune autorité de certification interne) les serveurs principaux. Nous avions fixé la date d’expiration à long terme afin d’éviter des modifications inutiles.

Tim Brigham
la source
1
il vaut mieux commencer par là - les mots qui vous ont
valu des
12
C'est une bonne idée. Vous ne voulez pas que la NSA fasse des dessins maladroits de la topologie de votre réseau .
Kevin
3
Le cryptage de toutes vos communications vous protège également contre l’écoute interne, qu’il s’agisse de l’ordinateur du stagiaire qui récupère un cheval de Troie lorsqu’il navigue sur des images de chats, ou d’un petit renifleur branché sur un port réseau derrière un bureau inutilisé, ou d’un mot de passe wifi partagé. un peu trop lâchement.
Doktor J
8
" We'd set the expiration date nice and far into the future to avoid unnecessary changes." et veuillez ajouter une règle à votre suite de surveillance préférée pour vous prévenir de son expiration. S'il vous plaît!
GnP
2
@GnP Je le fais aussi - si c'est un certificat avec une période de 10 ans, notre politique exige toujours que le serveur principal soit remplacé dans ce délai. Cela le rend un peu redondant et il ne semblait pas nécessaire de le mentionner dans la réponse.
Tim Brigham
19

TL; DR, vous devez chiffrer le trafic sauf s’il se trouve sur le même hôte.

Vous ne pouvez pas faire confiance à votre réseau. Les malwares de votre propre réseau peuvent intercepter / modifier les requêtes http.

Ce ne sont pas des attaques théoriques, mais des exemples concrets:

À M
la source
16

Est-ce que les "nombreux autres serveurs" doivent fonctionner sur HTTPS ou, étant donné qu'ils ne peuvent pas être accédés en externe, peuvent-ils plutôt fonctionner sur HTTP en toute sécurité?

Cela dépend vraiment de ce que vous essayez d'accomplir. Comprendre que le but de l'utilisation de HTTPS est de protéger les données en transit entre deux points. Si vous êtes préoccupé par les données reniflées dans votre réseau, vous devriez peut-être s'en occuper en premier. Si vous devez protéger les données en transit à l'intérieur de votre réseau, vous dites que vous craignez pour la sécurité des données qui traversent vos systèmes à l'intérieur de votre réseau ou qu'il existe une raison liée à la conformité pour vous de chiffrer les données en transit.

C'est vraiment plus une question d'opinion, mais la réponse est que cela dépend. Qu'essayez-vous de faire? Quel type de données cryptez-vous? Quelles menaces essayez-vous de défendre? Avez-vous une obligation légale (par exemple, PCI-DSS, HIPAA, etc.) qui stipule que vous devez chiffrer les données en transit? Si les données sont sensibles et que vous craignez qu'elles ne soient utilisées de manière abusive lors de leur transmission au sein de votre réseau, je vous conseillerais de vous adresser à la direction pour résoudre le problème. En fin de compte, qu'essayez-vous de protéger et pourquoi essayez-vous de le protéger?

utilisateur5870571
la source
13

À l'époque, les gens pensaient que les réseaux internes étaient des maisons sûres. Une fois, j'ai eu un différend avec un superviseur qui était consterné par le fait que mes serveurs internes exécutaient leurs pare-feu intégrés. "Si vous ne pouvez pas faire confiance à votre réseau interne, à qui pouvez-vous faire confiance?" J'ai souligné que nous avions des ordinateurs portables étudiants sur notre réseau interne et qu'il n'y avait pas de pare-feu entre les ordinateurs portables étudiants et mes serveurs. Nouveau dans le monde universitaire, il semblait avoir son univers en lambeaux à cette information.

Les réseaux internes ne sont plus considérés comme sûrs, même si vous n'avez pas d'ordinateur portable étudiant sur votre réseau. Voir la réponse de Tom pour quelques exemples.

Cela dit, oui, cela dépend des informations transmises, des problèmes de conformité juridique, etc. Vous pouvez décider de ne pas vous soucier de savoir si quelqu'un renifle, par exemple, des données météorologiques. Cela dit, il est possible que même si la boîte d' envoi de données ne sont pas sensibles maintenant , quelqu'un pourrait décider d'ajouter des fonctionnalités à votre application ultérieure qui sont sensibles, donc je recommande une plus grande paranoïa (y compris HTTPS).

Katherine Villyard
la source
Les données météorologiques peuvent être suffisamment sensibles: une personne pourrait prendre des décisions erronées sur des données météorologiques altérées.
Hagen von Eitzen
1
Assez juste, cela dépend de la raison pour laquelle vous utilisez les données météorologiques. J'essayais de trouver quelque chose d'inoffensif. :)
Katherine Villyard
1
@HagenvonEitzen ou l'attaquant y injecterait des logiciels malveillants / des publicités. Grand-mère est donc avertie lorsqu'elle vérifie la météo à l'aide de sa machine Windows XP.
André Borie
8

Aujourd'hui, avec des instructions spécialisées du processeur pour accélérer le cryptage et de nouveaux protocoles de transport qui ne fonctionneront pas du tout ou dont les performances sont dégradées sur un lien non crypté (HTTP / 2, gRPC, etc.), la meilleure question est peut-être celle-ci: raison pour laquelle vous avez besoin de rétrograder un lien réseau vers HTTP? S'il n'y a pas de raison particulière, la solution est de rester avec HTTPS.

Aaron
la source
Processus de pensée
sympa
5

La seule raison pour laquelle je puisse penser à désactiver le cryptage est la performance. Toutefois, dans votre cas, les serveurs internes sont interfacés via HTTP, ce qui signifie qu'ils supportent déjà les coûts de performance d'un serveur Web, supportant le protocole HTTP et codant les données en HTTP / JSON /. Désactiver le cryptage libèrera peut-être 100 Ko de RAM et vous rapportera quelques microsecondes par Ko de données transmises, ce qui n'aura aucun impact visible sur les performances globales. D'autre part, vous devrez prêter beaucoup plus d'attention à la sécurité puisque vous utilisez maintenant HTTP dans votre intranet. En fait, il est possible qu'une configuration de pare-feu plus stricte ralentisse davantage les choses que la désactivation du cryptage, ce qui a entraîné une dégradation des performances perçues par les utilisateurs finaux.

Ce sera comme mettre un spoiler sur un tracteur: on n’obtient pratiquement rien, théoriquement, et beaucoup de désagréments dans la pratique.

Dmitry Grigoryev
la source