[bdonlan]

With HKPK (which I think you're talking about here - HSTS just requires that https be used at all) expiration is not an issue as you whitelist the key, not the certificate (and are required to list a backup key, which should ideally be offline). By listing the server's own key, possibly in addition to a trusted CA, you ensure that in the worst case you can renew using the same key.

Obviously when you're first rolling it out you should use a short duration to allow for a quick rollback if something goes wrong.

Of course nothing about this truly prevents someone who didn't take proper precautions when setting it up from screwing it up. Unfortunately it's hard to make a more tolerant system without also making it vulnerable again...

[user5994461]

I am definitely talking HSTS. You only need HTTPS enabled and send the "Strict-Transport-Security" header. It is very easy to setup, it can also backfire pretty bad.

Not HKPK.

[okket]

I still think you have this wrong:

HSTS says "This domain uses TLS and ONLY TLS. Ignore insecure connections to this domain. Remember this for x seconds." (should be harmless these days, why should it backfire?)

https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security...

HPKP says "This domain uses this certificate. Also, remember this and ignore/complain when different in the future." (which is the problematic part)

https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning#How_It...

[user5994461]

You don't seem to understand. Read again, I gave many scenarios where a certificate will be invalid, that will block all access to your site if HSTS is enabled.

[okket]

I read your posts. Your examples apply to HKPK (key pinning), not HSTS (enforcing TLS only).

[user5994461]

My examples are for HSTS. I gave examples where a certificates is invalid. TLS fails when the certificate is invalid and HSTS blocks access to your site.