I'm a bit late to the party, but here is a variant that works with
dynamic pages and is backwards compatible, even without HTTP2 or other
persistent connections:
1. In the HTTP response headers, the server sends a new extra header
whose value is
Base64(TLS-session-mac-algorithm-mac(lcase(url)|Base64(random258-bit
value),
fixed-key-derivation-function(current-session-binding-token-string or
master secret
depending-on-tls-version). This must be sent by the server less than 5
seconds after the applicable GET request, even if later parts of the
HTTP header have not yet been computed (for example, it can be sent
before the Content-Length has been computed.
2. If the HTTP response uses an unspecified length (chunked encoding),
a trailer "header field" is added that holds Base64(random258-bit
value) as its value.
3. If the HTTP response uses a specified length (and thus cannot supply
a HTTP trailer), the sequence "MITM_DETECT_MAGIC_STRING"|
Base64(random258-bit value)|"MITM_DETECT_MAGIC_STRING" must occur
anywhere within the last 1024 bytes of the response (with the last such
pattern being the one that counts). This can be done invisibly to
humans for many file formats, including HTML, XML, PNG etc.
In most cases the server would also delay transmission of the tail
holding the random value while relying on the rendering engine being
able to complete the entity display without this last bit of data.
The trick here is that the random value cannot be predicted by the
MITM, yet the server can generate it trivially without knowing the
dynamic page elements. Also the HTML compatibility rules make the page
show normally in browsers that don't look for the MITM detection data.
Keeping around 33 bytes of random data or a 43 character string during
generation of each page is also a low and affordable server runtime
cost, as is the transmission of less than 150 extra bytes per page (43
char hash, 43 char random value, two HTML headers or 1 HTML header + 2
magic strings + tags to hide magic string).
Another trick is that this work can be done in a web server or SSL
accelerator rather than in a page generator such as PHP, which would
generally not be trusted to access the TLS secrets of the session and
might not return their first byte of output during the first 5
seconds. Similarly, the checking can be done in the HTTP(S) client
code which is less exposed to scripting based attacks than the
rendering engine and other DOM parts of the browser.
Final limitation is that the browser needs to know out-of-band the
absence of MITM detection headers is normal or a sign of an MITM
removing those headers.
On 31/05/2016 14:18, Richard Z wrote:
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
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
