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

Clean up wording in new section

Browse Source 
Signed-off-by: Friendly Rabbit <169707731+friendly-rabbit-35@users.noreply.github.com>
This commit is contained in:
Friendly Rabbit 2024-07-16 20:23:06 -07:00
parent 68f831d5e8
commit 7c3da23524
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/posts/android/F-Droid Security Issues.md
View File

@ -106,7 +106,7 @@ Certificate pinning is an important security feature that is also straightforwar
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 done, though, the next best thing --- or, 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 include enforcing TLS 1.2 and TLS 1.3 and disabling weak ciphers. F-Droid does **none** 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.
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.
Furthermore, F-Droid has a problem regarding the adoption of **[new signature schemes](https://source.android.com/security/apksigning)**. They [held out on the v1 signature scheme](https://forum.f-droid.org/t/why-f-droid-is-still-using-apk-signature-scheme-v1/10602) (which was [horrible](https://www.xda-developers.com/janus-vulnerability-android-apps/) and deprecated since 2017) until they were forced by Android 11 requirements to support the newer v2/v3 schemes (v2 was introduced in Android 7.0, v3 in Android 9). Quite frankly, this is straight-up bad, and **signing APKs with GPG** is no better, considering [how bad PGP and its reference implementation GPG are](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html) (even Debian [is trying to move away from it](https://wiki.debian.org/Teams/Apt/Spec/AptSign)). Ideally, F-Droid should fully move on to newer signature schemes, and should completely phase out the legacy signature schemes which are still being used for some apps and metadata.