+1 It is also worth pointing out that the MITM certs stopped being offered commercially as soon as it became public knowledge that they had been.
Presumably the next step the companies providing this facility will take is to offer their own browser with the capability built in. It is no good jumping up and down saying people should not make such devices. The choice we have is whether to do the job right or let them do it without any input. What I find wrong with the MITM proxies is that they offer a completely transparent mechanism. The user is not notified that they are being logged. I think that is a broken approach because the whole point of accountability controls is that people behave differently when they know they are being watched. I don't mean just changing the color of the address bar either. I would want to see something like the following: 0) The intercept capability is turned on in the browser, this would be done using a separate tool and lock the browser to a specific intercept cert root. 1) User attempts to connect to https://www.example.com 2) Browser throws up splash screen for 5secs stating 'Your connection has been intercepted' 3) Business as usual. The splash screen would appear once per session with a new host and reset periodically. It should show the interception cert being used as well. On Mon, Feb 13, 2012 at 1:21 PM, David Conrad <[email protected]> wrote: > On Feb 13, 2012, at 8:36 AM, Martin Rex wrote: >> The fact that there are products (client-side HTTPS proxies that >> perform MITM and inspect content) actively sold and used, >> which are vitally dependent on being able to exploit weaknesses >> of the existing TLS X.509 PKI security&trust model, is a sure proof >> that something is wrong with the existing security model. > > Well, it is proof that the theoretical model in which authorized MITM was > disallowed was seen as too limiting. > >> I do not think there is value in maintaining backward compatible >> weaknesses, and personally, I do not mind the slightest about breaking >> those protocol subverting middle boxes, be it by the use of TLS channel >> bindings, or the checking of DANE TLSA records. > > Pragmatically speaking, if you come up with an architecture that disallows > people from doing what they want/need to do, they'll either figure out ways > around it or not use that architecture. > > Regards, > -drc > > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
