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.
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.
Faking the page is a lot of work, especially if it's customized. A
cache won't be enough. Users will notice if they get a generic page
instead of their personal social network page.
This would be a good feature to add to HTTP2, because it has one
persistent connection which, once validated, is good for many pages.
With HTTP2, you could have one validation stream with delays
running in parallel with other streams.
Nobody seems to be doing enough with in-band MITM detection. There's
[1], but that requires "previously established user authentication
credentials." Facebook has a scheme which relies on MITM attackers not
knowing how to MITM Flash content.[2] That's a form of security through
obscurity, but it does detect most attacks at the proxy and hostile WiFi
level.
Should Mozilla be active in this area?
John Nagle
[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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
