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