Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question

migrated from crypto.stackexchange.com Apr 17 at 17:59

This question came from our site for software developers, mathematicians and others interested in cryptography.

2 Answers 2

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.

share|improve this answer
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 Apr 18 at 14:20
@jaysheth It would sound like you were probably safe then. –  mikeazo Apr 18 at 14:28

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 ....

share|improve this answer
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 Apr 18 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 Apr 23 at 23:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.