¿Cómo reemplazar SSL / TLS?

Sin SSL, sin seguridad. Las cosas en el mundo real rara vez son simples, pero aquí es el caso. Esto se ve fácilmente de la siguiente manera: cualquier cosa que haga en Javascript, se hará en Javascript enviado por el servidor . Cualquier atacante que esté en posición de ver los datos también puede modificarlos a voluntad (por ejemplo, la forma más fácil de espiar WiFi es ejecutar su propio punto de acceso falso, y luego, naturalmente, puede modificar todos los datos a medida que van y vienen) ; por lo tanto, un atacante de este tipo puede simplemente eliminar o alterar cualquier solución basada en Javascript que pueda encontrar y desactivarla. O simplemente agregue un enlace a también y envíe la contraseña en forma clara como parámetro adicional.

Ahora, incluso si pudiera obtener "Javascript seguro" en el navegador del cliente, se encontraría con todos los problemas que conlleva el criptografía de Javascript, y se detallan en el artículo al que se vincula. Pero esto es solo una consideración secundaria, en comparación con la falla fundamental explicada anteriormente: sin SSL, usted no puede asegurarse de que lo que se ejecuta en el navegador del cliente sea su código.

Tratar de manejar la contraseña de manera segura en un sitio web que no es SSL es como tratar de realizar una cirugía cerebral de forma segura con solo una cucharita de té y una palanca oxidada. Simplemente no lo hagas. Si hay datos confidenciales que fluyen al sitio web (por ejemplo, nombres y direcciones), DEBE aplicar mecanismos de protección razonables. Si los datos no son confidenciales, ¿por qué necesitaría contraseñas?

En mi humilde opinión, el generador de números aleatorios es la menor de tus preocupaciones aquí. Dado que el código para invocar el cifrado se envía de forma clara, es trivial para alguien MITM la interacción.

Si el servicio requiere el nivel de seguridad proporcionado por el cifrado y lo entrega un sitio web, DEBE usar HTTPS (e idealmente todo el material de seguridad asociado, como las cookies seguras + httponly y HSTS).

La única forma de evitar esto sería escribir una aplicación HTML5 (donde el código se descarga con poca frecuencia), pero incluso esto tiene importantes inconvenientes.

La mejor solución, como se ha indicado, es obtener un plan de alojamiento web real que permita https. Esto no debería ser demasiado costoso, de hecho, incluso debería ser posible encontrar un proveedor gratuito para proporcione esto.

En su defecto, ¿cuál es su caso de uso? Parece que tiene en mente un grupo de usuarios para su sitio web. Si ese es el caso y no solo está ofreciendo un servicio de notificación de eventos por suscripción a personas al azar en Internet, considere proporcionar la base para una conexión "segura" en un canal diferente.

Se me ocurre que enviar el código a su máquina por otra fuente confiable (publicar CD's por correo electrónico e informarlos por correo electrónico, simplemente enviar el software como un archivo adjunto a un correo electrónico firmado digitalmente, etc.) permite Usted debe cargar previamente el software con una clave pública criptográfica.

Luego, puede negociar una conexión segura a través de un método de conexión no seguro (como http) ya que el código que determina si el servidor ha descifrado satisfactoriamente los datos cifrados con su clave pública vive en el cliente. El resultado es un flujo de datos de la aplicación http 'texto sin formato', con la arruga de que los datos de la aplicación en sí están cifrados.

Esto es un montón de problemas y un método no estándar. Tiene problemas con la implementación ya que pocas personas lo han intentado para ofrecer asesoramiento, y con seguridad, ya que pocas personas han revisado su confiabilidad *.

El canal alternativo puede tener problemas de seguridad. ¿Se podría interceptar el correo? ¿Podrían los estafadores hacerse pasar por su organización y enviar su propia versión "segura" de su software? ¿Sus usuarios son lo suficientemente inteligentes como para verificar las firmas digitales en los correos electrónicos que envía? Estas son todas las preocupaciones que deberá considerar y aceptar como riesgos o intentar mitigar con soluciones novedosas, ya que tiene menos orientación no solo sobre cómo implementar, sino también qué preguntas debe hacer (debe hacer preguntas). más que solo estos tres!).

Al hablar con la gerencia de la ONG, considere delinear la situación en estos términos:

