Solution 1 :
C'est une question d'opinion, et cela a aussi à voir avec des problèmes de réglementation (si vous en rencontrez).
Même si ce n'est pas nécessaire actuellement, je suis un grand défenseur du maintien du HTTPS activé entre tous les pare-feu / équilibreurs de charge / serveurs frontaux au niveau de l'application et les serveurs principaux. C'est une surface d'attaque en moins. J'ai passé des contrats avec des endroits qui devaient se convertir à mesure que des informations plus sensibles commençaient à être transmises - il vaut mieux commencer par là.
Ce que je suggérerais généralement, c'est d'utiliser une autorité de certification interne (si disponible) ou de s'auto-signer (si aucune autorité de certification interne) sur les serveurs principaux. Nous fixerions la date d'expiration bien loin dans le futur pour éviter des changements inutiles.
Solution 2 :
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 logiciels malveillants de votre propre réseau peuvent intercepter/modifier les requêtes http.
Il ne s'agit pas d'attaques théoriques, mais d'exemples concrets :
-
Routeurs (probablement piratés) à l'intérieur 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 reniflant 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
Solution 3 :
Les "nombreux autres serveurs" doivent-ils fonctionner via HTTPS ou, étant donné qu'ils ne sont pas accessibles de l'extérieur, peuvent-ils fonctionner via 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 craignez que les données ne soient reniflées à l'intérieur de votre réseau, vous devriez peut-être vous en occuper en premier. Si vous avez besoin de protéger les données en transit à l'intérieur de votre réseau, vous dites que vous êtes préoccupé par la sécurité des données traversant vos systèmes à l'intérieur de votre réseau ou qu'il existe une raison liée à la conformité pour 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 chiffrez-vous ? De quelles menaces essayez-vous de vous défendre ? Avez-vous une exigence légale (par exemple, PCI-DSS, HIPAA, etc.) qui vous oblige à chiffrer les données en transit ? Si les données sont sensibles et que vous craignez qu'elles ne soient utilisées à mauvais escient lorsqu'elles sont transmises à l'intérieur de votre réseau, je vous suggère de vous concerter avec la direction pour résoudre le problème. Donc, en fin de compte, qu'essayez-vous de protéger et pourquoi essayez-vous de le protéger ?
Solution 4 :
À l'époque, les gens supposaient que les réseaux internes étaient sûrs comme des maisons. Une fois, j'ai eu un différend avec un superviseur qui était consterné que mes serveurs internes exécutent 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 d'étudiants sur notre réseau interne et qu'il n'y avait pas de pare-feu entre les ordinateurs portables d'étudiants et mes serveurs. Lui, étant nouveau dans le milieu universitaire, 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'ordinateurs portables d'élèves 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é légale, etc. Vous pouvez décider que vous ne vous souciez pas si quelqu'un renifle, par exemple, des données météorologiques. Cela dit, il est possible que même si les données envoyées ne sont pas sensibles maintenant , quelqu'un pourrait décider d'ajouter ultérieurement à votre application des fonctionnalités qui sont sensible, donc je recommanderais une plus grande paranoïa (y compris HTTPS).
Solution 5 :
Aujourd'hui, avec des instructions CPU spécialisées pour accélérer le chiffrement et de nouveaux protocoles de transport qui ne fonctionneront pas du tout ou fonctionneront avec des performances dégradées sur un lien non chiffré (HTTP/2, gRPC, etc.), la meilleure question est peut-être :existe-t-il un raison pour laquelle vous avez besoin de rétrograder un lien réseau vers HTTP ? S'il n'y a pas de raison spécifique, la réponse est de rester avec HTTPS.