¿Todos los servidores necesitan usar el protocolo HTTPS o solo servidores públicos?

38

Tengo un servidor web front-end que se ejecuta sobre HTTPS, esto es público, es decir, el puerto está abierto.

También tengo un servidor API de back-end al que mi servidor web realiza solicitudes de API (esto es público y requiere autenticación) el puerto está abierto.

Estos 2 servidores se ejecutan sobre HTTPS.

Detrás del servidor API, hay muchos otros servidores. El servidor API invierte proxies para estos servidores. Los puertos para estos otros servidores no están abiertos al tráfico entrante. Solo se puede hablar a través del servidor API.

Mi pregunta ... ¿Es necesario que los "muchos otros servidores" se ejecuten a través de HTTPS o, dado que no se puede acceder a ellos externamente, ¿se pueden ejecutar a través de HTTP de forma segura?

Pensé que esta sería una pregunta común, pero no pude encontrar una respuesta. Gracias. Si esto es un engaño, indíqueme la respuesta correcta.

linux https

— danday74
fuente

35

En vista de cómo la NSA aprovechó los enlaces en el extranjero que Google y Yahoo usaban para comunicarse entre sus centros de datos sin encriptar, le recomiendo que siempre asuma que una conexión es sospechosa. Nunca se sabe dónde podría estar escuchando alguien, y es mejor prevenir que curar. La única vez que lo haría consideraría usar HTTP solo es un servicio que se ejecuta en la misma máquina que lo usa, abierto solo a conexiones locales.

— childofsoong

77

Esto se conoce como descarga de SSL y terminación de SSL si desea realizar más investigaciones.

— Esben Skov Pedersen

31

Es como preguntar "¿todas las puertas necesitan cerraduras o solo puertas exteriores"? Solo usted puede responder esta pregunta al considerar las amenazas dentro y fuera de su red.

— Ryan Griggs

55

Como dice la pregunta de Security.SE : "La seguridad es un tema muy contextual: las amenazas que se consideran importantes en su entorno pueden ser intrascendentes en el de otra persona, y viceversa. ¿Está tratando de proteger algo de valor global contra las amenazas persistentes avanzadas? O ¿Está buscando un enfoque rentable para una pequeña empresa de bajo perfil? Para obtener las respuestas más útiles, debe decirnos: qué activos está tratando de proteger, quién usa el activo que está tratando de proteger y a quién creo que podría querer abusar de él (y por qué); ...

— DW

2

qué pasos ya ha tomado para proteger ese activo; qué riesgos cree que aún necesita mitigar ". Este tipo de contexto es esencial. Le sugiero que edite su pregunta para incluir esta información.

— DW

50

Esto es una cuestión de opinión, y también tiene que ver con problemas regulatorios (si enfrenta alguno).

Incluso si no es necesario actualmente, soy un gran defensor de mantener el HTTPS habilitado entre cualquier firewall de nivel de aplicación / equilibradores de carga / servidores front-end y los servidores back-end. Es una superficie de ataque menos. He contratado lugares que debían convertirse a medida que se pasaba 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 de servicios de fondo. Estableceríamos una fecha de vencimiento agradable y lejana en el futuro para evitar cambios innecesarios.

— Tim Brigham
fuente

1

es mejor comenzar por ahí - las palabras que te dieron los puntos :)

— danday74

12

Esta es una buena idea. No desea que la NSA haga dibujos tontos de la topología de su red .

— Kevin

3

Cifrar todas sus comunicaciones también protege contra las escuchas internas, ya sea en la forma de la computadora del interno que recogió un troyano mientras examinaba imágenes de gatos, o un pequeño rastreador conectado a un puerto de red detrás de un escritorio no utilizado, o una contraseña wifi compartida un poco demasiado flojo.

— Doktor J

8

" We'd set the expiration date nice and far into the future to avoid unnecessary changes." y agregue una regla a su conjunto de monitoreo preferido para avisarle cuando esté por caducar. ¡Por favor!

— GnP

2

@GnP Lo hago también: si es un certificado con un período de 10 años, nuestra política siempre exige que el servidor de fondo se reemplace dentro de ese período ... Lo hace un poco redundante y no parece necesario mencionarlo en la respuesta.

