1278041 - Public-Key-Pins: An unknown error occurred processing the header specified by the site.

Status: RESOLVED FIXED

(Core :: Security: PSM, defect, P1)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

Visits https://tdelmas.ovh



Actual results:

The console display an error: 
>Public-Key-Pins: An unknown error occurred processing the header specified by the site.

The Network>Security tab display:
Public key Pinning: Disabled


Expected results:

The console display no error

The Network>Security tab display:
Public key Pinning: Enabled

Comment 1

[[e-mail]]

The current value of the HPKP header is: 'pin-sha256="YpcIku2YvZ9Q6rgTn8juPpBlEdzH7YFm9ZOLPImwwJk="; pin-sha256="IwwHGTSTcoDahobeEPEGs8n9nzQwPddD4wtpOesn0aQ="; pin-sha256="HzEi72HXqCYnOwBmRCxBCjCmqaCGjx0u0azPh/XgsN8="; max-age=5184000; includeSubdomains';

The base46 of my current key and the two backups:

openssl rsa -in current.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
YpcIku2YvZ9Q6rgTn8juPpBlEdzH7YFm9ZOLPImwwJk=

openssl rsa -in backup.tdelmas.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
IwwHGTSTcoDahobeEPEGs8n9nzQwPddD4wtpOesn0aQ=

openssl rsa -in backup2.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
HzEi72HXqCYnOwBmRCxBCjCmqaCGjx0u0azPh/XgsN8=


In google chrome, before visiting https://tdelmas.ovh , chrome://net-internals/#hsts the Query for tdelmas.ovh display

Found:
static_sts_domain: tdelmas.ovh
static_upgrade_mode: STRICT
static_sts_include_subdomains: true
static_sts_observed: 1462942800
static_pkp_domain: 
static_pkp_include_subdomains: 
static_pkp_observed: 
static_spki_hashes: 
dynamic_sts_domain: 
dynamic_upgrade_mode: UNKNOWN
dynamic_sts_include_subdomains: 
dynamic_sts_observed: 
dynamic_pkp_domain: 
dynamic_pkp_include_subdomains: 
dynamic_pkp_observed: 
dynamic_spki_hashes: 

And after:

static_sts_domain: tdelmas.ovh
static_upgrade_mode: STRICT
static_sts_include_subdomains: true
static_sts_observed: 1462942800
static_pkp_domain: 
static_pkp_include_subdomains: 
static_pkp_observed: 
static_spki_hashes: 
dynamic_sts_domain: tdelmas.eu
dynamic_upgrade_mode: STRICT
dynamic_sts_include_subdomains: true
dynamic_sts_observed: 1465034396.543958
dynamic_pkp_domain: tdelmas.eu
dynamic_pkp_include_subdomains: true
dynamic_pkp_observed: 1465034396.543974
dynamic_spki_hashes: sha256/YpcIku2YvZ9Q6rgTn8juPpBlEdzH7YFm9ZOLPImwwJk=,sha256/IwwHGTSTcoDahobeEPEGs8n9nzQwPddD4wtpOesn0aQ=,sha256/HzEi72HXqCYnOwBmRCxBCjCmqaCGjx0u0azPh/XgsN8=

I have the problem with Firefox 46 and Firefox developers 48

Am I missing something obvious?
Is it linked to the preload of HSTS?

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Looks like this call is failing with a TLS required feature missing error: https://dxr.mozilla.org/mozilla-central/rev/3e8ee3599a67edd971770af4982ad4b0fe77f073/security/manager/ssl/nsSiteSecurityService.cpp#705
I suppose in these cases we should just pass in the FLAG_TLS_IGNORE_STATUS_REQUEST flag, since the connection would have already failed if there wasn't a stapled OCSP response (this should be double-checked, though). I think we have a similar situation here: https://dxr.mozilla.org/mozilla-central/rev/3e8ee3599a67edd971770af4982ad4b0fe77f073/security/manager/ssl/nsNSSIOLayer.cpp#377 but it's not clear that it's safe to pass in the flag there (although the same reasoning may apply). We might be able to do better there, though, since at that point we should have access to the original connection's stapled OCSP response, I think.

Comment 3

[[e-mail]]

(Note that if you test my domain just after a server restart, you may encounter an error about a TLS feature missing, as my certificate has the must-staple  feature, and nginx has problem fetching OCSP for the firts request. F5 should make the problem disappear.)

Comment 4

[rugk]

Off-topic, but the Must-Staple issue with nginx is well-known and it is "architectural issue", but there are workarounds for it (the easiest is just doing a manual request after a server restart): https://unmitigatedrisk.com/?p=241

As for something on-topic: I can reproduce this error too, BTW. (also using OCSP Must-Staple)

Comment 5

[lussnig]

