W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

RE: Yet another trusted proxy suggestion

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>
Message-ID: <032801ceec63$050b7f00$0f227d00$@huitema.net>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC