Connections are reused when a host goes from non-pinned to pinned |
||||
Issue descriptionWhat steps will reproduce the problem? (1) In chrome://net-internals/#hsts, delete scotthelme.co.uk. (2) Visit https://hpkp.scotthelme.co.uk. Observe that the page loads without an error. (3) Visit https://scotthelme.co.uk. Observe dynamic pins for hpkp.scotthelme.co.uk under "Query domain" in chrome://net-internals/#hsts. (4) Visit https://hpkp.scotthelme.co.uk. What is the expected output? Visiting hpkp.scotthelme.co.uk in step 4 should result in a full-page interstitial for a PKP violation. What do you see instead? hpkp.scotthelme.co.uk loads without an error in step 4. net-internals shows that the request for step 4 gets pooled with an existing connection from step 1, and I guess pins aren't checked before pooling. I'm guessing this might be a dup of issue 533571 or another one of the socket pool bugs, but I'm reporting it separately as a security bug just to be safe.
,
Aug 29 2016
Hrm.... Flushing the entire socket pool whenever updating HSTS seems a bit much, though if it's an HTTPS proxy when the change occurs... How much do we care about this?
,
Aug 29 2016
I'm not adding the entry manually -- scotthelme.co.uk sets the pins. After looking at code a bit more I think we may be missing a VerifyDomainAuthentication() call here in SpdySessionPool::FindAvailableSession() after calling LookupAvailableSessionByKey(): https://cs.chromium.org/chromium/src/net/spdy/spdy_session_pool.cc?q=FindAvailableSession&sq=package:chromium&l=160 Sorry for the missing net-internals log, I attached it here. ID 2171220 is the first request to hpkp.scotthelme.co.uk. ID 2171609 is the request to scotthelme.co.uk that sets the pins with includeSubdomains. ID 2171735 is the second request to hpkp.scotthelme.co.uk, with HTTP_STREAM_JOB event ID 2171737 that logs HTTP2_SESSION_POOL_FOUND_EXISTING_SESSION.
,
Aug 29 2016
Right, but the SpdySessionKey for LookupAvailableSessionByKey doesn't do pooling, it finds the existing session. That is, it's the connection from (2) that was loaded without error. The same behaviour would be exhibited for an SSL socket that we reused for an HTTP stream, since we do the HPKP check in the socket now, not the URLRequestContext. That is, setting aside HPKP, I would not expect (4) to result in error, if Connection Keep-Alive was used.
,
Aug 29 2016
Sorry, that was supposed to be, "Setting aside HTTP/2, I would not expect (4)"
,
Aug 29 2016
Huh, ok, I guess this is WAI. It was surprising to me but as you say I guess this is just kind of how it is, even pre-HTTP/2.
,
Dec 6 2016
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 rsleevi@chromium.org
, Aug 29 2016