- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 6 Jun 2012 11:55:44 -0700
- To: Philip Gladstone <pgladsto@cisco.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CACvaWvY+hmAYPZrVSqXaDVY_rky3sgupnhRttyQd+Jjhg82wNQ@mail.gmail.com>
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. Ryan
Received on Wednesday, 6 June 2012 18:56:21 UTC