- From: Christian Huitema <huitema@huitema.net>
- Date: Thu, 28 Nov 2013 09:55:24 -0800
- To: "'Yoav Nir'" <synp71@live.com>, "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>, "'HTTP Group'" <ietf-http-wg@w3.org>
Yoav wrote: > * Deploy client certificates for users. This defeats all TLS proxies, > unless you come up with a proxy that somehow gets the user's private > key. It doesn't get any more "trusted" than that. Very few banks do > this. There is an alternative, "detect that TLS security has been compromised, and switch to end-to-end methods." Suppose that we somehow got a new JavaScript API that allowed access to some of the TLS data, say looking at the server certificate that was used in the connection, or maybe computing a secure hash of an input string with the TLS session key. There are many instances in which HTTP connections carries data that is derived from of “shared secret” between client and server. The obvious example is the user’s password, but there are other examples. A CAPTCHA, for example, is effectively a temporary secret between client and server, because an attacker will need some time to crack it. Validation pictures used by banks are also a form of shared secret. The low tech password verification hash a challenge provided by the server with the password provided by the client to produce a challenge response. Suppose we also hash the TLS session key into the response. The server can now verify the session key is the same at both ends. If it is not, then the MITM attack is detected. We can do the same with the response to a CAPTCHA. Instead of sending the response in the clear, hash it with the session key. Or maybe produce two hashes, one with a nonce and another with nonce and session key. Again, if the server cannot verify the result, the MITM is detected. Something similar could be done for verification images. Instead of looking for the image by some image identifier, the client looks for the hash of the image identifier and the session key. If this is not the expected value, the server returns a “you are being spied upon” image. Based on that, the server can decide whether to continue the connection, to tell the customer to switch to a new Internet service, or maybe to use some form of end-to-end encryption for at least some of the data. -- Christian Huitema
Received on Thursday, 28 November 2013 17:56:21 UTC