> 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
