W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2012

Re: Another use case: validating documents received

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 6 Jun 2012 11:55:44 -0700
Message-ID: <CACvaWvY+hmAYPZrVSqXaDVY_rky3sgupnhRttyQd+Jjhg82wNQ@mail.gmail.com>
To: Philip Gladstone <pgladsto@cisco.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Wed, Jun 6, 2012 at 11:21 AM, Philip Gladstone <pgladsto@cisco.com>wrote:

>  As part of another activity, the requirement came up to allow the
> javascript in a browser to validate the whether an HTML document that had
> been received was actually the original document sent by the web server or
> whether it had been modified in transit (e.g. by some 'helpful' party that
> was doing ad insertion). Note that retreiving the document over TLS doesn't
> provide that guarantee due to the presence of TLS proxies.
> It isn't quite clear to me how to solve this problem, but it seems like a
> useful use case.
> Philip
> --
> Philip Gladstone
> Distinguished Engineer
> Product Developmentpgladstone@cisco.com
> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
> Google: +1 978 800 1010
> Ham radio: N1DQ
>  Could you share a bit about what you expect to be able to prevent by
doing this in JavaScript?

In the presence of TLS proxies, effectively all assumptions about the
browser security model go out the window. As such, any JavaScript that
executes within that model would have to be suspect/unreliable, and thus
incapable of making any rational security decisions.

More fundamentally, the question seems to be "How do we prevent TLS proxies
from modifying content," to which the answer is "Mutually authenticate the
TLS channel," which provides guarantees for the server (eg: TLS client auth
and/or tls-unique channel bindings + some form of HTTP auth), or strongly
authenticate at the client (eg: certificate pinning), preventing arbitrary
roots from creating 'hostile' certificate chains that permit MITM.

It seems more of a transport layer question than one of application layer.

Received on Wednesday, 6 June 2012 18:56:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC