or check out https://report-uri.io/
@eva2000 nice page but since HPKP violations are not common. I would like to see two more topic on this page.
- An Test how some Page behave if they receive an HPKP report.
- An Tutorial how someone can test that his browser reports error for his domain.
Depends on the timezone, but you may be right.
And allow the attacker to intercept or modify all this data so you do not get any or a completely faked HPKP report. I think that’s not what you want.
That’s why you should use HTTPS and HPKP there too - obviously. Because if the client fails sending the report it should try it later again (if it’s following the specification).
Like already said by @eva2000 https://report-uri.io/ is a nice easy service for collecting such reports.
The issue is just that the connection will fail if your browser claims to support a TLS version (1.3) which it actually does not support…
So if TLS 1.3 is supported by your browser you should obviously enable support for it.
Yes, you’re right. Maybe I did not looked carefully enough.
Here is a demonstration of this: https://scotthelme.co.uk/demonstrating-hpkp-validation-failures/
You can also test it yourself e.g. by using infamous AV SSL interception software. As most browser have an exception of HPKP to allow this kind of interception you mostly have to adjust the settings to be able to test it like this. In Firefox this can be done by changing
(And for you here is a German guide how to do this: https://www.computerguard.de/threads/weitere-sicherheits-features-fuer-computerguard-de-content-security-policy-http-public-key-pinning.9666/)
Hi, even if i came from germany i have no problem in reading English documentation.
The first link was what i was looking for. The point about hpkp reporting url i do not agree.
You are right that the browser does an retry. But lets think about an simple case. You are
in an hotel or company and they implement an bad proxy that mess with ssl. Than you
have no chance receiving the report via https. But there would be no block at http level.
Did I claimed something else?
The German guide is also a bit more comprehensive - that’s why I linked it mainly.
In this case you’ve already lost if you use their devices, because obviously they could have added many root certificates or modified other things, where TLS cannot protect you.
A much better situation is if you use your own device in their WLAN: If a connection fails, because they intercept it the HPKP report may be triggered and sent. If this does not succeed the Browser can still try it again - at some point you maybe use another Wi-Fi network.
Hi, i setup an test domain with invalid pin’s. In the firefox console log i get the warning “Public-Key-Pins: The site specified a header that did not include a matching pin.” But the lock stay green and there is no report submited.
Not the action i expected at all. (In have the Self Created CA in my Truststore).
security.cert_pinning.process_headers_from_non_builtin_roots = true
security.cert_pinning.enforcement_level = 2
Obviously this is out of scope of this thread and not related to Let’s Encrypt, but just a short answer:
In the sites I linked to you can see how it should work. You can also test it here: https://pinning-test.badssl.com/ although this is only about preloaded pins and only works in the current Chrome/Chromium versions.
So to get back to your case: Maybe you loaded a site which loaded other assets from a domain with HPKP which are blocked as it is shown in the console.
The connection to https://hpkp-fail.suche.org/ currently fails. (timeout error, so not cause by HTTPS/HPKP)
I made an easy way to get the DH Parameter patched certificate updated. Put a small shell script on
Hi, i think this is misleading. Because i think currently only RSA Certificates can be used with letsencrypt.
"create a certificate with those dh params"
DHE in the ciphersuites is used for Key Exchange with forward security.
A browser must not cache or apply a HPKP policy if there is not at least 1 valid pin in the policy. If it did this, you would have immediately blocked any and all access to the domain in question, which is what the requirement is there to protect against, accidentally causing a DoS.
To create my demo subdomain, https://hpkp.scotthelme.co.uk, I created a HPKP policy on http://scotthelme.co.uk that contains the includeSubdomains directive. This policy will then apply to all subdomains but the policy does not include a valid pin for the certificate on the hpkp subdomain, causing the HPKP error.
I hope that helps.
@rugk : Thanks for the tip with “TLS extension intolerance” i fixed my server that he now accept 1.3 too.
@ScottHelme : If i go first to “hpkp” and later to the main domain and than back to “hpkp” i did not receive
any warning. After closing firefox and go to main domain first i receive an warning. But i can not see
traffic to report-uri.io i my browser log or browser DNS information.
If i got you correct it i set an lifetime of one year for the pin the browser would cache the information
across the sessions ? Is this anywhere described ?
I’ve just checked Firefox and it’s also acting a little buggy for me. Once you have visited the main domain then you should have the policy and cache it to be applied. Does it work in Chrome? (Firefox doesn’t report on HPKP violations yet).
The issue is that it should not accept 1.3…
Because TLS v1.3 is not even standardized yet so the web server does quite sure not support it.
Hi, i fully understand it. If an client connect with SSL Version TLSv1.0 Handshake Version TLSv1.3 the server response with TLSv1.2.
That’s the correct way.
OK now i also Updated to 4 times 100%
The decission is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA with server side mitigated. (4*100)
or TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (one of them required for firefox).
Personal i think 100,100,100,90 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 would be more secure.
And it would be good if the rating would also show this.