On Thu, Feb 9, 2012 at 7:49 AM, Phillip Hallam-Baker <[email protected]> wrote:
I agree on the problem of Web middleboxen being a problem. What I really dislike about the BlueCoat solution is that it is transparent. Which is of course why enterprises like them. They can just deploy and forget. The fact that the purpose of the box is to violate core assurances in the Web UI is irrelevant to them. They have a regulatory requirement and will pay someone to achieve that at the least personal effort to them.
I think this can be solved via code. Make it so that name:certificate pairs which pass based on the built-in roots can present blue and green, and certificates which pass based on non-built-in roots show up in gold.
I think we need to address SSL middleboxen properly (and not in this forum, probably in TLS). Like prostitution, there are people who are going to do this somehow, better to allow for it and regulate it properly than have it happening in dark corners. The next logical step is to attack the client with some sort of applet that adds a bogus root into the certstore.
The next logical way to defend against this is to enable it on our terms.
Having an authorized bypass mode would enable the browser providers to provide the appropriate (and really really intrusive) warnings to the user at regular intervals. This is how Ari Luotonen, Rob McCool and co originally conceived SSL intercept back when they did the Netscape proxy.
Why isn't this already part of the browser codes which handle network proxies? -Kyle H
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
