Dynamic HPKP pinning tests

[lgarron]

(Followup to #15.)

[rugk]

I think the design should be like in https://hsts.badssl.com/.

The only thing you have to keep in mind is that the image which indicates the state of HPKP should be loaded over a different domain than https://hpkp.badssl.com/ (e.g.), because otherwise you cannot access https://hpkp.badssl.com/ any more... 😃
This way you should also see an error message (like HPKP does not work or no HPKP header was sent previously [or has expired]) when accessing the site the first time - which is expected.

[lgarron]

Ideas from @seccubus at #178:

• Only one PIN (no backup)
• two pins, both not matching anything
• two pins, both pinning a CA not in the chain.

[MrSeccubus]

One more. A 90 second timeout. Technically correct, but not very useful.

[lgarron]

Technically correct, but not very useful.

What is this meant to test?

I am happy to add as many subdomains and paths as are useful, but each of them should be useful for testing some sort of security feature (preferentially browser UI).

[MrSeccubus]

This wil not give an error in the browser UI. Just like having a single pin will not give an error.

However, these cases are still considered bad practise because having your hpkp pin exipire after 90 seconds still allows an attacker to mitm you if you haven't visited the site in less then 90 seconds before the attack.

Similarly the single pin is bad because you will effectively brick your site for everybody that visited your site before in the timeout period if you lose your private key.

My usecase Is that I'm using badssl as a testbed for testssl.sh

[lgarron]

My usecase Is that I'm using badssl as a testbed for testssl.sh

Hmm, that sounds pretty reasonable. Would it be sufficient to have these configurations at different paths on the same domain (much less fuss than creating a separate domain for each one)?

[MrSeccubus]

For testbed purposes it would be sufficient, as testssl.sh is just a shellscript and it doesn't stick to the rules of hpkp. I would go for separate domains if the testcase bricks the site.

Fatal mistakes that each need a separate site:

• two pins, both not matching anything
• two pins, both pinning a CA not in the chain

You could actually combine these into a single site. Have two pins, one for something you pulled from /dev/random and the other that pins a CA that you don't use.

One site that has the non-fatal mistakes:

• Only one pin (I would pin a CA or Sub-CA), short timeout

Since both test cases can actually live inside the same header, there is no need to have these on separate URLs.

You could add a correctly configured site that has:

• a pin for the leaf, a pin for the Sub-CA, a pin for the root CA, a backup pin, a backup pin for another CA, includeSubdomains, preload, long timeout