Re: Another use case: validating documents received

Indeed there will be a cat-and-mouse game between the implementation of 
the tls proxy and the people doing the detection. This is true 
throughout the malware world.

Your bank might like to be able to verify that the data as delivered is 
the data as sent. Yes, the TLS proxy might change the JS to eliminate 
the checks, but that is a very difficult problem and very unscalable for 
the operators of TLS proxies.

Philip

On 6/6/2012 2:55 PM, Ryan Sleevi wrote:
>
> On Wed, Jun 6, 2012 at 11:21 AM, Philip Gladstone <pgladsto@cisco.com 
> <mailto: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 Development
>     pgladstone@cisco.com  <mailto:pgladstone@cisco.com>
>     Phone: +1 978-ZEN-TOAD(+1 978 936 8623  <tel:%28%2B1%20978%20936%208623>)
>     Google:+1 978 800 1010  <tel:%2B1%20978%20800%201010>
>     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

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