¿El uso de jCryption 3.0 + SSL ha mitigado la vulnerabilidad de Heartbleed?

Question

¿El uso de jCryption 3.0 + SSL ha mitigado la vulnerabilidad de Heartbleed?

#1 de mikeazo (1 votos)
#2 de Indolering (0 votos)

2

Me encontré con un proyecto llamado jCryption 3.0, que cifra los datos entre el cliente y el servidor, sin usar SSL. Si el JavaScript de un sitio web hubiera utilizado jCryption 3.0 para cifrar los campos del formulario de inicio de sesión antes de enviarlos (a través de SSL) al servidor, ¿esta técnica habría mitigado un posible ataque de Heartbleed?

Esta pregunta asume lo siguiente:

SSL se usa para verificar la identidad del sitio y proporcionar una segunda capa de cifrado
jCryption 3.0 se utiliza para cifrar cualquier información confidencial enviada entre el cliente y el servidor, incluso a través de SSL
El servidor al que publica el navegador es un equilibrador de carga (que ejecuta una versión vulnerable de openssl), que descifra el tráfico entrante y lo envía a un servidor web para su posterior procesamiento

A mi entender, alguien que realice un ataque Heartbleed en el equilibrador de carga vulnerable solo podría descubrir un nombre de usuario cifrado & Los datos de la contraseña o la clave privada del servidor de la memoria.

openssl javascript heartbleed

pregunta Jay Sheth 16.04.2014 - 19:09

fuente

2 respuestas

Lea otras preguntas en las etiquetas openssl javascript heartbleed

conexión SSL MITM -bash: -sudo: comando no encontrado [cerrado]

score 1 · Answer 1

El servidor tiene que descifrar la información. Una vez que se descifra, se encuentra en la memoria de proceso del servidor en texto plano. Entonces se filtraría por el corazón.

Además, el servidor debe tener la clave de descifrado. Por lo tanto, es probable que se almacene en la memoria del proceso y se pueda recuperar a través de ataques cardíacos.

score 0 · Answer 2

Creo que el atacante en teoría podría recuperar la clave privada para el certificado SSL del servidor, MITM la sesión y luego comprometer la biblioteca JS que envía al cliente. Sin embargo, ese es un truco bastante elaborado y (dado el 100% de efectividad de SSLStrip) probablemente no valdría la pena. Así que sí, ayudaría a mitigar el problema, pero no al 100%.

Una forma en que podría mitigarlo aún más es almacenar las claves públicas / privadas en el almacenamiento del lado del cliente del navegador o hacer algunas huellas digitales del entorno JS del cliente y del propio navegador. Sin embargo, esto también sería un cifrado de mejor esfuerzo: si el navegador vacía sus claves de almacenamiento, no tiene más remedio que generar otras nuevas. Es posible que pueda pedirle al cliente que realice algún tipo de autenticación fuera de banda o simplemente usarla como una forma de verificar a los clientes mientras trabaja en la regeneración de sus certificados TLS y revocar los antiguos ...