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

[Trevor Perrin <[e-mail]>]

Hi Jeff,

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

Both backup pins and pin-break codes let a site switch from its
current cert chain to a different one, so they have similar "disaster
mitigation" properties, and a site could choose one or the other.

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.


Trevor