On 06/01/2016 12:18 PM, Peter Kurrasch wrote:
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 suggesting that it's time to look for one. I'm not recommending
what I proposed; that's just a proof of concept.
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.
If you do this entirely as a postamble, an attacker can also do it
without increasing delays. They just copy the page as it is
transmitted, then replace the postamble. The idea is to force the
attacker to hash data it hasn't seen yet, or fake data that it can hash.
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.
That's partly why I was thinking HTTP2. It might be possible to
authenticate the HTTP2 connection, which contains multiple streams,
in parallel with other data transfer. A nice browser feature would
be to inhibit input to password fields and cookie responses until
authentication is complete.
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.
I'm not recommending that; I just wanted to properly cite other
work on the problem.
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?
There are at least three approaches that can work:
- A prior shared secret. The password-based approach mentioned and
certificate pinning are in this category.
- Some separate data channel that is not compromised in
real time by the same party compromising the main channel.
The Facebook trick with a Flash-based channel is one such.
That's vulnerable once the attacker knows about it.
- Timing constraints that force the attacker to try to predict
future content. That's what I discussed.
What I want to do is to get people thinking about this as a
solveable problem. There's a general impression that MITM attacks are
fundamentally not detectable. But that's not actually the case.
It's hard, but not impossible. The key concept here is that an
MITM attacker can be forced to to jump through hoops to make the
attack work, and it may be possible to make those hoops so hard to
jump through that it can't be done.
I'm posting this because CA problems such as the Symantec/Blue Coat
cert are becoming more common. Blocking those when found is like
signature-based virus detection - it protects only against old attacks.
A better technical solution is needed.
John Nagle
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
