On Wed, Jun 1, 2016 at 3:39 PM, John Nagle <[email protected]> wrote:
> >> 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. That might be a general impression among the community, but there are people working on it. There is a "channel binding" standard that generates a keypair that is bound to a particular TLS session [1], and this made it into U2F: https://fidoalliance.org/fido-technotes-channel-binding-and-fido/ Which means that the U2F token can include its "view" (the fingerprint of the TLS session key seen by the client) of the TLS session in the package it signs and sends up to the server. If the server's TLS session has a different fingerprint, then it follows that there's an intermediary session in the middle. The "token binding" working group referenced there is where effort is being directed now: https://datatracker.ietf.org/wg/tokbind/documents/ Not saying it fully meets your goals, just pointing out that there is active work on this issue, and that versions of this work have been deployed in production via U2F. > I'm posting this because CA problems such as the Symantec/Blue Coat > cert are becoming more common. As discussed on another thread on this mailing list[2], the Symantec / Blue Coat cert wasn't a CA problem. It was disclosed by Symantec, included in their audits, and Symantec's possession of the key didn't give Blue Coat powers to generate certificates for domains not under their control. -- Eric [1] https://tools.ietf.org/html/rfc5929 [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/akOzSAMLf_k/Y1D4-RXoAwAJ > > John Nagle > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
