|
|
|
|
|
|
by feld
4162 days ago
|
|
|
Tools to permit you to wipe out your HPKP mistake would be usable by attackers, though. That's hard to solve. I haven't looked into HPKP much, but it appears it has the ability to be configured in a "report only" mode if name your header "Public-Key-Pins-Report-Only". This will allow you to test your implementation to make sure it's correct before renaming the header to start enforcing. The idea of a non-enforcing mode for testing purposes also exists in DKIM (though DKIM didn't really catch on much due to servers with proper DKIM configurations getting compromised and sending spam...) I would say that HSTS is far more dangerous as I don't see a similar "testing" mode available. edit: It would be a good idea to make sure your max-age setting doesn't exceed the expiration date of your intermediate certificate, so don't go crazy with it. A tool with built-in safeguards to handle most of this configuration would be welcome. |
|
|
I meant tools to prevent you from making the mistakes in the first place, not for fixing it after the mistake.
The non-enforcing mode doesn't help. When I talk about mistakes, I mean things like losing access to your cert or timing mistakes in rolling the cert. If I roll it out today, it will be fine today. It will probably fail at some point in the future though, and fail hard, unless I follow very strict processes.
HSTS is considerably less dangerous. Once it's set up, it will continue to work without you having to do anything extra. HPKP on the other hand requires you to actively consider when you generate new certs, and when you add extra HPKP headers to your responses, and when you roll the certs etc.
I can change my CA or generate a new key today on a whim, because I don't do HPKP. If I did do HPKP, this would require considerable thought and preparation in advance.