1. El último método implica un riesgo significativo y terminará costándoles más tiempo de implementación que el que pagará simplemente por el alojamiento. El programa debe actualizarse, especialmente si el servidor (o el par de claves del servidor) cambia, y continuamente distribuido a nuevos usuarios después de la implementación inicial.
2. No hacer nada en absoluto y usar una contraseña en http con direcciones y nombres (y potencialmente direcciones de correo electrónico) podría ser un desastre de relaciones públicas si alguna información se filtra (y lo hará), un riesgo importante. Esto se ve agravado por el hecho de que las personas reutilizan las contraseñas y su mala práctica podría estar vinculada a violaciones posteriores.
3. Como tal, se le ha dado un pensamiento significativo a la situación y no solo va a sugerir la solución descrita en el paso 4 porque 'todos lo hacen' (aunque, en el caso de que todos lo hagan porque es una buena práctica, esto no es fácil una cosa mala). Ser capaz de proponer la solución alternativa (si es complicada y excesiva) descrita en los pasos 1 y amp; 2 es evidencia de que se está llevando a cabo esta diligencia debida.
4. En base a esto, https hosting con bajo costo (o sin costo) en curso es el enfoque menos costoso y menos riesgoso.

* Jonathan Gray entra en por qué se encontrará con problemas al codificar un sistema seguro en su respuesta , vea la sección que comienza "TLS es también un sistema mucho más intrínseco"

Primero reemplaza tu host.

Obtener certificados SSL es más fácil que nunca gracias a las CA gratuitas. LetsEncrypt , por ejemplo, ofrece certificados gratuitos de validación de dominios SSL / TLS de manera automatizada siempre que sea el propietario del nombre de dominio. Hay más explicaciones en La respuesta de StackzOfZtuff sobre sus capacidades.

Hay instrucciones sobre cómo configurarlo en su sitio de la comunidad con preguntas frecuentes y un foro de ayuda.

El problema con JS es la generación de números aleatorios (que es vital para la seguridad del cifrado moderno). Existen bibliotecas disponibles que ayudan a resolver esto, pero debe asegurarse de que la biblioteca haga uso de crypto.getRandomValues así como la capacidad de obtener entropía de la entrada humana (como la actividad del mouse o del teclado). Sin embargo, esto es especialmente engorroso para los dispositivos móviles, especialmente si se considera el hecho de que el hardware en sí es menos capaz de generar números aleatorios seguros.

También me gustaría agregar un punto adicional sobre RSA. Solo puede cifrar pequeñas cantidades de datos con ella, y la cantidad de datos es relativa a la longitud de clave utilizada. No solo eso, sino que la RSA es lenta. Si necesita una cantidad decente de datos o está realizando varias solicitudes al servidor, le recomiendo cifrar una clave aleatoria (CSPRNG) con JS en el lado del cliente utilizando la clave pública del servidor y utilizando esa clave para el cifrado simétrico.

Editar: TLS es también un sistema mucho más intrínseco que trabaja muy duro para proteger contra todo tipo de ataques. El único tipo de ataque contra el que TLS no protege eficazmente es una desconexión forzada. TLS se encarga automáticamente de todo, desde la autenticación del servidor hasta la protección de intermediarios hasta la protección contra ataques de reproducción en una capa que ni siquiera es vista por el programador de alto nivel promedio. En su situación, usted señala que no puede utilizar conexiones TLS / (SSL) reales, lo cual es desafortunado. Pero me gustaría dejar claro que lo recomiendo altamente contra cualquier implementación personalizada diseñada para reemplazar TLS.

Potencialmente como último recurso, ya que no será tan bueno como TLS de extremo a extremo ... pero quizás pueda poner algo como CloudFlare al frente para al menos tener TLS en el punto final del cliente?

Otra opción es escribir un complemento del navegador, o un script de Tampermonkey (para reducir los dolores de cabeza de múltiples plataformas), y tener el código JS previamente entregado en el navegador. Menciono esto simplemente como una medida de último recurso.

El inconveniente obvio es que sus usuarios están limitados a usar las computadoras que ya tienen el complemento, o a tener que descargarlo nuevamente cada vez que usan un nuevo dispositivo. También sería difícil usar dispositivos móviles con él.