Closed
Bug 1275677
Opened 9 years ago
Closed 9 years ago
Connections are not blocked though HPKP violations are showed in Console
Categories
(Core :: Security: PSM, defect)
Core
Security: PSM
Tracking
()
RESOLVED
INVALID
People
(Reporter: r_kato, Unassigned)
Details
Attachments
(1 file)
21.20 KB,
image/png
|
Details |
Environment:
* Nightly 49.0a1 (2016-05-25)
* Windows 10 x86_64
Step to reproduce:
* Visit https://hashedhyphen.com/
hashedhyphen.com is certified with Let's Encrypt. I enabled HPKP at this domain, then I renewed the cert.
Of course, the SHA-256 values of the old cert and the new one are different, but connections to hashedhyphen.com are established successfully.
The certificate chain terminates at DST Root CA X3, which is a built-in root cert, not user-imported certs.
Why would connections be not blocked...? Or my server's settings are wrong...?
Updated•9 years ago
|
Group: core-security → crypto-core-security
Component: Security → Security: PSM
Flags: needinfo?(dkeeler)
![]() |
||
Comment 1•9 years ago
|
||
Since you updated your certificate, the hash of the entire certificate will of course be different. However, unless you used a different key, the hash of the key will not have changed. That may be what's going on here.
What are the errors you are seeing in the console?
Also, it might be helpful if you included the line corresponding to your site from the SiteSecurityServiceState.txt file in your profile directory.
Flags: needinfo?(dkeeler) → needinfo?(ryo_kato)
Reporter | ||
Comment 2•9 years ago
|
||
I'm sorry for my late response.
> What are the errors you are seeing in the console?
The error says "Public-Key-Pins: The site specified a header that did not include a matching pin."
> Also, it might be helpful if you included the line corresponding to your site from the
> SiteSecurityServiceState.txt file in your profile directory.
---------- SITESECURITYSERVICESTATE.TXT
hashedhyphen.com:HSTS 9 16949 1495976996626,1,1
There is no line including "hashedhyphen.com:HPKP"...
Flags: needinfo?(ryo_kato)
Reporter | ||
Comment 3•9 years ago
|
||
> However, unless you used a different key, the hash of the key will not have changed.
It seems that both public key and private key were changed after I ran letsencrypt.
Comment 4•9 years ago
|
||
(In reply to Ryo Kato [:r_kato] from comment #2)
> ---------- SITESECURITYSERVICESTATE.TXT
> hashedhyphen.com:HSTS 9 16949 1495976996626,1,1
>
> There is no line including "hashedhyphen.com:HPKP"...
That would seem to indicate HPKP was not set the first time as you thought.
The console error is a failure when *setting* HPKP: setting will fail if the current connection would fail the attempted pin. This prevents sites from blackholing themselves through a typo or similar mistake. If that error happened when you first tried to set HPKP (no way to know, now) then that might explain why there's no HPKP line in sitesecurityservicestate.txt
possible user error?
Reporter | ||
Comment 5•9 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #4)
> The console error is a failure when *setting* HPKP: setting will fail if the
> current connection would fail the attempted pin. This prevents sites from
> blackholing themselves through a typo or similar mistake.
If this behavior is expected one, that will be OK.
Reporter | ||
Comment 6•9 years ago
|
||
I visited https://hashedhyphen.com/ again. At this time, no error messages were shown, and SiteSecurityServiceState.txt was upated.
---------- SITESECURITYSERVICESTATE.TXT
hashedhyphen.com:HPKP 0 16955 1464919955847,1,0,IJWCtyBLFp9+UMm6eKP2h+77Rgucb0ZMyql1V0oD3LI=YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
hashedhyphen.com:HSTS 10 16955 1496449955847,1,1
The current pin-sha256 value specified in HPKP header is:
dEOSvbh9fdrFASgECKDhrMxbTYIUmOMNQ+2M27RvB7o=
Next time I visited it, the error message was shown though the connection established.
I don't understand that for now...
![]() |
||
Comment 7•9 years ago
|
||
Strange - there should be at least two pin-sha256 directives in the header (at least one corresponding to a key in the current verification path and at least one that isn't in any current verification path, as a backup). These links might be helpful:
https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625
http://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html (this one has a title that is unfortunately hostile, but it does have useful information)
Reporter | ||
Comment 9•9 years ago
|
||
(In reply to David Keeler [:keeler] (use needinfo?) from comment #8)
> Is this still an issue?
Thank you for useful information in #7. I found that this issue was caused by my server's wrong settings. Therefore this is no longer an issue.
Flags: needinfo?(ryo_kato)
![]() |
||
Comment 10•9 years ago
|
||
Great - thanks.
Group: crypto-core-security
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•