Chrome and Safari don't honor HPKP
I have added the HPKP header to my site, but it is not honored by Chrome or Safari. I checked it manually by setting up a proxy and going to chrome://net-internals/#hsts
and looking for my domain - which was not found. HPKP seems to be correct and I tested it with HPKP toolkit as well , so I know it is valid.
I think I might do something strange with my thread. I have a web application that is served via myapp.example.com
. At login, the application redirects the user to authserver.example.com/begin
to initiate the OpenID Connect authorization code flow. The HPKP header only comes back from authserver.example.com/begin
, and I think this might be the problem. I have include-subdomain
HPKP in the header so I think this is not a problem.
This is the HPKP header (Append Lines for Reading):
public-key-pins:max-age=864000;includeSubDomains; \
pin-sha256="bcppaSjDk7AM8C/13vyGOR+EJHDYzv9/liatMm4fLdE="; \
pin-sha256="cJjqBxF88mhfexjIArmQxvZFqWQa45p40n05C6X/rNI="; \
report-uri="https://reporturl.example"
Thank!
source to share
I have added the HPKP header to my site but it is not honored by Chrome or Safari ... I checked it manually by setting a proxy ...
RFC 7469, Extending the Public Key to HTTP , a kind of discernment that has passed you by. The IETF published it with overrides so that an attacker could break a known good pinset. It is mentioned once in the standard under the name "override" , but no details are provided. The IETF was also unable to post a discussion in the security considerations section.
Moreover, the proxy that you installed used an override. It doesn't matter if its the wrong proxy, a proxy certificate installed by a mobile OEM, or a proxy controlled by an attacker who tricked the user into installing it. The web security model and standard allows this. They cover interception and consider it a valid use case.
Something else they did was post a "shouldn't or shouldn't" broken pinset message. This means that the user agent is also complicit in the cover. This is also not discussed in the security considerations section. They really don't want people to know that their supposed secure connection has been intercepted.
The best thing to avoid is to go beyond the web security model. Don't use browser-based apps if the issue is security related. Use a hybrid app and customize. Your hybrid app can host a WebView control or view, but still access the feed to validate the settings. Also see OWASP Certificate and Public Key Closing .
Also see the draft-ietf-websec-key-pinning drawing comments on the IETF mailing list. One of the suggestions in the comment was to change the name to "HTTP Public Key Extension with Overrides" to highlight this feature. Unsurprisingly, this is not what they want. They try to do it secretly without knowing the user's knowledge.
Here's the relevant text from RFC 6479:
2.7. Interacting with preloaded contact lists
UAs can select additional sources of pinning information, such as through built-in pinning information lists. Such UAs should allow users to redefine such additional sources, including excluding them from consideration.
Effective policy for a well-known host that has both inline Inference and inference from previously discovered PKP header response fields from the implementation.
source to share
Locally installed CAs (such as the ones used for proxies as you say are running) override any HPKP checks.
This is necessary so as not to completely disrupt the Internet, given their prevalence: antivirus software and proxy servers used in large corporations, mostly MITM https traffic through a locally issued certificate, since otherwise they could not read the traffic.
Some would argue that installing a CA locally requires access to your machine, at which point it's a game anyway, but for me it still significantly reduces the protection of HPKP and that combined with the high risks of using HPKP means I'm really not a fan of it.
source to share