Re: Another use case: validating documents received

On Wed, Jun 6, 2012 at 12:06 PM, Philip Gladstone <pgladsto@cisco.com>wrote:

>  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
>
>
If the bank, which in this example is the server, wishes to ensure this,
then what they're really wanting to ensure is that no third-party is 'on
the line', potentially modifying things before the client receives them.
This is exactly the problem mutual authentication is meant to solve.
Traditional, anonymous TLS only provides guarantees to the client - if the
server wants guarantees, it should request auth. Again, that goes more to a
transport layer problem, not one that I think can/should be attempted at
the application layer. If you're not going to require it at the TLS client
layer, at least using TLS-unique channel bindings at the HTTP auth layer
provides a strong binding to the channel that the TLS proxy cannot MITM
without also possessing whatever client credentials are necessary.

To the extent that it's a problem addressable by this WG and in scope of
the charter, I think these use cases are addressed within the 'secondary
API features,' specifically control of TLS session login/logout and
derivation of keys from TLS sessions. Both of these can improve the
behaviour of mutual auth as seen from JS, but I think your problem is more
fundamental.

If the user's session can be MITM'd by the bank, then the MITM will just
sent hostile JS to disable/lie/circumvent the browser's mechanisms. Your
presumption is that the mechanisms for injecting some content (eg: ad
insertion) is already implemented and deployed, so why not just deploy JS
instead?

However, I don't think the concept of hashing the page and reporting the
contents are really a good fit. See for example this thread -
http://lists.w3.org/Archives/Public/public-identity/2012Feb/0011.html in
the precursor to this WG.


>
> On 6/6/2012 2:55 PM, Ryan Sleevi wrote:
>
>
> 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
>
>
> --
> 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
>
>