Re: SSL/TLS everywhere fail

The point (1) is built on whatever TLS certificate system we settled down on so whatever improvement made there propagates here automatically.

The point (2) comes with the intention of sparking a cat-and-mouse game. The verification script can perform some kind of phone-home or whatnot, maybe loading part of the page pre-verification and some post-verification - the authors of legitimate websites together frustrate the potential MITM attackers by the sheer amount of ways of verification that can be done. Unless MITM attackers form alliances not unlike those antivirus companies they can have some difficulty in blocking all kinds of verifications, but such alliances can be easy to tell.

About whole-page replacements those are not even preventable theoretically. For example I don’t want anything within my network contact any server within a certain domain, I just set up my local firewall to redirect any address to that domain to blackhole.in.maxchan.info and serve a warning page instead.

> On Dec 7, 2015, at 18:31, Cory Benfield <cory@lukasa.co.uk> wrote:
> 
> Well, PHK will object to (1) because he rejects the CA system as both politically and technically flawed. Further, (1) is, if implemented incautiously, open to the same kind of MITM attack that TLS is. You need a way to restrict certificates that can sign content for a specific origin. We've attempted to solve this (or at least improve the situation) for TLS: similar approaches would need to be taken here. 
> 
> For (2), I admit to not fully understanding what you're suggesting. However, my guess is that you're essentially saying that we'd punt by doing the validation in JavaScript, client-side, relying on the browser-side JS to validate the signature. That is of course open to the exact same attack as sending the cert in the HTTP: a MITM can replace the JS with one that would validate the content. 
> 
> The attack to worry about is: what if the attacker replaces the body *in its entirety*, headers and all? How do we protect against that? GPG does this by transmitting keys out of band using manual verification. TLS does this using the CA system, which has been further enhanced by HPKP and Certificate Transparency. How would we do this for the body content?
> 
> So far, I think (1) is workable, if subtle. However, I doubt PHK will go for it. 
> 
> Cory
> 
>> On 7 Dec 2015, at 10:15, Maxthon Chan <xcvista@me.com> wrote:
>> 
>> 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
>>> 
>>> 
>>