A lot of advice online, including my own, recommends that once you start enforcing a policy you keep the max-age quite short for a period of time. The report-only mode is helpful in identifying issues but given the nature of what HPKP is and does, jumping straight to a high max-age value when you start enforcing the policy isn't wise.
No, but that doesn't impact the operation of enforcing the use of their public keys which is the main purpose. It's definitely preferable to have reporting though.
When we first deployed our policy there was no support for reporting in browsers. I think that Firefox still lacks support and chrome only added support recently (I'd have to double check, or I'm sure Scott knows).
Yeah, we deployed this short max-age just to be safe on the initial deployment. I have a pull request open right now to switch our backup CA and add the intermediate certificate pins (to avoid possible future cross-signing issues) before we start bumping max-age. HPKP requires careful planning and a low max-age is definitely the way to go until you are 100% confident in your policy.
Thanks. I didn't know about X-Content-Type-Options! It is getting harder and harder to know all these headers nowadays. I am big fan of these checking tools with scores, it makes web developing entertaining. (A+! https://securityheaders.io/?q=https%3A%2F%2Fsatoshicrypt.com... )
I agree, I love these sorts of things because they make it easy to learn what you don't know. On the other hand, assigning an order based on an analysis like this can be interpreted wrongly, which I find annoying.
HPKP will accept if any of the fingerprints match -- I was wondering how I could transition certificates when using it, and hadn't noticed that fact. So to transition to a new certificate, specify the fingerprint of the old AND new certificates, for at least as long as the max-age. You can also specify the fingerprint of any certificate in the trust chain. I plan on pinning the let's encrypt certificate, instead of the specific certificates let's encrypt issues, and trusting let's encrypt to implement the domain validation correctly.
HPKP is HTTP Public Key Pinning, you aren't pinning certificates, you're pinning the public key. This means that you don't necessarily need to change any pins when you renew certificates as the certificate can use the same key pair. The only time you need to consume a backup pin when renewing the certificate is if you have a new public key signed. I think it's important to understand the difference before you try to deploy HPKP.
As for pinning the CA instead of your own public key, you can see my other comments in this thread with links about how GitHub pin their CA and a backup CA. I also have a link with information on the various levels in a chain you can pin at like the leaf, intermediate and root. Each has its own benefits and drawbacks.
I see, I hadn't made that obvious connection -- it's right in the name! (been awake for ~28 hours) That's much nicer. This is the first I've seen that header, it's good to know it exists -- I've implemented it in other ad-hoc protocols.
Strange, I get the same thing too despite the domain being among those whitelisted. I don't know how 'self' cannot equal securityheaders.io for a request to that domain.
I remember a while back when I was first using this I had a really difficult time getting it to work for a site I was doing. In the end, I had to remove all references to 'self' as a source and use the domain instead (even though these should be one and the same).
What I fear about HPKP is how easy it is to kill domain. You have to lose your keys once and it's lost domain for your users, because it's really hard for users to circumvent that protection. It's better to have a really good understanding of what's going on and have good key backups before you configure it.
I don't think `X-XSS-Protection` is a worthwhile header to have. Every browser with XSS protection has it on by default. OWASP says this only exists to turn it on when a user may have turned it off (I have no idea why they would).
`Content-Security-Policy` is an awesome header, but in truth, it's very easy to misconfigure and even when correctly configured is usually fairly easy to bypass on any non-trivially complex website (for example, JSONP is an effective bypass for CSP). It's still worth looking into.
This site is awesome!
That's why I've included on my OWASP Project.
I'm just starting this project but it's going to have a lot information about security headers.
46 comments
[ 2.7 ms ] story [ 109 ms ] threadhttps://securityheaders.io/?q=https%3A%2F%2Fgithub.com%2F
https://testssl.sh/ https://github.com/drwetter/testssl.sh
Site Scan from MS - https://dev.windows.com/en-us/microsoft-edge/tools/staticsca...
Subresource Integrity scanner - https://sritest.io/
--
These are all good but I would include the following:
Qualys SSL Server Test - The first site I use.
testssl.sh - for behind the fireware testing
https://tls.imirhil.fr/ - this one is nice because it shows the ciphers used/avail broken down by TLS version. I have not seen any other site do this.
As for pinning the CA instead of your own public key, you can see my other comments in this thread with links about how GitHub pin their CA and a backup CA. I also have a link with information on the various levels in a chain you can pin at like the leaf, intermediate and root. Each has its own benefits and drawbacks.
This is also keeping the CSS from loading. (Chrome, however, displays beautifully.)
I remember a while back when I was first using this I had a really difficult time getting it to work for a site I was doing. In the end, I had to remove all references to 'self' as a source and use the domain instead (even though these should be one and the same).
I also have a blog on the various places you can pin like the leaf, intermediate and root: https://scotthel.me/k2h
From recent scans I see that www.google.com got an E with missing headers:
Is this negligence on Google's part or ...?Looks like they just need a Content-Security-Policy and Public-Key-Pins.
`Content-Security-Policy` is an awesome header, but in truth, it's very easy to misconfigure and even when correctly configured is usually fairly easy to bypass on any non-trivially complex website (for example, JSONP is an effective bypass for CSP). It's still worth looking into.
https://securityheaders.io/?q=https%3A%2F%2Fnews.ycombinator...
https://www.owasp.org/index.php/OWASP_Secure_Headers_Project