v2 log list issue and behaviours on older app version
Closed this issue · 8 comments
Hi guys,
I'm using com.appmattus.certificatetransparency:certificatetransparency-android:0.2.0 in my Android app. I just noticed this from the Google Play Developer Console
The message is clear and an update for my app is needed.
I've just one doubt about older versions of the app that implement the above library version: do all the network calls fail starting from the 15th of February 2023? Or just the CT check during SSL handshake won't work gracefully?
Thank you in advance.
Just tried to rewrite v2 log list endpoints' responses though a proxy, making them respond with 404. This, unfortunately, makes every network call under CT check fail :(
Thank you @HappyDr0id.
One question for the future: how can I get notified in case of further log list endpoint turndown (however Google says the v3 should implement a new schema that makes CT logs dynamically updatable)? How often they will be discontinued?
@mpatafio Chrome CT person here.
We try to avoid updating the schema / URL for the list whenever possible, and changes are announced ahead of time on the ct-policy@chromium mailing list, viewable at https://groups.google.com/a/chromium.org/g/ct-policy .
Note that this log list is designed to be used by certificate authorities and related parties who need to ensure that their certificates are trusted in Chrome. If apps or libraries build CT enforcement into their own apps using this list, they do so at their own risk -- we can't make any guarantees about the stability of the list, and in general we can't change our timelines to accommodate non-Chrome use-cases.
Note that this log list is designed to be used by certificate authorities and related parties who need to ensure that their certificates are trusted in Chrome. If apps or libraries build CT enforcement into their own apps using this list, they do so at their own risk -- we can't make any guarantees about the stability of the list, and in general we can't change our timelines to accommodate non-Chrome use-cases.
@jdeblasio thx for the message and clarification/insights.. would you have any recommendation how to implement it then for apps on android?
Since CT is a (recommended) way to avoid certificate pinning downsides etc. we (Android apps) should find a reliable, easy way to also provide it to our users (since it is a long time iOS feature and Google is involved with CT from the beginning).
Would be interested in your opinion, insights (although ofc maybe not your domain as being involved more with chrome).
Thx in advance.
@daniel-tailored speaking only for myself (not for Chrome/Google):
Most of the risk here comes from apps relying on libraries that aren't maintained. It might be reasonable for an app or library to bootstrap their CT enforcement using the Chrome list, but the CT ecosystem is always evolving, so to do so safely, the app/library developer is taking an ongoing obligation to keep up with changes to the ecosystem to keep things up to date.
This is similar to the other risks developers face when using third-party libraries. Unmaintained libraries might, for instance, have unpatched security vulnerabilities. App developers take on the cumulative risk of all of their dependencies.
Unfortunately, I'm not aware of an actively-maintained CT library for Android at this time. This functionality also isn't provided by Google Play Services or other Google-supported libraries.
As a result, I suspect developers have three options:
- Not use CT, nor pinning. Rely on the standard protections provided by TLS. Using technologies like CAA can help reduce the set of sources for possible unauthorized certificates.
- Use certificate pinning anyway, but mitigate the risks of pinning by providing multiple backup pins and re-evaluating your pinning configuration regularly.
- Use CT anyway, but keep up with the ecosystem yourself to maintain compatibility. In this case, that might mean carefully monitoring the mailing list mentioned above on an ongoing basis for any changes that might impact your app, then testing and modifying your configuration as needed as changes arise.
I know that none of those are super satisfying answers.
@jdeblasio thx so much for the response and the time you put into in replying.. I agree with you and we had a similar outcome of the pros and cons.
Most of the risk here comes from apps relying on libraries that aren't maintained. It might be reasonable for an app or library to bootstrap their CT enforcement using the Chrome list, but the CT ecosystem is always evolving, so to do so safely, the app/library developer is taking an ongoing obligation to keep up with changes to the ecosystem to keep things up to date.
Yes ofc.. also the given circumstances of an app, not being able to update things on the fly require a more stable/constant and backward compatible implementation even more. Hopefully v3 can offer that for quite a while now.
I now it is an evolving ecosystem but do you also have an evaluation on that or is that not really possible to say if in one year a breaking change making a force update necessary could happen?
Unfortunately, I'm not aware of an actively-maintained CT library for Android at this time. This functionality also isn't provided by Google Play Services or other Google-supported libraries.
Yes. Thats imo the biggest problem (nothing from Android/Google site).
We evaluated our options and also identified it as a risk but manageable (fork it etc.) and outweighing the risks of pinning respectively giving us more flexibility with CT. Unfortunately the turndown of v2 log list was not on the radar (and since we were pre-release it was not visible in the play store as a warning).
Adding this now to our evaluation and risk/mitigation to monitor not only vulnerabilities but the mailing list and updates that might impact the app.
A new version will be released shortly that will address the URL change and also provide a more robust caching mechanism.
Of particular note there are now some different VerificationResults to take note of that can help from a monitoring point of view.
- VerificationResult.Success.StaleNetwork - This indicates that the timestamp of the log-list.json file from the network is out of date. There are two cases here:
- either there is already cached data that is newer than the server is presenting; possible replay attack
- or there is no cached data and we are returning the server data as presented; possible network issues
- VerificationResult.DisableChecks - This indicates we are unable to load new data from the server and the data we do have is greater than 70 days old so (like Chrome) we are failing soft and disabling CT checks.