Socket.IO y WebSocket no proporcionan información de conexión subyacente (como el certificado o la clave pública del canal SSL / TLS), y estoy tratando de entender el razonamiento.
El contexto para esta pregunta es una aplicación web de carga lateral que desea consultar el certificado o la clave pública de su conexión subyacente. La consulta se usaría para el certificado o la fijación de claves públicas. Aquí, la carga lateral proporciona un canal de distribución confiable, por lo que la manipulación de HTML / CSS / Javascript no es una preocupación o amenaza.
Aquellos que reclaman su estado no necesario (1) la plataforma realiza comprobaciones por lo que no es necesario; (2) CSS o Javascript podrían usar el certificado del servidor o la clave pública para rastrear a los usuarios, por lo que es una posible fuga; y (3) es ineficiente, por lo que no es bienvenido.
Creo que hay algunos problemas con los argumentos. Primero, hemos visto una serie de problemas en el pasado, como Diginotar y recientemente Turquía manipula el DNS . La plataforma / navegador no detectó los problemas (sin Chrome debido a la fijación), por lo que los navegadores no están realizando las comprobaciones correctas . Entiendo que el navegador no puede saber estas cosas (es una "característica" o limitación en el modelo de seguridad), y es la razón por la que quiero que las aplicaciones de mi competencia lo hagan.
Segundo, el malware quiere recopilar y egresar datos. Así que las partes más peligrosas de Socket.IO y WebSocket API son open y write . Dudo que la capacidad de consultar el certificado o la clave pública de un servidor supere el riesgo de open y write .
En tercer lugar, estoy bastante seguro de que hay mejores vectores para CSS o Javascript para rastrear a los usuarios o su navegación (como CSS que sigue el cambio de color en un enlace visitado), por lo que no lo considero una amenaza inmediata o de alta prioridad. . Si es una amenaza, siento que los beneficios del endurecimiento del canal superan la posible fuga. (Especialmente en la era posterior a Snowden).
Finalmente, con respecto a la eficiencia, tengo que remitir al Dr. Jon Bentley: "Si no tiene que ser correcto, puedo hacerlo tan rápido como quisiera". Me imagino que incluye todo tipo de optimizaciones inteligentes, como eNull al usar TLS.
Aquí está mi pregunta cerrada: ¿se considera realmente una fuga potencial para permitir que Javascript solicite el certificado del servidor? ¿El miedo a una "filtración" del certificado del servidor realmente supera los beneficios del endurecimiento y la fijación de canales?
Aquí está la pregunta abierta: ¿qué es lo que no entiendo correctamente o qué me falta? Siento que hay una gran desconexión entre lo que quiero y espero, y lo que las personas que escriben los estándares están dispuestos a brindar.
Para completar, "aplicación web" es el término genérico y cubriría, por ejemplo, Sys Apps, Hosted Apps, Chrome Apps, Packaged Apps, Installable Apps, etc. No cubriría otras aplicaciones web, como Bookmarked Apps porque eso requeriría una búsqueda.
Relacionado: otra buena pregunta sobre seguridad de WebSocket: Elaborar seguridad de websockets , pero no discutir las características que faltan.