On Tue, Nov 8, 2011 at 7:48 PM, Steingruebl, Andy <[email protected]> wrote: >> -----Original Message----- >> From: Chris Palmer >> > - There is no directive or suggestion to User Agents about saving or >> > not saving pins received in a private browsing mode. Maybe there >> > shouldn't be, but if a User-Agent does save them, the same 304/ETag >> > trick malicious sites use to track users can be created using certs >> > and subdomains. >> >> Yes, another person raised this concern, and it is real. I don't see a way to >> resolve this problem; perhaps I am not smart enough, but I can't see a way to >> have both dynamic pinning AND avoid this tracking attack. >> >> I am willing to add a paragraph about what browsers should do in private >> browsing mode, and I am willing to go either way on what the requirement >> should be. I don't know what is best. > > We battled this problem with HSTS as well. I think what Mozilla settled on > (and I don't remember the Chrome solution) is to use a different storage > mechanism when HSTS is *set* during private browsing mode, and clear on exit > from private browsing.
It's been a while since I wrote that code, but I'm pretty sure that's how it works in Chrome too. There's a separate memory-only HSTS store that's used for incognito. That's consistent with how we handle other host-specific data stored by the network layer, such as cookies. Adam > Clearing history/cookies on the browser is similarly problematic for HSTS and > pinning. This is unfortunate in that we'd really like it to be hard for > users to clear HSTS state because it is "good for them". Not clear whether > this belongs in the spec, or a set of implementation guidelines. Folks got > squeamish here about talking about exact UA behavior, etc. > > There is a Firefox bugzilla bug about this issue, I'll try to go find it and > post back here unless someone beats me to it. > > - Andy > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
