Solución 1:
Esto es una cuestión de opinión, y también tiene que ver con cuestiones regulatorias (si se enfrenta a alguna).
Incluso si actualmente no es necesario, soy un gran defensor de mantener el HTTPS habilitado entre cualquier nivel de aplicación de cortafuegos/equilibradores de carga/servidores front-end y servidores back-end. Es una superficie de ataque menos. He contratado con lugares que necesitaban convertir a medida que comenzaba a pasar información más confidencial; es mejor comenzar allí.
Lo que generalmente sugeriría es usar una CA interna (si está disponible) o autofirmar (si no hay una CA interna) los servidores back-end. Estableceríamos la fecha de caducidad en un futuro lejano para evitar cambios innecesarios.
Solución 2:
TL;DR debes encriptar el tráfico a menos que esté en el mismo host.
No puedes confiar en tu red. Los programas maliciosos en su propia red pueden interceptar/modificar solicitudes http.
No son ataques teóricos, sino un ejemplo de la vida real:
-
Enrutadores (probablemente pirateados) dentro de la red de algunos sitios web que inyectan anuncios:https://www.blackhat.com/docs/us-16/materials/us-16-Nakably-TCP-Injection-Attacks-in-the-Wild- A-Large-Scale-Study-wp.pdf
-
Red india olfateando entre cloudfare y back-end:https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know -it-90935f7f6d98#.hymc3785e
-
El ahora famoso "SSL agregado y eliminado aquí :-)" de la NSA
Solución 3:
¿Los "muchos otros servidores" deben ejecutarse a través de HTTPS o, dado que no se puede acceder a ellos desde el exterior, pueden ejecutarse a través de HTTP de forma segura?
Esto realmente depende de lo que estés tratando de lograr. Comprenda que el propósito de usar HTTPS es proteger los datos en tránsito entre dos puntos. Si le preocupa que los datos sean rastreados dentro de su red, entonces tal vez deba ocuparse de eso primero. Si necesita proteger los datos en tránsito dentro de su red, lo que está diciendo es que le preocupa la seguridad de los datos que atraviesan sus sistemas dentro de su red o que existe alguna razón relacionada con el cumplimiento para que cifre los datos en tránsito.
Esto es realmente más una pregunta de opinión, pero la respuesta es depende. ¿Que estás tratando de hacer? ¿Qué tipo de datos estás encriptando? ¿De qué amenazas estás tratando de defenderte? ¿Tiene un requisito legal (por ejemplo, PCI-DSS, HIPAA, etc.) que dice que necesita cifrar los datos en tránsito? Si los datos son confidenciales y le preocupa que se puedan utilizar de forma indebida cuando se transmiten dentro de su red, le sugiero que se reúna con la administración para solucionar el problema. Entonces, al final, ¿qué estás tratando de proteger y por qué estás tratando de protegerlo?
Solución 4:
En el pasado, la gente asumía que las redes internas eran tan seguras como las casas. Una vez tuve una disputa con un supervisor que estaba horrorizado porque mis servidores internos estaban ejecutando sus firewalls incorporados. "Si no puedes confiar en tu red interna, ¿en quién puedes confiar?" Señalé que teníamos computadoras portátiles de estudiantes en nuestra red interna y que no había un firewall entre las computadoras portátiles de los estudiantes y mis servidores. Él, siendo nuevo en la academia, parecía tener su universo hecho jirones con esta información.
Las redes internas ya no se consideran tan seguras, incluso si no tiene computadoras portátiles para estudiantes en su red. Vea la respuesta de Tom para ver algunos ejemplos.
Dicho esto, sí, depende de la información que se transmita, cualquier problema de cumplimiento legal, etc. Puede decidir que no le importa si alguien detecta, por ejemplo, datos meteorológicos. Dicho esto, es posible que incluso si los datos enviados no son confidenciales ahora , alguien podría decidir agregar funciones a su aplicación más tarde que son sensible, por lo que recomendaría una mayor paranoia (incluido HTTPS).
Solución 5:
Hoy en día, con instrucciones de CPU especializadas para acelerar el cifrado y nuevos protocolos de transporte que no funcionarán en absoluto o que funcionarán con un rendimiento degradado en un enlace sin cifrar (HTTP/2, gRPC, etc.), quizás la mejor pregunta es:¿Hay algún ¿Por qué necesita degradar un enlace de red a HTTP? Si no hay un motivo específico, entonces la respuesta es quedarse con HTTPS.