Re: SSL/TLS everywhere fail

A possible way:

1) The signature is done using the website’s normal SSL certificate (this can be transmitted in plain, just like when establishing TLS security)
2) The state of signature verification status as well as the signing certificate can be read in DOM so every website can check it in their own way later, even phone home when a fake certificate is encountered. The same can also apply for TLS trust status and certificate.

Now this, especially DOM access to actual certificate, can spark a cat-and-mouse game between MITM attacker and genuine site owner.

> On Dec 7, 2015, at 16:31, Cory Benfield <cory@lukasa.co.uk> wrote:
> 
> 
>> On 6 Dec 2015, at 17:32, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>> 
>> The biggest current protocol deficiency is that HTTP offers no means
>> to check integrity.
>> 
>> That could be done with a simple HTTP header and a thumbs-up icon
>> in the address-bar, and it wouldn't cost TLS startup overhead and
>> wouldn't impact the cachebility of the high volume traffic.
>> 
>> To the extent people paid attention to the thumb-up icon[2] it would
>> instantly prevent ad-injection, make a very large swath of simple
>> criminal activity impossible, and expose complex criminal activity
>> to a new range of legal risks (forging documents etc.)
>> 
>> Such calibrated measures, no matter their good cost/benefit, are
>> of course incompatible with the IETF's "all-out-war" attitude which
>> Stephen detailed in his email:  Integrity is routinely, as you just
>> did above, taken hostage for the "TLS everywhere" agenda.
> 
> Would you like to elaborate on how this would be done? Hashing the body content? Because an attacker can rewrite the header as well. Hashing the headers? Well, again, the attacker can rewrite those and recompute a hash on the entire thing. Signing the body? How does the client obtain the public key they use to verify the signature?
> 
> I ask these questions only because you used the word “simple”. The header itself (as in, the bytes on the wire) may be simple, but the technological underpinnings of this approach are *not* simple, at least as far as I can see. The best we have right now is a current I-D that aims to address exactly this, draft-thomson-http-content-signature[0], and that draft suffers from the absurd flaw that the signing public key is transmitted in unauthenticated cleartext right alongside the signature itself. The draft does save itself by allowing the key to be provisioned by other means, but omits to suggest what that would be.
> 
> As you have correctly identified in the past, Poul-Henning, establishing trust for crypto keys is tricky. You have objected to the CA system in what I would call “strong” language. Fine. Tell me how you want to do it for integrity checking of HTTP messages.
> 
> I am desperate for a good body-encryption draft, and I am desperate for a good integrity draft. You suggested in the above text that such a thing would be straightforward to build (*not* easy, straightforward). Good! Tell me how it should work, and I’ll even write the I-D for you, out of respect to your time constraints. I’d love to see this exist.
> 
> Cory
> 
> [0]: https://tools.ietf.org/html/draft-thomson-http-content-signature-00
> 
>