| It's an interesting idea but not without some issues. Essentially you are proposing a mechanism for in-band-data-over-TLS to determine if the end-to-end encryption has been compromised, correct? (I'm deliberately avoiding the term MITM as I think it carries extra baggage that is distracting for now.) I think having a "preamble code" (for lack of a better term?) as mentioned could be difficult for sites that are heavy on the dynamic content--they'd have to buffer up the final page then hash it anyway. If the server can do it, so could any MITM appliance. I think a "postamble code" is the way to go. Also, any detection method that relies on timing would have to be a non-starter almost out of necessity. Propagation of data throughout the internet is wacky enough that it would be extremely difficult to get down a timing model that works in all cases. I also took a look at the ref [1] you provided. An interesting idea as well, though wildly impractical. I can't imagine that any of the top 1000 sites on the internet could even implement such a thing because they tend to have pages that pull in data from far flung corners of the world. I don't think any but the most trivial sites would ever work. I also have a problem with the salted password that is mentioned. I don't think it's as secure as would be wanted. So the key to making something like this work is to figure out the algorithm for producing "the code" to use. Obviously it has to incorporate knowledge of the TLS data but then what else can be used in a secure manner? The password idea from [1] is clever, but if we realize it won't work what is a good alternative? I hope you don't feel I'm trying to discourage more thought on this. My intention is only to offer a way to look at this that might help focus additional work and conversation.
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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
