Re: [websec] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00)

[=JeffH <[e-mail]>]

Hi Trevor & ChrisP,

Trevor Perrin <[e-mail]> noted:
 >
 > In defense of pin-break codes! -
 >
 > On Fri, Oct 14, 2011 at 3:05 PM, =JeffH <[e-mail]> wrote:
 >> So if a purported Known Pinned Host presents a cert chain in the TLS
 >> handshake lacking any keys on the UA's pinned key list, then it could be a
 >> bogus host (eg attacker), and if the UA does a HTTP GET and sends cookies
 >> (as well as receives a response and examines headers (e.g. the UA could be
 >> redirected further afield)) in any case, then this is a (non-trivial)
 >> vulnerability.
 >
 > A better alternative might be to deliver pin-break codes as part of
 > the TLS handshake (e.g. a TLS Extension).  Then:
 >  * Pin-break codes would work regardless of how the pin-break
 > verifiers are set, so pin-break codes could be used with pins set via
 > HSTS header, browser hardcodes, Convergence, DNS, etc.
 >  * Pin-break codes would work with non-HTTP protocols like SMTP or POP.
 >  * Pin-break codes would be retrieved without an HTTP Request,
 > removing the risk noted above.
 >
 > What do you think?

In general, I think we should think about conveying pinning/unpinning in the 
TLS channel in some fashion (which I'd noted at the very end of my original 
msg). And yes, the added benefit of working for other protocols layered on top 
of TLS, rather than just working for HTTP, would seem to be a win (for the 
longer term).

Tho, getting TLS extensions actually implemented and deployed seems to take a 
few forevers.

I wonder about hacking it (conveyance of pinning/unpinning info), for the 
nearer-term, into a cert extension. Then just modifying client apps (e.g. 
browsers) is what's necessary.


 > Pin-break codes might be preferred by site operators nervous about
 > boxing themselves in with pinning, since pin-break codes let the site
 > change its cert chain arbitrarily without being limited by backup pins
 > or waiting for expiration.

Agreed, can see/understand that use case.


Chris Palmer <[e-mail]> followed up..
 >
 > Note that the TLS layer could still abort the connection if the
 > connection doesn't pass the pinning test (i.e. if the connection was
 > made with a server certificate that does not contain any previously
 > pinned public keys).

agreed.

 > Thus, in order to successfully use a breakc, you would still have to
 > serve it with a cert containing a public key you had pinned.
 > (Including, perhaps, your backup pin.)

yes, which has me wondering, as I hope I articulated somewhat clearly, about 
the overall utility of the pin-break-verifier-and-code mechanism, except in the 
particular case where a application server operator wishes to deploy only one 
key/cert and pin to that, cross their fingers, and then fall back on this pin 
breaking mechanism if needed.

 >> In examining the various such situations (aka "disasters") outlined in Sec
 >> 3, it appears that essentially all of them are mitigated if the host
 >> operators allocated a backup server key/cert as advised, and have properly
 >> issued a pin to it, along with their pin to their present operational
 >> key/cert. In this situation, it appears that having the
 >> pin-break-verifier-and-code mechanism isn't strictly necessary.
 >
 > Chris E. and I now agree with this, and are probably going to remove
 > breakc and breakv from the draft specification. Even if they stay,
 > they probably won't appear in the first rev of the Chrome
 > implementation. The thinking is now, "Get the simplest thing
 > implemented, see how people like it, and implement breakc/v if there
 > is demand."

sounds fine to me.

 > This would probably/almost certainly imply that pins expire when the
 > server stops mentioning them in the pins directive (or when max-age
 > expires, whichever is soonest).

Agreed.

=JeffH