1
0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2025-02-20 18:31:35 -05:00

Clarify cert pinning in Play Store (addresses https://github.com/PrivSec-dev/privsec.dev/issues/263)

Signed-off-by: Friendly Rabbit <169707731+friendly-rabbit-35@users.noreply.github.com>
This commit is contained in:
Friendly Rabbit 2024-07-22 14:58:51 -07:00
parent 7c3da23524
commit 91473381c2

View File

@ -81,7 +81,7 @@ It is also worth noting that the repository metadata format for F-Droid isn't pr
F-Droid's official client also lacks **TLS certificate pinning**. Certificate pinning is a way for apps to increase the security of their connection to services [by providing a set of public key hashes](https://developer.android.com/training/articles/security-config#CertificatePinning) of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (*man-in-the-middle* attack) could be possible and lead to various security issues, considering you're trusting an app to deliver you other apps.
Certificate pinning is an important security feature that is also straightforward to implement using the [declarative network security configuration](https://developer.android.com/training/articles/security-config) available since Android 7.0 (API level 24). The Play Store uses this feature, which improves security for all connections to Google (they generally use a limited set of root CAs including [their own](https://pki.goog/)). Likewise, see how GrapheneOS pins both root and CA certificates in their [app repository client](https://github.com/GrapheneOS/Apps):
Certificate pinning is an important security feature that is also straightforward to implement using the [declarative network security configuration](https://developer.android.com/training/articles/security-config) available since Android 7.0 (API level 24). The [GrapheneOS App Store](https://github.com/GrapheneOS/AppStore) uses this feature; see how GrapheneOS pins both root and CA certificates in their app repository client:
```xml
<!-- res/xml/network_security_config.xml -->
@ -104,6 +104,8 @@ Certificate pinning is an important security feature that is also straightforwar
</network-security-config>
```
The Play Store does not use certificate pinning exactly, but achieves a similar level of security for all connections to Google by using a limited set of root CAs, including [their own](https://pki.goog/)). This practice, alongside the Play Store's use of [package signing](https://source.android.com/docs/security/features/apksigning), guarantees that the apps you download from the Play Store are obtained securely and not tampered with. F-Droid does **not** provide the same guarantee.
To be fair, the F-Droid team has considered several times about adding certificate pinning to their client [at least for the default repositories](https://gitlab.com/fdroid/fdroidclient/-/issues/105). [Relics of preliminary work](https://gitlab.com/fdroid/fdroidclient/-/blob/1.14-alpha4/app/src/main/java/org/fdroid/fdroid/FDroidCertPins.java) can even be found in their current codebase, but it's unfortunate that they haven't been able to find [any working implementation](https://github.com/f-droid/fdroidclient/commit/7f78b46664981b9b73cadbfdda6391f6fe939c77) so far. Given the overly complex nature of F-Droid, that's largely understandable.
In a situation where TLS certificate pinning cannot be implemented, though, the next best thing --- rather, the most basic thing --- is to have a robust infrastucture for TLS. This means setting up CAA records with account pinning, setting up DNSSEC, and pinning ACME `accounturi` and `validationmethods`. Other basic security practices within this scope include enforcing TLS 1.2 and TLS 1.3 and disabling weak ciphers. F-Droid does **not** implement **any** of these. They do not have CAA records and DNSSEC and [still support TLS 1.0 and TLS 1.1](https://www.hardenize.com/report/f-droid.org/1721021966#www_tls) with their servers.