Si una aplicación maliciosa ha encontrado su camino en una computadora que ejecuta un servidor WebSocket solo localhost, ¿ayudaría si las comunicaciones usaran SSL?
Si es así, ¿cómo podría fallar SSL si una aplicación maliciosa
Por lo general, SSL no ayudará.
Si el atacante tiene control completo sobre la computadora, entonces gana. Puede inspeccionar y modificar la memoria de todos los procesos en la computadora.
Si el atacante es solo un usuario no administrativo, entonces no podrá espiar el proceso de otros usuarios. Sin embargo, si el atacante puede ejecutar el código como el mismo usuario que el servidor o el cliente de su conexión local de host prevista (o ambas), entonces puede saquear la RAM del proceso involucrado y gana. Además, suponiendo que un atacante no administrativo significa que usted confía en que dicho atacante podría ingresar a la máquina pero no encontró ningún agujero explotable de privilegios: es una suposición bastante optimista.
Si el atacante solo puede escuchar las comunicaciones, pero no echar un vistazo a la memoria del proceso, entonces SSL puede ayudar, ya que evitará el espionaje. Sin embargo, este no es un escenario muy realista: espiar las conexiones de localhost requiere privilegios de administrador local.
Donde SSL puede ayudar es sobre autenticación : un atacante local, con derechos no administrativos, puede intentar conectarse al servidor y hacerse pasar por el cliente, o viceversa. SSL proporciona autenticación: el cliente valida el certificado del servidor y, si el servidor solicita un certificado de cliente, el servidor valida el certificado del cliente. Tenga en cuenta, sin embargo, que en localhost, hay formas más eficientes para que un servidor sepa quién está en el otro extremo del socket (por ejemplo, getpeereid() ).
Lea otras preguntas en las etiquetas tls windows-permissions defense permissions websocket