2

I came across a project called jCryption 3.0, which encrypts data between the client and server, without using SSL. If a website's JavaScript had used jCryption 3.0 to encrypt login form fields before sending them (over SSL) back to the server, would this technique have mitigated a potential Heartbleed attack?

This question assumes the following:

  1. SSL is used to verify the identity of the site, and provide a second layer of encryption
  2. jCryption 3.0 is used to encrypt any sensitive data sent between the client and server, even over SSL
  3. The server that the browser posts to is a load balancer (running a vulnerable version of openssl), which decrypts the incoming traffic and sends it on to a web server for further processing

From my understanding, someone performing a Heartbleed attack on the vulnerable load balancer would potentially only be able to uncover encrypted username & password data, or the server's private key from memory.

Improve this question
0

2 Answers 2

Reset to default
1

The server has to decrypt the information. Once it is decrypted, it is in the server's process memory in plaintext. Then it would be leaked by heartbleed.

Furthermore, the server must have the decryption key. So it would likely be stored in the process memory and would be recoverable via heartbleed attacks.

Improve this answer
2
  • 1
    Hi, in my example, I had a load balancer (running a vulnerable version of openssl), and a web server behind it. In this example, the client-side JavaScript would encrypt the submitted form data, and send it over SSL to the load balancer. Thus, someone who expoited the Heartbleed bug would have only had access to the load balancer's memory, not the web server's memory. The web server would handle decryption of the form data.
    – Jay Sheth
    Commented Apr 18, 2014 at 14:20
  • @jaysheth It would sound like you were probably safe then.
    – mikeazo
    Commented Apr 18, 2014 at 14:28
0

I believe the attacker could theoretically retrieve the private key for the server's SSL certificate, MITM the session, and then compromise the JS library you send to the client. However, that's a pretty elaborate hack and (given the near 100% effectiveness of SSLStrip) probably wouldn't be worth the effort. So yes, it would help mitigate the issue, just not 100%.

One way you could further mitigate this is to store public/private keys in the browser's client-side storage or do some fingerprinting of the client's JS environment and the browser itself. However, this too would be best-effort encryption: if the browser flushes your storage keys you have no choice but to generate new ones. You might be able to ask the client to perform some sort of out-of-band authentication or just use it as a way to verify clients while you are working on regenerating your TLS certs and revoking old ones ....

Improve this answer
2
  • Hi, thanks for your answer. One solution may be to create browser extensions for Firefox and Chrome, containing the JavaScript, so it can't be modified. Another solution would be to develop a common API that all browsers implement to perform client-side public-key encryption for form fields, either over HTTP or HTTPS. Since the certificate authority system is kind of broken anyway, perhaps we should develop another way to verify the identity of the site, outside of SSL certificates. Thus, this system could be used over SSL, or regular HTTP.
    – Jay Sheth
    Commented Apr 18, 2014 at 14:21
  • @JaySheth Wile I do agree the current cert auth scheme is horribly broken, your proposal would only have helped here if the JS-level encryption happened at a different server. If you are applying the encryption at the same machine, you are screwed. At some point, you should just invest in some hardware security modules. That would move the encryption signing to a place where software bugs couldn't expose the keys.
    – Indolering
    Commented Apr 23, 2014 at 23:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .