1

We have a domain with HSTS and HPKP enabled and working. For a few reasons, we would like to disable it, not immediately, but as soon as key expires. This means that the site would remain accessible through HTTPS, as it is now, but without the HSTS abd HPKP mechanisms.

What steps should we take to do this smoothly?

TRiG
  • 1,181
  • 3
  • 13
  • 30
TheMadCat
  • 35
  • 3
  • You should just stop sending it is response headers. For eg. if you have Apache web sever just remove relevant configuration from `.htaccess` or `httpd.conf` file. – Aniket Thakur Mar 17 '17 at 10:35

2 Answers2

1

Just stop adding HPKP(Public-Key-Pins) and HSTS(Strict-Transport-Security) headers to the answers, and after the biggest max-age value of either of these will expire (meaning no client will remember any longer that your site had these enabled), your site will be free of both HPKP and HSTS.

Also keep in mind that if you had max-age for HPKP bigger than your current certificate remaining lifetime, you will still need to use the backup key for certificate renewal, or the clients still remebering your backup key hash will think that something nasty is happening on the certificate replacement/renewal.

But it's a really weird intention - while the Web is moving to a more secure state, you wish to move in the opposite direction.

drookie
  • 8,625
  • 1
  • 19
  • 29
  • HSTS is fine, but public key pinning isn't really practical yet. – Michael Hampton Oct 18 '16 at 20:36
  • Oh really ? :) Read something about sslBump or other MitM attacks. And this isn't just some abstract paranoia - it's a modern reality, because it's already widely used in production. And not only by some repressive 3rd world countries - it's a DPI satellite technology. – drookie Oct 18 '16 at 21:10
  • I know exactly what problem public key pinning solves. It's just all the other problems it creates, which makes it not practical. – Michael Hampton Oct 18 '16 at 21:12
  • Read this about HPKP: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead – TheMadCat Oct 19 '16 at 01:17
  • 1
    ZAMAGAD ! *"One have to understand what he's doing and how HPKP is working". "Some hacker may hack your site AND ENABLE HPKP, THAT'S BAD". "The main problem with HPKP is that we have to make it simplier, so even a complete imbecile can operate it".* Lol. – drookie Oct 19 '16 at 03:07
  • 1
    Man, you know... if some attacker gains access to my server without me noticing it, so he can even edit the server configs - the HPKP enabling is least of my problems, and probably that would be too expensive for an attacker - to waste the server resources in this way: he could do way more damage, way more beneficial things for him without HPKP. And yeah, *"you have to know what you are doing"* it's a general rule in IT, not some dangerous exception. – drookie Oct 19 '16 at 03:08
  • 3
    My concern are not hackers, but how to deal correctly with HPKP. SysAdmins come and go, some are aware of it, some not. At this stage, HSTS, CSP Policies and OWASP are enough for us. – TheMadCat Oct 19 '16 at 11:05
  • I agree with @MichaelHampton that HPKP is not practical yet. It is easy for people to make mistakes and HPKP is not forgiving in that regard. – Aaron Apr 03 '17 at 14:10
0

Do not just stop sending headers. Set the header to expire before retiring

Nginx server block config

add_header Public-Key-Pins 'pin-sha256="hdkehrh4jrhi7h37ei3iehkhw=";max-age=0;includeSubdomains';

Btw the pin-sha256 is fake, there is no benefit to copy-pasting mine. The important part is the max-age=0; part. That way when you do remove headers in 3, 6, 9 + months time, it's done.

A Past client of mine moved hosting without clearing HSTS and their new host didn't offer them SSL. Their site was not loved and browsers from customers they had routinely blocked the non-https site (which was what they moved to).

MrMesees
  • 127
  • 5