We had a conversation about this at a Boston IETF meetup last year; the consensus, with which I agree, is that simply adding TLS alerts isn't good enough, for (essentially) the reason you stated earlier: we have no way to know that the attacker here is a good guy. E.g., in the case of the OpenDNS behavior being described here, we don't know if OpenDNS is protecting us or attacking us.
A solution to this problem would require that there be a way for the MITM to signal that in this particular case, the connection is being blocked, and to sign that assertion with a cert that the application is configured to trust. This establishes a trust relationship with the protecting party (the operator of the OpenDNS server) that the user can agree to or refuse to agree to, and if the UI is done well, the user can be reminded that this intercept is the result of them agreeing previously to such intercepts. This avoids presenting the user with something to click through, but also provides a way to attribute the intercept to a specific, authorized entity, so that if that entity decides to censor something I didn't agree to have censored, there's a way for the service provider to help me to understand why I can't access their service. I'm responding in detail here because I want to make it clear that I am no longer a proponent of the original proposal, not because I'm specifically advocating what I describe above. Another way to deal with this problem is to simply not provide the "bad cert" popup in the first place—that's a very bad UI design, and I've noticed that modern browsers are starting to abandon it (yay). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
