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

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.

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.

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:

• Des routeurs (probablement piratés) au sein du réseau de certains sites Web injectant des publicités: https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-TCP-Injection-Attacks-in-the-Wild- A-Large-Scale-Study-wp.pdf

• Réseau indien sniffing entre cloudfare et back-end: https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know -it-90935f7f6d98 # .hymc3785e

• Le désormais célèbre "SSL ajouté et supprimé ici :-)" de la NSA

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?

À 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).

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.

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.