Issue metadata
Sign in to add a comment
|
Security: HSTS Bypass when fake certificate is set before HSTS
Reported by
a3135...@gmail.com,
Mar 23 2017
|
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS When a site's fake certificate is added exception first (before hsts enabled), HSTS cannot protect it from click through. VERSION Chrome Version: [56.0.2924.87 (64-bit)] Operating System: Only tested on Windows 10，but maybe all platforms are influenced. REPRODUCTION CASE 1.Visit https://1.1.ascii0x03.cn first, then add it exception. Because my certificate is only for "*.ascii0x03.cn". 2.Visit https://ascii0x03.cn/ The site ascii0x03.cn set "Strict-Transport-Security:max-age=100000;includeSubDomains" header to protect any subdomains by HSTS. 3.Visit http://2.1.ascii0x03.cn/ You can see the http upgraded to https. And there'll be a NET::ERR_CERT_COMMON_NAME_INVALID error. You can't click through because of HSTS. Everything is ok. 4.Visit https://1.1.ascii0x03.cn again. There's no caution! We still can visit the HSTS site though the certificate is fake. FireFox doesn't have this bug.
,
Mar 23 2017
I think the proposal here is that we'd flush the user's exception list for all subdomains after getting a valid HSTS directive from an origin server. This doesn't really feel like a security bug, because the point at which the user clicks through the first warning is the time of exploit.
,
Mar 23 2017
> This doesn't really feel like a security bug, because the point at which the user clicks through the first warning is the time of exploit. I think that our behaviour is also spec-conformant. [1] mentions that we MUST terminate the connection, but it links to section 12, where user recourse is a SHOULD. [2] If the user has decided to be unsafe, I don't see strong value in securing this edge case. If anything, I would expect it to interfere with legitimate testing by developers. [1] https://tools.ietf.org/html/rfc6797#section-8.4 [2] https://tools.ietf.org/html/rfc6797#section-12.1
,
Mar 24 2017
I did an another experiment that I can't bypass the ascii0x03.cn in the same way.(via untrusted fiddler certificate) It seems that chrome do flush the user's exception for the exact domain when got a right HSTS directive, but don't flush the user's exception when got a HSTS "includeSubDomains " directive. So I think it's a bug, and I don't understand why we leave a "preSet Door" for the attacker to bypass SubDomain HSTS. Though the bug is not serious, there's a "permanent backdoor" to steal global cookies in "SubDomain HSTS" website. Sorry that I am not very familiar with RFC spec. Obey MUST or SHOULD? HSTS aims to terminate any secure transport connection attempts upon any and all secure transport errors or warnings. There's no caution page in REPRODUCTION CASE setp 4.
,
Mar 24 2017
> It seems that chrome do flush the user's exception for the exact domain when got a right HSTS directive See Issue 473390 and Issue 516808 . Certificate exceptions are forgotten upon receipt of a valid certificate. > "permanent backdoor" It's not permanent. Chrome caches certificate exceptions for a fixed lifetime (one week), unless overidden by a field trial group. See Issue 487270. const uint64_t kDeltaDefaultExpirationInSeconds = UINT64_C(604800);
,
Mar 25 2017
Oh, I got it. Thanks for your patient explanation which I learned much from. :) A "one week door" doesn't make much sense here. Sorry for the stupid questions~
,
Mar 26 2017
,
Jul 2 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rsesek@chromium.org
, Mar 23 2017Components: Internals>Network>DomainSecurityPolicy