Subject: [websec] Shooting yourself in the foot with HSTS and HPKP

From: Yoav Nir <[email-masked]>
Date: Sun, 25 May 2014 23:45:59 +0300

Hi

We’ve had a few threads ([1]) on this list about administrators needing to be careful when activating HSTS and/or HPKP, because a common mistake like forgetting to replace the certificate in time can brick your site. The usual conclusion was that companies and organizations without the proper technical capacity to maintain a valid certificate should not use these features ([2])

So today we got a real live demo how this can happen even to big, well-funded companies ([3]). HSTS and HPKP were not involved - this was not a browser, but a client that was programmed to hard-fail when receiving an expired certificate. It is the equivalent of a site with HSTS, and if it can happen to them, it could happen to anybody.

I’m not saying we should revisit our previous decisions. Obviously Apple can fix this now in minutes (probably already has), and all the consequences are some bad press. I just think it is illuminating that even at large companies there is no guarantee that an action that needs to be performed once a year will be done correctly.

Yoav

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01119.html (just an example - there were many threads)
[2] http://www.ietf.org/mail-archive/web/websec/current/msg01213.html
[3] http://www.macrumors.com/2014/05/25/apple-software-update-invalid/

---

From: Igor Bukanov <[email-masked]>
Date: Mon, 26 May 2014 08:06:17 +0200

I second that concern. I know at least one organization that is not
going to consider implementing key pining precisely for that reason.
They may consider a report-only mode, but as they were badly bitten by
browser bugs in the report-only mode implementation of
Content-Security-Policy that effectively changed report-only into
enforcing, they would wait with that until the implementation matures.

I think it would be easier to convince them if they could implement
key pinning themselves in incremental steps. For example, a browser
can provide JS API to access certificate chain and a possibility to
"pin" a particular JS source so it would be always executed from the
local cache.

On 25 May 2014 22:45, Yoav Nir <[email-masked]> wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 26 May 2014 10:14:43 -0400

On Mon, May 26, 2014 at 2:06 AM, Igor Bukanov <[email-masked]> wrote:
> ... For example, a browser
> can provide JS API to access certificate chain ...
+1. I've been looking for it for years (and WebSockets, too). If
anyone knows where to find it, please let me know.

Jeff

---

From: Nico Williams <[email-masked]>
Date: Mon, 26 May 2014 09:25:17 -0500

I've seen many corporate failures to ensure fthe availability of unexpired
certificates.  I's a big problem.  Without an online certification
protocol, it is organizationally difficult to keep certificates valid!

DANE, of course, doesn't have validity periods, just TTLs, so it shouldn't
suffer from this.  But DANE with pinning still would.  And rebuilding a
host without preserving its private keys would still cause failures.  But
at least organizationally, DANE is much, much easier to handle than PKIX.

(Kerberos has validity periods, but does much better because it has online
infrastructure, at the increased risk of downtime if that infrastructure
becomes unavailable.)

Nico
--

---

From: Igor Bukanov <[email-masked]>
Date: Mon, 26 May 2014 19:42:23 +0200

According to [1] the only realistic way to access the certificate
chain on the present web is to use Flash or Java applets,
https://www.linshunghuang.com/papers/mitm.pdf

[1] - https://www.linshunghuang.com/papers/mitm.pdf