[ NNSquad ] Re: [ PRIVACY ] Would You Know if Your ISP Tampered With Your Web Pages?

[jbartas <jbartas@speakeasy.net>]

There might be an easy way around this overhead - put the key in the 
referring page's html link, something like this:

<img src="http://adageny.com/advert.gif";
  digest="936760478239847958923761398095683"
  key="9878" >

The key, along with the coming "advert.gif" stream, would be used by the 
browser's plug-in to calculate the digest. If it doesn't match the 
digest in the original link, the received stream is suspect. It would be 
up to the third party site (in this case adageny.com)  to provide the 
correct key & sum to the hosting site beforehand.

This would not help with web pages that are hand typed into the location 
bar, but I think those are a minority these days.

BTW, a browser feature that supports this would have to have the ability 
to allow user-defined pages to replace certain obnoxious content. I 
would not use a tool that set off an alarm every time my ad blocker 
kicked in. Also think about schools and businesses that are required by 
law to block sexual content. A predefined "sexual content blocked" page 
would have to be allowed to replace a picture without setting off  an 
alarm.


-JB-

Nick Weaver wrote:
> A "Content-MD5" header won't help at all, you need a
> "Content-Public-Key-Signature".  A digest (well, SHA512 digest, MD5 is
> broken) is insufficient, as it doesn't provide any verification that
> the checksum itself hasn't been tampered with.
>
> The problem is, this would cost considerably more on server-side
> computation than SSL-everywhere, as SSL only has the public key
> exchange during connection setup, but the signature requirement would
> apply to every element separately.  However, it wouldn't have the
> session initiation latency that SSL has.  You will still need the
> certificate change as well, otherwise you can get MITM just as you are
> on the unsigned pages.
>
> What is really required is Auth-TCP/TLS, where the key exchange
> material  is included in the Syn & SYN-ACK (so no extra RTT in
> connection setup, as this is also a huge cost of SSL/TLS), and which
> is used to create message integrity on subsequent TCP packets, but
> which defers any computation on the server side until the 3-way
> handshake completes (a'la SYN-cookies).
>
> Developing the standard is left as an exercise to the reader (and
> might prove hard in practice).
>
>
>   


--
John Bartas - Director of Network Engineering
Packet Island, Inc. www.packetisland.com
jbartas@packetisland.com
cell: 408-857-0605