3 ms·

I didn't mean to imply a debate...only that the reductionist viewpoint "it is only as secure as SSL, so just use SSL" doesn't quite sit right with me; the probl

I didn't mean to imply a debate...only that the reductionist viewpoint "it is only as secure as SSL, so just use SSL" doesn't quite sit right with me; the problem feels a bit more grey. In the particular scenario I proposed the only attacker we are trying to protect against is a completely passive attacker than can possibly view our logs from servers along the path to our back end server. Obviously in the world of crypto that is a ridiculously weak adversary, and not one you want to hang your hat on when designing a crypto system. But, it is an adversary that plenty of companies are concerned with. For example, because sensitive data is not something you can "unsee", it would be ideal if one could ensure that even trusted employees are never witness to the information. For example, I could be a completely trusted employee that sees an accidentally logged credit card. The bell has been rung..there is no going back. In that situation, even though there is no adversary in the malicious stance, it is a problem that can occur and many people would like to solve it.

IgorPartola 13y ago
Security is reductionist. Once your system is broken it doesn't matter how or where, it just is. If you need SSL, you must use it. You cannot hack around it, since the attacker will simply MITM you without it, or find a side channel to load the malicious code and then use one of the dozens of flexibilities in the JS runtime to get your sensitive info. The opposite is also true: if your SSL setup is compromised (e.g. Leaked private key), client side crypto does nothing to protect you since the attacker can just MITM your crypto code inside the runtime, get data out of the DOM, etc. There are no cases left where client side crypto provides any additional security. Some future server-browser model might change that, but not anything that exists on the web currently.
zentrus 13y ago
I for one agree with you. There are a few specific cases where client-side crypto has benefits regardless of the fact that you need to (at some point) trust the server. I think the best examples involve protecting history or data residing on the server up to the point of being compromised. See my other comment on here for my use case.

IgorPartola 13y ago

Security is reductionist. Once your system is broken it doesn't matter how or where, it just is. If you need SSL, you must use it. You cannot hack around it, since the attacker will simply MITM you without it, or find a side channel to load the malicious code and then use one of the dozens of flexibilities in the JS runtime to get your sensitive info. The opposite is also true: if your SSL setup is compromised (e.g. Leaked private key), client side crypto does nothing to protect you since the attacker can just MITM your crypto code inside the runtime, get data out of the DOM, etc. There are no cases left where client side crypto provides any additional security. Some future server-browser model might change that, but not anything that exists on the web currently.

zentrus 13y ago

I for one agree with you. There are a few specific cases where client-side crypto has benefits regardless of the fact that you need to (at some point) trust the server. I think the best examples involve protecting history or data residing on the server up to the point of being compromised. See my other comment on here for my use case.