Obviamente, TLS es una necesidad para cualquier autenticación segura. Por favor, cambia tu configuración de paranoia hasta 11 para esto.
Antecedentes : (En caso de que las personas no estén familiarizadas con el protocolo WebSocket (WS) y sus idiosincrasias) La conexión WebSocket TLS (WSS) es una conexión diferente de la conexión HTTP TLS. Esto significa que uno no puede autenticar automáticamente al otro. Debido a los proxies, especialmente a uno malicioso que realiza un ataque MitM, el simple hecho de tener la misma dirección IP remota (o incluso la misma ID de sesión) no garantiza que las dos conexiones sean del mismo navegador.
WS es una conexión TCP persistente con una API muy limitada en el lado del cliente que no permite inspeccionar los detalles de TLS para una conexión WSS. Está diseñado para funcionar bien con firewalls y proxies (no maliciosos) que restringen el tráfico a solo el tráfico HTTP, y es deseable debido a su ubicuidad en los navegadores web modernos.
En PHP, WS (típicamente) se implementa utilizando un script de línea de comandos (CLI), que ejecuta su propio servidor aceptando y administrando las conexiones de socket directamente, en lugar de estar mediado a través de un servidor HTTP. (Si hay un servidor HTTP involucrado, solo es para reenviar el tráfico después de la actualización exitosa, y se convierte en un proxy transparente para todos los propósitos después del protocolo de enlace). Por lo tanto, las superglobales típicas de PHP no tienen sentido en la CLI de PHP.
Es posible pasar cookies durante el protocolo de enlace de WS, incluido un ID de sesión. En PHP CLI, es posible (pero sin ganas) acceder a los datos de la sesión actual, incluso después de un cambio de estado provocado por el lado HTTP de las cosas, si conoce el ID de la sesión. Sin embargo, debido a que las cookies se pasan solo durante el protocolo de enlace de WS, el servidor WS no recibe notificaciones de cambios en las cookies, como el ID de sesión.
AJAX permanece autenticado a través de la conexión HTTPS, por supuesto, y estoy seguro de que hay una manera de aprovechar las solicitudes de AJAX para autenticar las conexiones WSS con el mismo navegador.
Ejemplo de secuestro de sesión : Alice inicia sesión en bob.com a través de medios HTTPS normales, pero tiene un proxy malicioso entre ellos, propiedad de Mallory, que ejecuta un ataque de espionaje de MitM que ha comprometido la sesión ID.
Mallory luego usa el ID de sesión en su propia cookie de sesión para conectarse al servidor WSS, que es donde me encuentro con mis problemas, porque no sé a quién diferenciar entre el navegador abierto y totalmente autenticado de Alice y el de Mallory. Navegador completamente diferente en una computadora completamente diferente.
Entonces, sabiendo que el ID de sesión es potencialmente inseguro, es un objetivo primordial y es inmutable una vez que se inicia la conexión WS, ¿cómo puedo autenticar que una conexión WSS determinada se está ejecutando en la misma instancia del navegador en la misma computadora que una conexión HTTPS dada?
Editar : una vez que se inicia la conexión HTTPS, Mallory no intenta interferir para evitar que se detecte. Por lo tanto, una vez que se establezca la TLS, la conexión HTTPS estará protegida de Mallory a partir de este punto en adelante, pero Mallory aún tendría el ID de sesión.
Justificación para este requisito de caso límite : estoy escribiendo software de código abierto WebSocket, por lo tanto no puedo hacer cumplir la protección de la ID de sesión a través de medios tales como asegurar que la cookie de sesión tenga el indicador de seguridad establecido. que el ID de sesión se regenera, etc., pero puede exigir que el implementador incluya un script de cliente que ayude a garantizar la autenticación en ambos medios.