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

[Kevin McArthur <kevin@stormtide.ca>]

I partially disagree. At least in my legal climate content modification 
is illegal. ISPs are trying to split hairs that content concatenation is 
not modification (i think we can all agree that it is, but the law 
doesn't recognize HTML and they've been concatenating "This is a long 
distance call" type recordings on phone calls for a long time). 
Content-MD5 would eliminate this argument as they would have to modify 
the MD5 and change the purpose of that communication. IIRC there are 
also similar forgery/impersonation type laws in the US.

As for server-side computation... I don't see this as being the adverse 
item to SSL everywhere. The lack of name-based virtual hosting (the IP 
requirement for SSL) as well as the commercialized element of trust 
providers means that there is significantly more real-world cost to 
deploy SSL. Unless you can solve those two issues, you likely wont 
increase SSL adoption much.

K

[ While I personally feel that the copyright argument against ISP
 modification/concatenation of user data streams could be a sound one (given
 a plaintiff with sufficient resources and stamina), until this sort of
 situation works its way through courts we don't really know what will
 happen.

 The "this is a long distance call" announcement analogy doesn't really fit.
 That would really be much more similar to an ISP putting a message in a
 splash screen that appears first, *separate* from the actual page contents.
 While I would also find this sort of behavior objectionable in other than
 very limited and specialized situations -- e.g., public hotspots, etc. -- it
 would probably be less likely to be viewed as a copyright violation.  Think
 of it this way -- a preamble phone announcement plays and is finished, then
 the rest of the conversation typically continues uninterrupted (these days
 at least, though with pay phones years ago it was a different story).
 Similarly, a splash screen appears and is then gone -- considerably
 different from grabbing screen real estate from the actual user content
 being provided by the service with which the user is interacting.

 There are at least two approaches to handling virtual servers under SSL/TLS
 that have been described in RFCs, though widespread implementation is a
 different issue.  I mentioned this in the Technical Addendum to:
 http://lauren.vortex.com/archive/000338.html .  Also, some issues
 surrounding the need for certificates (and the role of self-signed certs) to
 enable SSL/TLS are discussed in:
 http://lauren.vortex.com/archive/000339.html .

    -- Lauren Weinstein
       NNSquad Moderator ]
    

- - -


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).
>