CT on Android and update on v2 log list

[Philippe Boneff]

Hello,

Thank you all for your interest in using Certificate Transparency. We understand the disturbance that the recent turndown caused. As we have all seen over the last few days, client-side CT enforcement comes with technical challenges and risks. We are working to provide a better experience in the future. Today, we have two announcements:

Firstly, https://www.gstatic.com/ct/log_list/v2/log_list.json will start returning 404 in 90 days, on 2023-06-07 around 10AM UTC+1.

Secondly, the existing log lists represent Chrome’s up to date interpretation of the CT ecosystem and are intended for use by CAs and CT monitors, not for CT enforcement by clients. The priority for these lists is to protect Chrome’s users.

We ask that you do not rely on these log lists for your application's CT enforcement. If you choose to ignore this warning, please:

1. Understand that this list may change without notice. This might break your application, and you must be prepared to remedy that breakage without assistance from Google.

2. Commit to monitoring the ct-p...@chromium.org mailing list and updating your application as needed. This mailing list is the official communication channel for log list changes, and we try to announce upcoming changes there when possible.

3. Understand that many existing CT enforcement libraries are not maintained, and do not follow current best practices. This may increase your app's risk of breakage.

4. Ensure that downtimes of these log lists do not result in your service incurring an outage.

We acknowledge that client-side CT enforcement on Android requires a lot of effort today. We are exploring options to make client-side CT enforcement easier and frictionless on Android. Google’s CT team will share information about these plans on the certificate-transparency mailing list in the coming months.

We remain available on certificate-...@googlegroups.com for any followup questions.

Sincerely,

Google’s CT and Chrome teams

[swaroop dantu]

Hi Google Team,

Is there any preferred library google suggests for achieving CT on Android ? 

Thanks

Swaroop

[Joe DeBlasio]

Hi Swaroop,

To our knowledge, there are no libraries for Android that currently satisfy all practices needed to enforce CT safely. As a result, we do not recommend any library for enforcing CT on Android. 

Best,

Joe, from the Chrome team

[Matt Dolan]

Hi Joe,

What would a library need to do to satisfy all practices needed to enforce CT safely?

The Appmattus CT library has been updated to fully support v3 log list. It now has regular releases (weekly) to update its embedded log list file as well as dynamic updating of the log list. Along with v3 support the libraries policy implementation closely matches Chromes in terms of the number of SCTs required and distinctness of operators as well as its fail over case. Similar to chrome if the log list file is too far out of date it now automatically disables the checks too. Given the v3 file now provides a timestamp it also protects as best it can from replay attacks of the log list files.

