¿Cifrar y autenticar el tráfico de host local?

5

Tengo algunos componentes de aplicación en la misma máquina pero en diferentes idiomas que necesitan comunicarse. Estoy utilizando comunicación por socket en localhost para hacerlo. Los datos transferidos son confidenciales.

¿Debería cifrarse esta comunicación?

Quiero decir que un atacante tendría que poder ejecutar código en la máquina para interceptar esto y, en ese caso, el usuario perdió de todos modos, ¿no?

    
pregunta Biff Wellington 04.05.2014 - 14:02
fuente

2 respuestas

8

Necesitas cifrado para disuadir a los atacantes pasivos (personas malvadas que espían en la línea e intentan descifrar el contenido de los datos) e integridad (y su hermano autenticación ) para bloquear a los atacantes activos que alteran los datos mientras están en tránsito. SSL proporciona ambos. Sin embargo, esto tiene sentido solo en contextos donde los atacantes pueden espiar o alterar los datos en tránsito. Para dos procesos en la misma máquina, que se comunican a través de la red "localhost", los atacantes que pueden hacerlo tienen, por lo general, "ya ganado".

Los detalles pueden diferir dependiendo del sistema operativo. Sin embargo, su seguridad normalmente dependerá del sistema operativo, no del cifrado. Considere, por ejemplo, un sistema Unix con múltiples usuarios. Si los dos procesos se comunican entre sí, los procesos de otros usuarios no podrán ver los intercambios de datos (a menos que el atacante sea root y luego pueda hacer cualquier cosa); sin embargo, pueden probar suplantación : en algún momento, uno de sus componentes debe conectarse al otro, y el punto de encuentro para sockets TCP es un número de puerto. Un atacante que puede ejecutar su propio código (como usuario normal) en la máquina puede mantener un servidor falso que recibirá la solicitud de conexión en lugar del componente previsto. Para protegerse de eso, el cliente tendría que asegurarse de que habla con el servidor esperado (y viceversa): este puede se realiza con SSL, pero existen mejores soluciones (en este caso, utilizando Unix -dominios con una ruta protegida por derechos de acceso al sistema y / o getpeereid() ).

Si, en su caso, se supone que la máquina local está "limpia" (no se ejecuta ningún código hostil en la máquina, bajo ninguna identidad), entonces las conexiones a localhost son seguras y no hay necesidad de ninguna protección adicional. Si es posible que se ejecute código hostil pero no privilegiado en la máquina (ese es el modelo de "máquina multiusuario compartida", como era típico de los sistemas Unix a fines de la década de los 80), entonces debe usar las características del sistema operativo para asegurarse de que las conexiones se realicen. al proceso correcto (es decir, a un proceso que se ejecuta en la identidad esperada). SSL sería una exageración.

    
respondido por el Tom Leek 14.05.2014 - 15:51
fuente
0

Bueno, si los dos programas se ejecutan en el host local, ¿por qué quiere usar la comunicación de red? Puede usar cualquier IPC (comunicación entre procesos) como Canalizaciones con nombre Puede especificar un descriptor de seguridad para una canalización con nombre cuando llame a la función CreateNamedPipe. El descriptor de seguridad controla el acceso a los extremos del cliente y del servidor de la canalización con nombre.

Lea el Modelo de control de acceso para aprender cómo asegurar tuberías nombradas. enlace O simplemente puede usar un algoritmo de cifrado simétrico para el cual el secreto es conocido en ambos procesos, puede codificar el secreto en el código.

    
respondido por el techno 04.05.2014 - 16:48
fuente

Lea otras preguntas en las etiquetas