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 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. First off, the whole point of the SEC regulations is that traders etc. should know that they are being watched. So they should not be using a regular client anyway. They should be using a client that regularly tells them that their connections are being intercepted. I would think this is also advisable from a liability, privacy and ethical point of view. Second, anyone who demands a cert that allows them to intercept any SSL session is being an idiot and putting themselves at great personal risk. There are people who are prepared to do a very great deal to get such a cert. I believe in separation of duties for my own personal protection. 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. On Thu, Feb 9, 2012 at 10:34 AM, Nico Williams <[email protected]> wrote: > On Thu, Feb 9, 2012 at 7:16 AM, Phillip Hallam-Baker <[email protected]> wrote: >> Agreed, but! > > No but, we agree on the rest regarding e-mail as well, and some of > what you say is a restatement of what I said. You go further and note > that the very fact that PGP and such public keys and capabilities are > divorced from the MUAs is the problem -- something I hadn't noticed > last night, but I agree. > >> Let us drop the end to end ideology in the dustbin and accept that >> email is an MTA to MTA protocol, or to be more precise it is three >> protocols: > > I'm happy to drop the end-to-end principle where it can't be applied. > E-mail is mostly such a case (I say mostly because for a very, very > small group of people PGP has worked well enough). > >> So now we see why security policy driven by MUA published security >> policy is going to fail: there is no consistency in the MUA loop. I > > Indeed. There's no way to ensure that all your MUAs have the same > capabilities. I regularly use four different MUAs myself. > >> read mail on four separate devices. They have no way to communicate >> between themselves to negotiate a common security policy and I >> certainly would not want them to. >> >> Conclusion: >> >> 1) Security policy is a property of MTAs and not MUAs and hence of >> domains and not accounts. >> >> 2) We need a security policy layer for the internet as a whole and not >> just for what people imagine to be the 'Web' or 'email' portions >> thereof. This is a problem caused by stovepipe thinking and >> non-my-problemism. > > Perhaps you're not communicating your vision of (2) very well. I'm > not entirely sure what you mean, and I'm dubious of any > one-size-fits-the-Internet scheme (if that's what you have in mind). > >> [...] >> Add the capability for MTAs to publish policy and we can establish a >> hop-by hop security mechanism that covers each of the three mail >> interactions in three separate end-to-end sessions. > > Right. This is a case where hop-by-hop security is the best we can do. > >> Getting back to the bigger problem, no this is not solving all the >> problems we are seeing in the Web space. But it is solving a pretty >> big one there. Web security is harder to improve than email security >> because we already have quite a bit of Web security and very little >> email security. > > I agree with this as well. > > The web also has lots of end-to-end-ness, though HTTP doesn't require > it, and, indeed, encourages middle boxes. And we also use the web for > different purposes than e-mail. I don't think the hop-by-hop security > argument applies quite as well to the web... For the web we really > want end-to-end security (with the server's concentrator being thought > of as part of the server). I'm open to arguments to the contrary. > Perhaps you'd suggest hop-by-hop security where the hops are > client<->ISP<->server? > > Nico > -- -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
