Hi Jeff, In defense of pin-break codes! -
On Fri, Oct 14, 2011 at 3:05 PM, =JeffH <[email protected]> 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
