I'm excited about this draft. > > Note that to validate pins, UAs must necessarily read the headers of > > a response. > [5] response = HTTP response? > This implies that the pin check machinery is up at the HTTP layer rather than > down lower in or near the TLS layer, which implies that the UA can make > normal HTTP requests to a bogus Known Pinned Host, and send cookies, before > realizing that the pin check has failed. > This is a fundamental security issue.
I don't think this is worded correctly. If a site is a Known Pinned Host, the pin check should occur after recieving the certificate chain, but before the TLS session is wholly established. If this check does not pass, the connection is aborted.[1] If a pin check occured at the HTTP layer and does occur after a TLS session has been established, data was sent by the client, and the response received - I see only two things that could happen that would be 'new' to the User Agent. 1) 'Oh, this site supports pinning. I didn't know that. I'll note it down as a Known Pinned Host. Let me check the pins just to be sane.' This check wouldn't actually provide any security (that's what preloading is for) - if the pins didn't match, either the server is messed up or the attacker was incompetant because they could have changed the pins. 2) 'I just recieved an unpin directive for the certificate I just used to connect.' This is again a case of the server being messed up. [2] So I think the existing wording is wrong, and better wording would be something like: Upon receipt of this header field, the UA will note the HSTS Host as a Known Pinned HSTS Host if it was previously not. When connecting to a Known Pinned HSTS Host, the UA will compare the public key fingerprint(s) in the Host's certificate chain to the pinned fingerprints, and will fail closed before sending a HTTP request unless at least one public key in the chain has a fingerprint matching one of the pinned fingerprints. (Following the HSTS specification, TLS errors for HSTS hosts must be hard, with no chance for the user to click through any warnings or errors. We treat fingerprint mismatch in the same way.) Where I added - "..will note the HSTS Host as a Known Pinned HSTS Host IF IT WAS PREVIOUSLY NOT." - "...will fail closed BEFORE SENDING A HTTP REQUEST unless at least...". [1] From an engineering perspective, perhaps the connection IS established because that occurs in a modular library that does not know of pinning, but the HTTP request would not be sent, because the connection would be examined outside the library. [2] Do we handle the case where Alice connects to a Known Pinned Site, recieves a valid certificate, but the certificate is unpinned in the Pinning Header? I think this is an error case, because while the initial connection is valid, any subsequent connections in the TLS session were 'fruit of the poison tree' - made using an unpinned certificate. I also think behavior should be noted explictly. I have an additional comment: this header field could grow quite large. Site operators may wish to omit it in the response in several scenarios that indicate to them the client has recieved it already. I don't see a reason this would cause any issue, I'm just noting it. -tom _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
