Lograr el cifrado de extremo a extremo con TLS

Lamentablemente encontrará que esto simplemente no está hecho. Como ha señalado correctamente, no permite que el cliente se conecte completamente a través del uso de un canal TLS, por lo que el descifrado en el servidor web o punto final TLS es un hecho.

Entonces, lo que hacen las organizaciones es evaluar el riesgo y luego observar otros controles de seguridad en el servidor web. Estos incluyen:

• aislamiento físico
• Segregación lógica
• Conexiones de administración separadas
• autenticación fuerte
• Monitoreo del acceso de administrador
• Endurecimiento del servidor
• etc

(Existe una posible solución parcial, que sería ejecutar el servidor web con RAM encriptada, discos encriptados, etc.). Sin embargo, esto conlleva un serio impacto en el rendimiento y aún no protege contra un atacante que haya accedido a el servidor web.)

Si desea una solución verdaderamente completa para que los clientes accedan a su información personal (que reside en un mainframe en la LAN del banco) desde un servicio web (alojado en su DMZ), tendrá que crear un complemento de navegador para su clientes.

Esto requerirá que dediquen un minuto adicional (como usuario por primera vez) a descargar & instale su complemento ... pero no necesitarán privilegios administrativos en su computadora para hacerlo.

Seguirá usando 2 sesiones TLS separadas, pero se ajustarán a una solución de extremo a extremo que cifrará los datos del usuario en el mainframe y descifrará los datos en su cliente (usando el complemento). Puede utilizar PGP (prefiero el criptografía asíncrona de NaCl) como base para su sistema de cifrado de mainframe a plugin.

editar: como alternativa, puede enviar a su cliente un dispositivo (como el huevo de ebay) o hacer que descarguen una aplicación móvil (como google auth) que puede proporcionarles una contraseña basada en el tiempo (la contraseña utilizable está caducada / se reemplaza regularmente, generalmente en cuestión de segundos, permitiendo que un PIN corto [~ 8 dígitos] sea seguro). Cuando su cliente solicita información confidencial, el mainframe les enviará un archivo ZIP encriptado que se aseguró antes de abandonar el mainframe. Luego usarían el PIN actual proporcionado por su dispositivo / aplicación autenticador como contraseña para descifrar los datos.

Una opción de tecnología aún más baja (en comparación con un dispositivo / aplicación autenticador) es permitir que el cliente compile una lista de PIN de uso único que pueden marcar cuando los agotan. Puede solicitar al cliente que recoja estas listas en su sucursal local o puede enviarlas por correo al cliente. Esta es una forma de autenticación de 2 factores ya que el cliente todavía tendrá que usar su contraseña para acceder a su banca en línea.

Básicamente, si entiendo su necesidad, todo lo que desea es reenviar el puerto de escucha SSL del mainframe para que escuche en un host en la DMZ. Esto podría hacerse usando cualquier solución NAT.

Aquí hay una arquitectura que podría funcionar:

• Genera un par de claves de cifrado asimétrico. La clave privada será conocida solo por un programa que se ejecuta en su mainframe que es el punto final que recupera los datos.
  • En el sitio web, use una biblioteca de cifrado basada en JavaScript del lado del cliente que pueda generar una clave de cifrado simétrica con la fuerza adecuada, como AES 256.
  • El sitio web hará que la clave pública asimétrica esté disponible en el script. Utilizando otra biblioteca de Javascript para que coincida con el esquema de encriptación asimétrica del programa mainframe, encripte la clave simétrica, antes de enviarla de vuelta al servidor web. Haga esto a través de SSL y, por supuesto, para proteger el transporte.
  • El servidor web realiza una solicitud al programa de mainframe solicitando los datos y pasa la clave de cifrado cifrada asimétricamente que generó el navegador web.
  • El programa de mainframe usa su clave privada para descifrar la clave simétrica. Luego, utiliza la clave simétrica para cifrar los datos confidenciales que está recuperando y los devuelve al sitio web, que los envía al navegador web del cliente.
  • El navegador web del cliente descifra la carga útil.

Este es tu modelo base. Dependiendo de la naturaleza de los datos, la singularidad de las solicitudes, etc., es probable que desees mejorar aún más las cosas, como por ejemplo, compartir los datos cifrados simétricamente, determinar con qué frecuencia cambiar las claves de cifrado, etc. Y para ser precisos. Esto no es 100% de extremo a extremo, ya que no conocemos la naturaleza de su programa de mainframe, o si sus datos están cifrados en reposo en el almacén de datos, pero creo que esto lo acerca mucho a sus necesidades, ya que la web El servidor o cualquier otro salto en el medio no podrá leer los datos confidenciales.

Hay varias bibliotecas por ahí que implementan algoritmos de cifrado en JavaScript para hacer AES y algos asimétricos como RSA.

Esta arquitectura no debe causar ningún dolor de cabeza adicional para sus usuarios, como puede ver con una solución basada en certificados de clientes o la instalación de software adicional en su máquina.