Of course at the moment it only accepts SCTs retrieved from the certificate - there is no support for SCTs over OCSP stapling or TLS extension but given the lack of wide use of these methods (even https://certificate.transparency.dev/howctworks/ downplays their use nowadays) I'm not convinced how much additional value that would provide.

A question I have is what I can do to make the library more robust. Are there any particular features you feel are missing that I should prioritise work against etc.

Many thanks,

Matt

ANDigital Ltd. Registered No. 08761455 in England and Wales. The registered address is: 3 Concorde Park, Concorde Road, Maidenhead, Berkshire, England, SL6 4BY. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, please notify us and remove it from your system. Although this email message and its contents have been checked for the presence of computer viruses, ANDigital Ltd. does not accept any responsibility as to its contents.

[phbo...@google.com]

Hi Matt,

Thanks for putting time into this and the recent PRs. I'm glad to see that CT enforcement will automatically be disabled after 70 days, that makes it easier to asses the impact of log list changes.

> there is no support for SCTs over OCSP stapling or TLS extension but given the lack of wide use of these methods (even https://certificate.transparency.dev/howctworks/ downplays their use nowadays) I'm not convinced how much additional value that would provide.

I agree your judgement here. The use cases of OCSP stapling and TLS extension are limited, and the added value is arguable.

>  A question I have is what I can do to make the library more robust.

Building a log list, delivering it to clients and enforcing CT are not easy challenges, I'm sure you're well aware of this! Maybe the repo README could highlight the (now diminished!) reliability risks that come with CT enforcement on the client side? Also, pointing folks at https://groups.google.com/a/chromium.org/g/ct-policy and https://groups.google.com/g/certificate-transparency could help make sure people who care about CT are all on the same forums.

Let's keep in touch!

Philippe from Google's CT Team

[Matt Dolan]

Yeah I agree. I've needed to to re-write the README for a while now and definitely giving it a better focus on the security implications will help.

[Joe DeBlasio]

Hi Matt,

To build off of what Philippe said:

• It's Chrome's position that each application or library should maintain its own CT policy that reflects decisions that make sense for you. Apple maintains their own policy and log list because what makes sense for them might not make sense for us, and similarly, the policy decisions we make for Chrome might not make sense for your use case.

• Relatedly, even if you base your policy off of Chrome's, the library really should be relying on your own mirror of the log list rather than directly on Google's URL. That indirection would allow you to diverge from the Google list if Chrome needed to quickly make an incompatible change. It'd also be useful to have the ability to globally disable CT enforcement without an app update, should incompatible changes occur.

• I'm very supportive of you adding an enforcement window, but the risk of being out of date applies equally to the enforcement logic itself. Chrome's policies in the log list (e.g. "usable", "retired" etc.) are tied to a particular enforcement implementation and using those log states without a matching policy implementation is risky. Although it's not exposed in the log_list.json file, Chrome internally uses a "compatibility_version" field that, when incremented, causes clients that don't recognize the new version to stop enforcement. You should ensure that policy enforcement does not diverge from the log list your library uses.

• While I've previously mentioned that Chrome is investigating whether we can remove support for one or both of SCTs via OCSP-stapling or TLS handshake, RFC 6962 does require both methods be implemented, and we do see both of these methods used in the wild. Choosing to not support those methods will not only impact who can use your library, but adds to the ongoing risks of using the library. Apps might not realize, for instance, that they're limiting their ability to change how they deliver SCTs in the future, which could result in breakage if they switch without adequate testing.

At an absolute bare minimum, I'd say that safe reliance on Google's log list means ensuring that you can:

• Safely handle transient downtime of the log list. The v3 log list comes with no SLA other than "we'll do our best", and downtime can and will happen. Libraries should be including a copy of their log list in the source and failing open if that copy is too old. They should not fail closed if they can't access the Google URL. Libraries should make clear to relying apps the downtime risks associated with these decisions.

• Adapt quickly to changes when necessary. The policies in the log list are made to meet the needs of a browser and are often paired with code enforcement changes on Chrome's side. We can't promise every decision or timeline is right for individual apps. Libraries relying on the log list need maintainers that actively monitor ct-policy@ for announced changes, determine whether those changes make sense for their use cases, make those changes, and ensure that downstream enforcing applications receive timely updates as needed. That last point -- ensuring that applications receive timely updates -- is hard to guarantee, but is critical for safety.

It sounds like you've made a lot of great changes to the library, but technical changes are only part of the picture. Enforcing CT safely requires the ongoing commitments of time and attention mentioned above -- I obviously can't speak to whether you or anyone else will do that.   

Hope that helps,

Joe

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/certificate-transparency/cf816800-20b4-4e7b-97cb-cd9e7ab3dc19n%40googlegroups.com.

[Samuel Cai]

My app received this warning, but I am sure my code doesn't use https://www.gstatic.com/ct/log_list/v2/log_list.json.

Could it be due to third party library I am using? How can I check this dependency, I tried searching this url in all my codes (including the binary format 3rd party library), but still couldn't find anything.

Thanks,

Samuel

[Roger Ng]

Hi Samuel,

I can take a look into that. Please send me your Android app package name in a private message.

Cheers,

Roger