On Mon, May 30, 2016 at 12:44:05PM -0700, John Nagle wrote: > We need general, automatic MITM detection in HTTP. > > It's quite possible. An MITM attack has a basic quality that makes it > detectable - each end is seeing different crypto bits for the same > plaintext. All they have to do is compare notes. > > There are out-of-band ways to do this, such as certificate pinning and > certificate repositories. But these haven't achieved much traction. > > Doing it in-band is difficult, but possible. An early system, for one of the > Secure Telephone Units (STU), displayed a 2-digit number to the user at each > end, based on the crypto bits. The users were supposed to compare these > numbers by voice, and if they matched, they were probably not having a MITM > attack. An MITM attacker would need to fake the voices of the participants > to break that.
VoIP/ZRTP does something very similar. > This is the insight that makes MITM detection possible. You can force the > MITM to have to tell a lie to convince the endpoints. More than that, if > you work at it, you can force the MITM to have to tell an *arbitrarily > complex* lie. You can even force the MITM to have to tell a lie about the > future traffic on the connection. That means they have to take over the > entire conversation and fake the other end. > > As an example, suppose a server sending a page sends, at the beginning of > the page, a hash value which is based on the contents of the page about to > be sent, and also based on the first 64 bytes of the crypto bits of the > connection. The browser checks this. The MITM attacker now has a problem. > If the attacker didn't know about this, the MITM attack immediately sounds > an alarm at the browser. If the attacker does know about this, they can > compute their own hash. But they haven't seen the content the hash covers, > because the page hasn't been transmitted yet. > > So the attacker either has to buffer up the entire page before they can send > any of it, or fake the page based on some source like a cache. Buffering up > the entire page adds delay. The server can add to that delay by deliberately > stalling for some seconds before sending the last few bytes of the page. If > the MITM attack adds 10 seconds before every page begins to load, it's > obvious what's happening. The browser could even check this; if the first > byte of the page doesn't appear within N seconds, don't display it. clever, although in practice I think many pages dont take 10s to load and thus many times the caching delay attack could work. Also many servers don't have full advance control what they will send to the user - on the fly generated content is just as unpredictable for them as it is for a potenital attacker. There are otf delivered ads, tag clouds, social buttons... But if you would go ahead with that - could it be done so that the hash is cryptografically signed and can be "saved" together with the page? This would improve on another major shortcommings of TLS - that the user can never prove he received some content from say his online bank. > Nobody seems to be doing enough with in-band MITM detection. There's [1], > but that requires "previously established user authentication credentials." seems fair for situations where demands on security are very high. Imho OpenPGP has some very strong points and I would love to see PGP over http. With manual out of band verification it is much more secure than relying on the integrity of the 200+ TLS CAs, while for the lower-risk situations key-ring signing may be a good alternative. Also, with PGP even if a MITM attack would succeed temporarilly there is a much better chance to prove anytime later that the attack happened which may make certain attack scenarios less interesting. > > [1] http://www.cc.gatech.edu/~traynor/papers/dacosta-esorics12.pdf > [2] > http://www.scmagazine.com/researchers-detect-ssl-mitm-attacks-method-implemented-by-facebook/article/346994/ > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy Richard -- Name and OpenPGP keys available from pgp key servers _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
