Secure Network Communication using SSL AND JavaScript client-side encryption?

3
votes

we are going to build an application where network security is one of the big issues. The application is provided over the internet (public network), but should transfer sensitive data and sensitive, confidential documents, which should be as secure as possible against possible attacks, e.g. man-in-the-middle.

Of course, the application will be encrypted using SSL. However, SSL has been hacked yet and we do not know if it is secure enough to use SSL only.

So my question is: Is there any benefit for the security of an online application using SSL, if we would encrypt the data before the network transfer with JavaScript ADDITIONALLY (symmetric or asymmetric encryption)?

So the data would be double encrypted, which would it make hard to read for attackers, even if they would manage to hack the SSL-encryption.

Additional Question: Is there a good JavaScript library for encrypting files on the client-side before transferring these over the network?

(Notice: We know the possibility of encrypting AND decrypting the files client-side, so they are not readable on the server (because the client key is unknown). However, there will be files which should be possible for the server to read and should, if useful, be double encrypted anyway, but with different keys per client).

2
securitysslencryption
While there are some attacks against SSL, I think the blanket statement "SSL has been hacked" is false. That being said, this is probably what you want: stackoverflow.com/questions/793812/javascript-aes-encryption – Chris Laplante
Well, thanks for the tip and you are right, the blanket statement "SSL has been hacked" is false. However if you are really paranoid, you also may mistrust your certificate factory, in times of NSA discussions you may be afraid of the security of your online data anyway. – Blackbam
I would recommend articulate several things: against whom are you trying to protect? what are the resources your attacker has? why does the attacker has access to? Only after that it makes sense to decide on technical solutions to protect against an attack. Otherwise you are putting the cart before the horse. – Victor Ronin
Hello, the thing as that the documents to be stored might be very interesting for industrial espionage. So the crackers may be payed by competing companies, but they may also even be interesting for government agencies like the secret service in the worst case. So attackers may have a lot of money and very good tools, and the files are possibly to be stored in kind of a public cloud. So what would you recommend? – Blackbam
If you're concerned there may be a MITM intercepting and altering your SSL/TLS connection, this attacker would also be exactly at the right place to perform a MITM attack on your JS code (assuming they have broken the SSL/TLS layer, as you suggest): they can replace it with whatever they like. Here is a good list of reasons why not use in-browser JS crypto. You're also mentioning applets, but they suffer from the similar problems regarding the code delivery. (I also presume you wouldn't trust their signatures either, if present.) – Bruno

2 Answers

1
votes

For SSL/TLS, depending on how much control you have over your client, you can use certificate pinning, which works fairly well. The basic idea is that instead of hard coding root certificates, you hard code the actual certificate for the server you are connecting to (or one you trust to sign other certificates).

As for a good JavaScript crypto library, try sjcl. There are some potential drawbacks of using JavaScript crypto, especially if you don't trust SSL/TLS (e.g., an attacker can change the crypto library that you are downloading), but I have used sjcl for a while and am happy with it.

If you need more info, please post more information about your threat model, the software, and the assumptions you are making about your client side and server side software.

0
votes

Yes, the additional encryption can provide mitigation against certain very specific attacks because you have complete control over where it begins and ends. SSL terminates at the web server and sometimes earlier (e.g. if your data center is using deep packet inspection or SSL offloading); the additional encryption can protect data in zones where the data are sent in the clear.

That being said, double encryption is NOT common. I work for organizations that are all very high value targets and we don't do that sort of thing.

Whatever you do, don't REPLACE SSL. It gives you more than encryption; it gives you authentication, which is arguably more important.