Proposal: Include certificate fingerprint(s) in NEL reports

[ivanr]

I would like to propose that a certificate hash/fingerprint is included with reports that indicate TLS failures as well as successful reports. When there is a problem, knowing the hash would be very helpful to assist with troubleshooting. In fact, it would be great if either the entire chain is included, or at least the hashes of the entire chain. Given CT, the hashes are sufficient to rebuild the chain in most cases.

Identifying leaf certificate by fingerprint would be most helpful to assist preventing certificate expiration when success sampling is enabled. Although one can monitor from multiple vantage points, catching all servers is impossible with complex infrastructures.

The proposed workflow is as follows: 1) success sampling is enabled; 2) reporting endpoints examine TLS fingerprints to detect expiring certificates that have not been replaced and 3) alert the administrators to take action.

[neilstuartcraig]

+1 from me. I'd really like to know the full chain, fingerprints or certs.

By way of illustration, we had an issue with a small percentage of our users (those on Android 6 and older IIRC) whereby they couldn't use our website. They saw the full page interstitial showing a TLS error and we received NEL reports of "TLS cert authority invalid". After a few days of digging, we found that one of our edge services had a cert which had been replaced but without the "extended support" cert chain (i.e. the ultimate root was too new for Android 6 and older). The fix was simple, we added 2 certs to our chain.
If we'd have received the cert chain in the reports, we'd have seen immediately what the issue was.

This would also be useful where 3rd parties (e.g. CDN's, cloud/*aaS vendors) manage the TLS on our behalf. If they replace certs and it causes problems, we'd be able to identify that easily without interaction with them.

We would also be able to use this to distinguish errors caused by our certs versus those caused by AV/MitM TLS proxies.

Also, picking up on the idea for monitoring cert expiration. If NEL had a severity (as per #125 or similar), this could be an event with severity of warn when a cert was encountered with e.g. < 30 days validity.

[ivanr]

@neilstuartcraig If you wanted NEL to assign severity to expiring certificates, you'd have to tell it how to recognise them. There's a trend toward using short-lived certificates that might have lifetimes of as little as a week. Granted, not many people use them today, but it's likely that the trend will continue in the long term. Additionally, it's easy to achieve what you want via a smarter monitoring component.

[neilstuartcraig]

Yeah that's (shorter lifetime certs) true, i guess it's a question of how long it's likely to take to get there.
I think it's worth considering using NEL as a reporting mechanism for expiration for the same sort of reason that HTTP errors are included in NEL - not all devs/operators have access to other methods (this argument was made in #126 (comment))

[sleevi]

I think this is unlikely to be implemented for Chrome. We've consistently rejected such efforts for privacy and fingerprintability reasons. It's a giant fingerprint whether or not a user is, say, behind a proxy or MITM if the fingerprint diverges from what the server expects. We considered this during the design, and made an intentional decision not to expose.

[ivanr]

@sleevi You know that threat model better, but would it make any difference if Chrome would support this type of reporting only for certificates issued from public roots? That would still enable owners to be alerted about expiring certificates with much reduced (although probably not 100% eliminated) opportunity for fingerprinting. I think with this change an operator would at best be able to tell if a client is behind some sort of proxy, but that's about it.

[sleevi]

@ivanr No, because that effectively reveals when the user is using a proxy/local interception agent, which is a fingerprinting datapoint itself.

[ivanr]

@sleevi I am not sure you can completely avoid fingerprinting, though. For example, I suspect it would be easier to detect interception agents by looking at the TLS handshake parameters and other TLS aspects.

Is Chrome's threat model publicly documented? I'd be curious to learn more about what you're protecting against exactly.