¿qué tan seguro es el cifrado rsa para un inicio de sesión web sin https?

Será algo seguro, pero no tan seguro como https, además de las credenciales, todos los demás datos no están encriptados. Si planea usarlo en redes públicas (abiertas), recomendaría configurar un proxy como se describe aquí . Incluso con un certificado autofirmado, será mucho más seguro.

Mi conjetura es que tiene una vulnerabilidad grave que podría ser explotada, pero todo depende de la implementación. Decir que utiliza RSA dice muy poco sobre la seguridad efectiva del sistema. RSA no será el enlace más débil.

• ¿Previene los ataques de repetición?
• ¿Proporciona cifrado autenticado mediante el uso de MAC?
• ¿Verifica el cliente la identidad del servidor en el otro extremo antes de responder a los desafíos?
• ¿Después de su inicio de sesión, un atacante podría alterar sus comandos remotos para hacer cosas maliciosas?

Puede intentar explorar el código fuente ( ServerPAMAuth parece una es un buen lugar para comenzar) y tratar de encontrar fallas, pero honestamente no me molestaría.

Lo que haría es configurar un proxy inverso que use SSL. Simplemente sucede Escribí una guía detallada sobre cómo hacer eso en nginx para una cámara web el otro día, simplemente reemplace la cámara web con el servidor RStudio y estará bien, y tenga en cuenta que puede ejecutar el proxy y Rstudio en el mismo servidor (así que Reemplace las referencias a 192.168.0.101 por localhost o 127.0.0.1 para obtener mejores resultados). Entonces, incluso si el protocolo de autenticación es vulnerable, aún estará protegido (suponiendo que realmente utilice un certificado firmado por CA, o haga que su navegador u otra aplicación confíe en su certificado autofirmado).

EDITAR: En realidad, de acuerdo con sus instrucciones, deberá agregar una proxy_redirect línea para:

proxy_redirect http://localhost:8787/ $scheme://$host:$server_port/;

Esto dice que si tiene una URL completa en un campo de encabezado HTTP (por ejemplo, en un redireccionamiento HTTP 302/304 donde el campo Ubicación es una URL que indica dónde se movió el recurso) cambiará de http://localhost:8787/path/to/something a $scheme://$host:$server_port/path/to/something como necesario, donde $scheme será https .

Los servicios de seguridad proporcionados por la aplicación web que está describiendo son diferentes a los que ofrece https. Al enviar la contraseña a través de RSA, la contraseña debe ser criptográficamente segura, asumiendo que RSA se está utilizando correctamente. Sin embargo, la conexión resultante no se cifrará; el nombre de usuario y la contraseña del usuario son los únicos datos que están protegidos. En https, todo el tráfico está encriptado. Https usa RSA para el intercambio de claves de la sesión inicial, por lo que en teoría, la sesión es tan segura como la sesión de rstudio durante la configuración inicial. Sin embargo, https puede proporcionar secreto perfecto para la credencial del usuario (si está configurado para hacerlo) y proporcionará confidencialidad e integridad durante el resto de la sesión. En otras palabras, en el esquema de solo RSA, las contraseñas están protegidas, pero no tanto, y el resto de la sesión está abierta a cualquier persona que pueda escuchar.

Al escribir que es básicamente una aplicación web, esto implica que la aplicación también se transfiere a través de HTTP (si no la almacena en caché o la instala como una aplicación web).

En ese caso, un atacante podría simplemente reemplazar la aplicación web real con una aplicación que no realice el cifrado o que, además, envíe contraseñas a un servidor controlado por el atacante. Por lo tanto, no importa qué tan seguro sea el RSA, su aplicación no es segura.

Además, como han mencionado otros, es muy probable que el contenido de su sesión se transfiera como texto sin formato y, por lo tanto, no esté protegido contra las escuchas ilegales y, si no se utilizan códigos de autenticación de mensajes, la manipulación. Por lo tanto, no me gustaría utilizar esa aplicación sin SSL (o un Proxy SSL).