Hi Eran, > ... Until everyone deploys TLS, including such non-TLS bits in a TLS > page cause the browser to show a broken TLS state in the address bar. > For most web users, that's more of a red flag (valid TLS but with some > resources loaded without TLS) than no TLS at all.
And in fact, in any modern browser, this situation is rightfully called out as an insecure deployment. Many one of those non-TLS resources you refer to could be modified by an attacker to inject malicious script and therefore hijack sessions. > The reality is that > it is really hard to deploy TLS applications today without having > issues with at least one vendor (especially when that vendor is an ad > network you rely on for your profits). Agreed. It is a typical "no one can do it because no one else is doing it" situation. > Yes, adding MAC to cookies without TLS > does not provide anywhere near the protection of TLS, but it is better > than nothing, when TLS is not available. To Nico's point, I'm not entirely sure about that. If something like MAC caught on, where would people deploy it? They deploy it to protect credentials over non-TLS connections, right? So it might be used as yet another excuse not to use TLS, even though it doesn't provide the kind of protection that most users would expect. In modern browsers, MAC would do nothing to stop someone from injecting script into a response which initiates arbitrary requests on behalf of a user. A browser would have no idea that the script was malicious, so it would happily sign requests as if they were user-initiated. To the point: session hijacking isn't just about stealing and reusing a session token. I see no problem trying to provide something to help protect user credentials through hard-to-crack hashes and the like, since those are often used in more than one place, but I see no point in trying to provide one-way integrity protection. thanks, tim _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
