Re: Yet another trusted proxy suggestion

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

Stated more generally, by integrating some TLS logic into the HTTP layer,
we can guarantee message integrity and auth and so prevent MITM proxies
from operating in stealth mode.




On Thu, Nov 28, 2013 at 12:55 PM, Christian Huitema <huitema@huitema.net>wrote:

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