Re: [websec] New draft of HTTP header-based public key pinning

[Chris Evans <[e-mail]>]

On Tue, Nov 8, 2011 at 7:48 PM, Steingruebl, Andy <
[e-mail]> 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.
>

I recently fixed Chrome's behaviour here to be (barring regressions):
- _New_ HSTS metadata encountered in incognito mode is saved in-memory for
the duration of the incognito session, but never persisted to disk, or seen
outside of the incognito windows.
- Incognito mode _will_ use HSTS metadata that was already persisted to
disk at the start of the incognito session.

That seemed like a solid balance between the various privacy vs. security
concerns.


> 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.
>

For Chrome, I believe it is tied to cookies: "Cookies and other site data".
Last I talked with Sid at Firefox, they were thinking of splitting off
cookies from other site data. I'm not sure where that went. It also gets
complicated: is HTML5 database / indexed storage "cookies" or "other site
data", etc. etc.

I'd recommend we stay out of providing exact UA requirements here other
than a "SHOULD" for providing _some_ user-friendly way to clear HSTS
metadata. Realistically, it's a pretty small percentage of the browsing
population that go in and fiddle with storage settings.


Cheers
Chris


> 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
>
>