Android 14 will prohibit modification of the system’s built-in root certificate
Recently, the developer debugging tool, HTTP Toolkit, released an article shedding light on Android’s trajectory towards a more restrictive environment. It emphasized that Android no longer permits developers to alter its built-in root certificates for debugging, inhibiting practices such as certificate substitution or Man-in-the-Middle interceptions to monitor specific traffic flows.
Though this trend commenced with Android 7.0, developers initially had countermeasures at their disposal. However, by Android 14, adjusting these inherent root certificates became unfeasible. Consequently, while HTTP Toolkit voiced its grievances about Android’s waning openness, it concurrently advised developers reliant on these functionalities to refrain from upgrading to Android 14.
The crux of the matter lies in Android’s certificate storage repository located at `/system/etc/security/cacerts/`. Although post-Android 7.0 developers couldn’t directly modify the certificate library, acquiring root access allowed them to alter the certificate path, thereby infusing the necessary certificates, such as universal self-signed ones.
With Android 14, Google implemented a swift reactionary security protocol by updating the Android system’s certificate library via Google Play.
Such measures weren’t arbitrary. Previously, with certificates embedded within the system, Google faced challenges updating them directly. This posed issues like certificate revocations where Google couldn’t intervene promptly. This led to delayed certificate updates for platforms like Let’s Encrypt, as new certificates weren’t trusted by older Android systems.
Subsequently, Google can now periodically update the certificate library through Google Play, including introducing new ROOT CAs or revoking existing ones. This enables Google to address certain issues within the CA industry swiftly.
However, the challenge arises as this novel update method no longer retrieves certificates from /system/etc/security/cacerts/ but sources them from another path: /apex/com.android.conscrypt/cacerts/.
The precise mechanics behind the APEX container remain elusive, with many specifics yet to be disclosed. During testing, developers discerned that attempting to modify this directory proved futile as the system outright ignored alterations.
As a result, even the infusion of self-signed certificates wouldn’t be recognized by the system, rendering methods like Man-in-the-Middle hijacking useless for debugging specific TLS traffic.
On a positive note, this alteration in Android 14 significantly enhances Android’s responsiveness to the CA industry, facilitating prompt revocations or trust of certificates, and bolstering Android device security.
Conversely, the downside for developers and cybersecurity researchers is evident: the inability to gain system trust for self-signed certificates gravely hampers debugging and security analysis endeavors.
Currently, Google hasn’t provided documentation concerning this matter, leaving uncertainty regarding potential resolutions.
