On Tue, November 19, 2013 3:36 pm, Yoav Nir wrote: > > Hm. Interesting predicament. Two thoughts: > > > > If the goal is to allow clients to note and obey the 'strict' directive > > even in the face of a SSL Interception proxy... what you propose won't > > work. The proxies will be built to just remove the strict directive, or > > the header all together. > > > > If the organization running the proxy wanted to block access to the site > > in question, they would do so. If they want to monitor ongoing access, > > they will strip the directive/header so the clients continue to connect. > > If they are ambivalent - 'access it or not, we don't care, but must > > monitor you if you do' - the stripping feature may or may not be > > enabled. > > > > What you propose would only help in the latter case, it will not > > actually provide more security if the website considers the proxy to be > > an adversary. And if they add the strict header, I would imagine that > > the website does consider them to be an adversary, or at least that they > > do not wish the connection to succeed.. > > I agree that it does not help security, but it increases the chances of > the server policy being enforced. This is not far-fetched. Most TLS > proxies are next-generation firewalls or caching proxies. They won't > remove the strict directive. Of course, snooping proxies will act > differently. > > > So I don't think what you propose is worthwhile, specifically because it > > does add risk via sites bricking themselves, while not improving > > security considerably. > > > > > > As far as the laptop moving between home and work... I get the > > impression this situation may be regarded as a 'failure' of the > > protocol. That is, we have unintentionally broke something. I disagree. > > I think the situation has worked as desired. > > It's the other way around. The desktop that remains at the office and > keeps ignoring the strict pins is the failure. > > > Because if we replace the players with a rogue government performing TLS > > MitM, with the specific goal of isolating clients from receiving > > up-to-date security policies... we would declare this same situation a > > success. > > > > I don't see a way to reconcile the two situations, as they behave almost > > exactly the same. > > > > TLS Proxies add a third player into what was previously a (primarily) > > two-party protocol*. I think the strict directive preserves the > > reasonable property that any one of the three parties can choose not to > > participate based on the settings of the protocol. > > - The TLS proxy can block access or choose not to intercept > > - The user can not visit the site > > - The site can declare "I don't want anyone else seeing the data I > > consider to be for the user's eyes only" > > So the benevolent TLS proxy should note the "strict" directive and block > the connection by itself? It makes sense, but that would require an > upgrade of the TLS proxies. Changing client behavior would work with the > proxies that are deployed now. > > > I expect that Firefox and Google may even continue to preload entries in > > their browsers that apply the 'strict' directive specifically to provide > > websites the power to assert their right to a MitM-free connection. I > > know several websites who would like to exercise that right. > > > > What? And have their sites not work in all the places that have newer > firewalls? I doubt it. > > Anyway, I can see how this would allow a buggy proxy to brick the users, > so I now agree that this is not worthwhile. > > Yoav > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec >
Apologies that this discussion has happened due to the editors not having refreshed the draft. As I recall (perhaps incorrectly), our takeaway from IETF 86 was the removal of the 'strict' directive, since the notion of having a remote server provide a directive to override local policy is just escalating a policy arms race. One of the key discussions was had was regarding pinning and how, in current implementations (eg: Chrome), one can only pin to chains that terminate in a 'well-known root'. The 'strict' directive (or its absence) was an attempt to provide some indication that the site accepts being pinned to an internal trust anchor. I recall (and again, perhaps incorrectly), that it was either Eric Rescorla or Jeff Hodges that suggested an implementation change might better accomodate this: 1) If noting pins, and it chains to a well-known trust anchor, local policy (read: potentially MITM enterprise devices) may be able to override 2) If noting pins, and it does not chain to a well-known trust anchor, effectively note the pins with no override capability (eg: the pins exactly as specified) The goal of this was less about enabling MITM proxies (although they're an unfortunate reality and, to at least some, a perceived necessity), and instead finding a way to balance pinning for both "public" sites as well as "internal" sites. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
