5 ms·

I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down. But, that said, I have seen the

I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down. But, that said, I have seen the following problem several times, and it seems like client-side crypto provided a reasonable solution. Challenge: I have a client (web browser) and I have a back-end server (sitting deep behind several layers of intermediate servers of varying degrees of trust) and these two entities need to exchange some sensitive piece of information (a credit card number, etc). How do I transmit this information (either from client to server or the reverse)? Problems/Assumptions: Let's assume I trust the front end server explicitly to serve fully server-controlled data. Obviously, if we don't trust the server serving me the JS it is all for not. Now, let us also assume that, although my front end server is trusted, it, as well as all of the intermediate servers may accidentally log data that flows through them. In other words, we assume that if I pass a plaintext credit card number over a trusted SSL connection to the server, it, or any of the intermediate servers on the path to the trusted back end server, may accidentally log the sensitive data. How do you solve that problem? Solution: You could use client-side crypto to create an end-to-end channel that transmits the sensitive data to the back end server. So, yes, the above solution assumes a fully trusted front end server. In this case, the client side crypto is more to protect the service provider than for the user, but it does seem to provide some sort of "existence proof" in so far as it is a problem that exists in the real world, is made better using client-side crypto, and doesn't seem to have many alternative solutions that provides the same assurances. P.S. This is more or less what BrainTree does with their client-side encryption for credit card processing (https://www.braintreepayments.com/braintrust/client-side-encryption https://www.braintreepayments.com/braintrust/client-side-enc...). In this case, the front end server needs to be trusted, as it is serving up the public key to bootstrap the whole system. But, if we assume the server is trusted (even without client-side crypto we have to assume this for any security) then this approach mitigates the problem of logging credit card data by accident. Now, maybe this use case is the only legit use of client-side crypto. But, it does make me take pause before dismissing the approach entirely.

dsl 13y ago
> I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down I think you are unfairly reframing it as some sort of debate. It's like not being totally decided on if you should log into your server over telnet from a coffee shop. Even if you don't see the weakness, attackers do.
- ptoomey3 13y ago
  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.
  - 13y ago

dsl 13y ago

> I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down I think you are unfairly reframing it as some sort of debate. It's like not being totally decided on if you should log into your server over telnet from a coffee shop. Even if you don't see the weakness, attackers do.

ptoomey3 13y ago
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.
- 13y ago