— Tim Brigham el

19

TL; DR debe cifrar el tráfico a menos que esté en el mismo host.

No puedes confiar en tu red. Malwares en su propia red puede 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-Nakibly-TCP-Injection-Attacks-in-the-Wild- A-Large-Scale-Study-wp.pdf
Red india que olfatea 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

— Tom
fuente

16

¿Es necesario que los "muchos otros servidores" se ejecuten a través de HTTPS o, dado que no se puede acceder a ellos externamente, ¿pueden ejecutarse a través de HTTP de forma segura?

Esto realmente depende de lo que intentes 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 se analicen dentro de su red, entonces tal vez debería 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 hay 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 que depende. ¿Que estás tratando de hacer? ¿Qué tipo de datos está 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 puedan ser mal utilizados cuando se transmiten dentro de su red, le sugiero que se reúna con la gerencia para solucionar el problema. Entonces, al final, ¿qué estás tratando de proteger y por qué estás tratando de protegerlo?

— usuario5870571
fuente

13

En el pasado, la gente asumía que las redes internas eran seguras como casas. Una vez tuve una disputa con un supervisor que estaba horrorizado porque mis servidores internos estaban ejecutando sus firewalls incorporados. "Si no puede confiar en su red interna, ¿en quién puede confiar?" Señalé que teníamos computadoras portátiles para estudiantes en nuestra red interna y que no había firewall entre las computadoras portátiles para estudiantes y mis servidores. Él, siendo nuevo en la academia, parecía tener su universo hecho jirones por esta información.

Las redes internas ya no se consideran seguras, incluso si no tiene computadoras portátiles para estudiantes en su red. Vea la respuesta de Tom para algunos ejemplos.

Dicho esto, sí, depende de la información que se transmite, cualquier problema de cumplimiento legal, etc. Puede decidir que no le importa si alguien olfatea, digamos, datos meteorológicos. Dicho esto, es posible que incluso si los datos enviados no son confidenciales ahora , alguien decida agregar características a su aplicación más tarde que sean confidenciales, por lo que recomendaría una mayor paranoia (incluido HTTPS).

— Katherine Villyard
fuente

Los datos sobre el clima pueden ser lo suficientemente sensibles: alguien podría basar sus decisiones incorrectas en datos sobre el clima alterados.

— Hagen von Eitzen

1

De acuerdo, depende de para qué está utilizando los datos meteorológicos. Estaba tratando de encontrar algo inocuo. :)

— Katherine Villyard

1

@HagenvonEitzen o el atacante inyectaría malware / anuncios allí, por lo que la abuela se enoja cuando verifica el clima con su máquina Windows XP.

— André Borie

8

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 funcionarán con un rendimiento degradado a través de un enlace no cifrado (HTTP / 2, gRPC, etc.), quizás la mejor pregunta es: ¿hay alguna ¿Por qué necesita degradar un enlace de red a HTTP? Si no hay una razón específica, entonces la respuesta es quedarse con HTTPS.

— Aaron
fuente

Buen proceso de pensamiento

— danday74

5

La única razón para deshabilitar el cifrado que se me ocurre es el rendimiento. Sin embargo, en su caso, los servidores internos están interconectados a través de HTTP, lo que significa que ya tienen el costo de rendimiento de ejecutar un servidor web, admitiendo el protocolo HTTP y codificando datos en HTTP / JSON / lo que sea. Deshabilitar el cifrado liberará quizás 100 KB de RAM y le otorgará unos pocos microsegundos por KB de datos transmitidos, lo que no tendrá un impacto visible en el rendimiento general. Por otro lado, tendrá que prestar mucha más atención a la seguridad ya que ahora ejecuta HTTP en su intranet. De hecho, es posible que una configuración de cortafuegos más estricta ralentice las cosas más que la desactivación del cifrado las ha acelerado, lo que resulta en un peor rendimiento percibido por los usuarios finales.

Será como poner un alerón en un tractor: teóricamente ganas casi nada, y prácticamente muchos inconvenientes.

— Dmitry Grigoryev
fuente