Hi, i can see an similar error with https://suche.org/ differences:
In the network security tab Public key Pinning: Enabled
1) If there is an HPKP error i would expect an security alert.
2) Normally an security alert should trigger an ssl-error reporting.
3) HPKP header is correct. OCSP-Stapple also works fine.
https://dev.ssllabs.com/ssltest/analyze.html?d=suche.org
There is no error with the ssl-setup or the security headers.
Since it is security related it should become more priority.
Tested Version (50.0a1 (2016-06-08))

Comment 6

[[e-mail]]

If I understand correctly the impact of the bug:
During the processing of HPKP, first the code check if the current session is trusted.
Here is the bug: as the certificate ask for must-staple, and the call to check the certificate at that moment do not give the stapled answer, it fail.
Thus, it do not continue the process of the header and do not send an report to the report-uri. 
(If a key was already previously pinned, it stay pinned)

I hope that bug can be fixed soon as it disable a security mechanism.

Comment 7

[rugk]

> I hope that bug can be fixed soon as it disable a security mechanism.

I heavily agree. Because of this bug webmasters now have to decide between OCSP Stapling or HPKP and have to disable one security feature if they want to use the other one (successfully).
So at least in the next nightly this should be fixed. I don't know however if it is possible to "backport" it also to Firefox Beta, so that it will be fixed with the next stable release of Firefox. (v 38, currently scheduled for 2016-08-02 - see https://wiki.mozilla.org/RapidRelease/Calendar), but if so I'm also advocating for doing so.

Comment 8

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: bug 1278041 - skip TLS Feature checks so HPKP can be set

This is safe because TLS Feature checks have already been done when connecting
to the site in the first place.

Review commit: https://reviewboard.mozilla.org/r/59848/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/59848/

Comment 9

[Mark Goodwin [:mgoodwin]]

Comment on attachment 8763719 [details]
bug 1278041 - skip TLS Feature checks so HPKP can be set

https://reviewboard.mozilla.org/r/59848/#review56868

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/394465ca5a62
skip TLS Feature checks so HPKP can be set r=mgoodwin

Comment 11

[lussnig]

Hi,

with the latest Versions of Firefox it is no longer an Error in the Console log.
Now the page can no longer be visited. Sample: https://suche.org/

No errors acording to https://dev.ssllabs.com/ssltest/analyze.html?d=suche.org

Error:   MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING
Version:  50.0a1 (2016-06-20)
and also: 50.0a1 (2016-06-21)

Comment 12

[rugk]

MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE means OCSP stapling is not sent. This error is triggered by OCSP Must-Staple.
So I think you just have a configuration issue. (Or your server could not request OCSP data from the LE OCSP server)

This does not seem related to this issue.

On SLLLabs it is now however shown that OCSP stapling works. I also Gert RhE same error when trying to connect to your site.

Comment 13

[lussnig]

But on ssllabs the check say that "OCSP stapling: Yes".
openssl s_client -connect suche.org:443 -servername suche.org -tls1_2  -tlsextdebug  -status
Say no. I think you are right and i have to check what happens on my side. Maybe an issue with CT-Log
via Status Response :-(

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/394465ca5a62

Comment 15

[rugk]

No SSLLabs is right. OpenSSL shows me:
"OCSP Response Status: successful (0x0)"

But I don't recommend continuing this discussing in this Bugzilla as it is unrelated to this issue. Test it with other browsers (which support OCSP Must-Staple - are there some?) and open a new big here if it is really a misbehavior of Firefox.


So actually on topic:
Nice that this big was fixed, however Firefox 50 is quite late. Can't we get it sooner, please?

Comment 16

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Comment on attachment 8763719 [details]
bug 1278041 - skip TLS Feature checks so HPKP can be set

Approval Request Comment
[Feature/regressing bug #]: bug 901698 / bug 921907 (OCSP must-staple)
[User impact if declined]: HPKP (http public key pinning) and OCSP must-staple will be mutually exclusive
[Describe test coverage new/current, TreeHerder]: has tests
[Risks and why]: low - small, localized change
[String/UUID change made/needed]: none

Comment 17

[Sylvestre Ledru [:Sylvestre]]

> [User impact if declined]: HPKP (http public key pinning) and OCSP must-staple will be mutually exclusive
What kind of potential regressions can we expect? Thanks

Comment 18

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

If a site has a certificate issued with an extension that specifies that OCSP information must always be included in the TLS handshake, if that site then attempts to set HPKP (i.e. specify that Firefox only connect to the site if it sees the right keys), it will fail with the error "an unknown error occurred processing the header" (note that the connection won't fail - setting the pins will fail. This is in general unnoticed by the user - the error appears in the console). Neither of these features are extremely common, but for sites that want to opt in to more robust security measures, having to choose between the two is unexpected and unfortunate.

Comment 19

[rugk]

Well explained! 

Comment 20

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8763719 [details]
bug 1278041 - skip TLS Feature checks so HPKP can be set

OK, let's take it.
Should be in 48 beta 4

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/852f817ca2c4

Comment 22

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b06bd6e4b887