- Android 14 (API v34) stellt um: System-CA-Zertifikate werden nicht mehr aus
/system, sondern aus dem APEX-basierten Modulcom.android.conscryptgelesen. Damit bricht der bisherige Debugging-Workflow, bei dem Zertifikate mit Root-Rechten injiziert wurden - Seit Android 7 Nougat ist der standardmäßige Trust Store von Apps in System-CAs und Benutzer-CAs getrennt; Entwicklungs-, Test- und Reverse-Engineering-Tools waren darauf angewiesen, das System-CA-Verzeichnis direkt zu ändern
- Die neue Struktur ermöglicht es, CA-Zertifikate per Google Play System Update zu aktualisieren, wodurch problematische CAs schneller entfernt und neue CAs schneller verteilt werden können – allerdings sinkt die Kontrolle des Gerätebesitzers
- Im Android-14-Beta-Emulator sehen Settings und Apps weiterhin die Google-CA-Liste, selbst wenn
/system/etc/security/cacerts,/system/etc/security/cacerts_google,/apex/com.android.conscrypt/cacertsusw. per tmpfs überdeckt oder gelöscht werden - Zum Zeitpunkt des Schreibens waren das Festhalten an Android 13 oder ein Custom OS ohne APEX die realistischen Alternativen; später seien durch Updates mehrere Umgehungsmethoden für die Zertifikatsinjektion unter Android 14 bekannt geworden
Wie sich die CA-Verwaltung in Android verändert hat
- Als Android 2007 von der Open Handset Alliance vorgestellt wurde, betonte man mit Formulierungen wie „open platform“ und „complete access to handset capabilities and tools“ die Offenheit
- Mit der Zeit wurde der Bereich, in dem Nutzer, Entwickler und Forscher ihre eigenen Geräte kontrollieren können, zunehmend kleiner eingeschätzt
-
Der Umbruch mit Android 7 Nougat
- Die vom Gerätebesitzer veränderbare CA-Liste wurde in System-CAs und Benutzer-CAs aufgeteilt
- Die vom OS-Anbieter bereitgestellte feste Liste von System-CAs wurde zum Standard für alle Apps
- Die vom Nutzer veränderbare CA-Liste wird nur verwendet, wenn eine App ausdrücklich per Opt-in zustimmt
- In der Folge vertrauen fast alle Apps Benutzer-CAs standardmäßig nicht mehr
Warum CA-Zertifikate wichtig sind
- Die vertrauenswürdigen CAs eines Geräts sind die Liste von Organisationen, die die Sicherheit verschlüsselten Netzwerkverkehrs garantieren
- Eine CA kann Zertifikate für TLS-Verbindungen wie HTTPS für beliebige Domains ausstellen, und Geräte, die dieser CA vertrauen, akzeptieren diese Zertifikate als Nachweis einer legitimen Verbindung
- Wenn ein Nutzer eine selbst erstellte CA auf dem Gerät als vertrauenswürdig einrichtet, kann er seinen eigenen HTTPS- oder TLS-Traffic abfangen und einsehen
- Die vom Smartphone gesendeten und empfangenen Daten lassen sich überprüfen
- Bei Bedarf lassen sie sich ändern oder blockieren
- Diese Kontrolle ist wichtig für Sicherheits- und Datenschutzforschung, Reverse Engineering, App-Debugging und -Tests, interne Unternehmensnetzwerke sowie Nutzer, die den Standard-CAs nicht vertrauen
- Es ist sinnvoll, nichttechnische Nutzer davor zu schützen, CAs versehentlich zu ändern, oder Änderungen ohne ihr Wissen zu verhindern; wenn jedoch auch die Kontrolle fortgeschrittener Nutzer eingeschränkt wird, werden viele Anwendungsfälle erschwert
Root-basierte Umgehungen seit Android 7
- Auch nach Android 7 ließ sich auf Geräten mit Root-Rechten der System-CA-Store direkt manipulieren
- Die typische Methode besteht darin, das gewünschte Zertifikat unter
/system/etc/security/cacerts/abzulegen - Da
/systemselbst auf gerooteten Geräten normalerweise read-only ist, wurden zwei Ansätze genutzt- Das
/system-Verzeichnis schreibbar rekonstruieren, neu starten und anschließend das echte Systemzertifikatsverzeichnis ändern - Ein temporäres Lese-/Schreib-Dateisystem über das read-only-Verzeichnis mounten, die bestehenden CAs kopieren und dann das neue Zertifikat hinzufügen
- Das
- Damit ein Zertifikat vom System akzeptiert wird, müssen außerdem Bedingungen wie Dateiname, Berechtigungen und SELinux-Label stimmen
- HTTP Toolkit automatisierte das Verfahren mit temporärem Mount und bot so One-Click-Interception-Setup auf gerooteten Android-Geräten oder Emulatoren
- Dieser Ansatz funktionierte auf Custom-Root-Geräten, speziellen Android-Distributionen und den meisten offiziellen Emulator-Images von Google
- Ausgenommen sind gesperrte vollständige „Google Play“-Edition-Images wie bei normalen OEM-Geräten
- Auch die Einrichtungsdokumentation von mitmproxy, zahlreiche Blogposts, StackOverflow-Antworten, Forenbeiträge, Magisk-Pakete und Hinweise von cacert.org nutzten ähnliche Verfahren
Die neue CA-Update-Struktur in Android 14
- Android 14 befand sich zum Zeitpunkt des Artikels in der finalen Beta-Phase und sollte innerhalb weniger Wochen erscheinen
- Eine der wichtigsten Sicherheitsfunktionen sind remote aktualisierbare CA-Zertifikate
- Die Verwaltung der CA-Zertifikate wurde aus dem Kern-OS-Image herausgelöst und in eine separate Komponente verschoben, die über Google Play verteilt und aktualisiert wird
- Mit dieser Struktur kann Google das Vertrauen in problematische CAs schneller entziehen
- Es muss weniger darauf gewartet werden, dass jeder Smartphone-Hersteller ein vollständiges OS-OTA-Update ausrollt
- Allein per Google Play System Update lässt sich die CA-Liste auf Android-14+-Geräten ändern
- Standardmäßig vertrauenswürdige CAs haben weitreichende Macht und brauchen daher Aufsicht und Sanktionen; die Befugnisse gescheiterter CAs müssen schnell entzogen werden
- Als Beispiel verlor TrustCor im Januar 2023 nach entdeckten engen Verbindungen zu Malware-Verbreitern sowie zu US-Verteidigungs- und Geheimdienstauftragnehmern das Vertrauen wichtiger Akteure, darunter Google
- Umgekehrt verursacht auch eine verzögerte Verteilung neuer CAs Probleme
- Let’s Encrypt musste die Einführung verbesserter Signaturketten mehrfach verschieben, weil ältere Android-Geräte nicht über die neuesten Root-CAs verfügten
- Eine Struktur mit schnelleren CA-Updates ist an sich wertvoll, doch die Android-14-Implementierung macht Änderungen an System-CAs praktisch schwierig
Tatsächliche Dateipfade und APEX-Verhalten
- Die zentrale Änderung in Android 14 ist, dass Zertifikate nicht mehr aus dem bisherigen
/system/etc/security/cacertsgelesen werden, sondern aus/apex/com.android.conscrypt/cacerts, sofern dieser Pfad vorhanden ist /apexist der Pfad, unter dem Android Pony EXpress, also APEX-Container, gemountet werden- APEX-Module sind unabhängig aktualisierbare Systemkomponenten und werden als signierte, unveränderliche Container ausgeliefert
- Die CA-Zertifikate von Android 14 sind Teil des Moduls
com.android.conscrypt, der zentralen TLS/SSL-Bibliothek von Android - Das Low-Level-Verhalten von APEX ist nicht ausreichend dokumentiert; einige Links zu Kerndetails sollen nur auf internen Google-Seiten verfügbar sein
- Tests zeigten ein Verhalten, bei dem die Inhalte von APEX-Modulen einzelnen Prozessen direkt bereitgestellt werden, sodass Dateiänderungen an anderen Stellen nicht in dem ankommen, was Apps sehen
Beobachtungen im Android-14-Emulator
- Die offiziellen AOSP- und „Play Services“-Images des Android-14-Beta-Emulators erlauben Root-Zugriff
- „Google Play“-Images sind wie normale OEM-Geräte gesperrt
- Mit dem API-34-Image „Google APIs“ lässt sich ein Emulator erstellen und eine Root-Shell öffnen
- Das Überdecken der folgenden Pfade per tmpfs mit der bisherigen temporären Mount-Methode hatte nicht den erwarteten Effekt
/system/etc/security/cacerts/system/etc/security/cacerts_google/apex/com.android.conscrypt/cacerts/apex/com.android.conscrypt@340818022/cacerts
- Im Tab „System“ unter Settings → Security & Privacy → More → Encryption → Trusted Credentials erscheinen die vermeintlich versteckten Zertifikate weiterhin
- Wenn man zum Beispiel die Datei
3c9a4d3b.0des „ACCV“-Zertifikats im gesamten Dateisystem sucht, ist sie während der Überdeckung per Mount nicht sichtbar, erscheint in Settings aber weiterhin - Führt man dasselbe Verfahren mit einem Android-13-Image aus, ist die Zertifikatsliste in Settings leer; die bisherige Methode funktioniert dort also wie erwartet
Auch direkte Änderungen am System-Image scheiterten
- Startet man den Android-14-Emulator mit
-writable-systemund führtadb root,adb remount,avbctl disable-verification, Neustarts usw. aus, lässt er sich schreibbar machen - Danach konnten die Zertifikate unter
/system/etc/security/cacerts/*und/system/etc/security/cacerts_google/*gelöscht werden - Die Zertifikate unter
/apexließen sich jedoch nicht löschen- Auch nach dem Remount blieben sie read-only
- Auch der Befehl
mount -o remount,rw ...schlug fehl
- Die nächstliegende mögliche Manipulation bestand darin, den jeweiligen Zertifikatspfad per
umountauszuhängen, sodass er in der Ausgabe vonmountnicht mehr sichtbar war - Trotzdem wurden die CA-Zertifikate in der „Trusted“-Liste von Settings weiterhin geladen
- Das scheint kein Cache-Problem der Settings-App zu sein, sondern gilt auch aus Sicht des Zertifikatsspeichers, den Apps sehen
- Unabhängig davon, wie das Dateisystem geändert wurde, sahen Apps offenbar weiterhin Googles CA-Liste
Auswirkungen und Einschränkungen
- In Android 14 bricht der bisherige Workflow, System-CA-Zertifikate für Debugging, Reverse Engineering, Tests und Forschung zu installieren
- Zum Zeitpunkt des Schreibens bestand die Alternative darin, bei Android 13 zu bleiben oder ein Custom-OS-Release zu verwenden, das für die CA-Zertifikatsverwaltung keine APEX-Module nutzt
- Mit der Zeit können solche Alternativen immer weniger praktikabel werden, weil man sich von zentralen internen Komponenten von Android Mainline entfernt oder dauerhaft veraltete Software nutzen muss
- Wenn Inhalte innerhalb von APEX-Modulen selbst mit Root-Rechten nicht änderbar sind, könnte bei jeder weiteren Systemkomponente, die nach APEX verschoben wird, die Nutzerkontrolle abnehmen
- Das kann auch für Android-Forks wie GrapheneOS und LineageOS sowie für Magisk und verschiedene Module problematisch sein
- Laut dem Update am Anfang entstanden später durch Diskussionen und Forschung zu Umgehungen jedoch mehrere Lösungen, mit denen Zertifikatsinjektion auch unter Android 14 möglich ist
- Wer HTTPS-Traffic unter Android 14 debuggen möchte, kann sich nicht mehr nur auf die bisherige Root-basierte System-CA-Injektion verlassen
1 Kommentare
Hacker-News-Meinungen
Aus meiner Sicht als jemand, der mit alten Android-Root-Tools, modernen universellen Custom ROMs und diversen Arbeiten rund um Android OS zu tun hatte, ist die Überschrift heute und auch künftig falsch
Root auf Android bedeutet tatsächlich Root-Rechte, und man kann tun, was man will [1]
Das heutige Android-Root-Tool Magisk enthält sogar Funktionen zum „Modifizieren“ von Java-Code, sollte also auch auf tief versteckte Dinge zugreifen können
Nur weil der Autor es nicht geschafft hat, heißt das nicht, dass es unmöglich ist; wahrscheinlicher ist, dass zygote die CAs cached und daher mit
stop;startneu gestartet werden muss, oder dass vor dem Ausführen des Befehls in den richtigen Mount-Namespace gewechselt werden mussGrapheneOS und LineageOS haben Zugriff auf den vollständigen Quellcode, also können sie ändern, was sie wollen; die Einschränkung besteht eher darin, dass es lästig ist, mit den Dingen Schritt zu halten, die Google in enormem Tempo kaputtmacht
Ich hoffe, dass mehr Menschen zu Custom ROMs wechseln, da Android gegenüber Nutzern, insbesondere Power-Usern, immer feindseliger wird
In meinen Träumen baue ich einen Android-Fork wie „OwnerDroid“, bei dem die erste Zeile des Sicherheitsmodells nicht „Der Nutzer ist der Feind“ lautet, aber bislang habe ich nur ein paar kleine Bausteine gebaut; das Gesamtprojekt würde eine enorme Menge Arbeit erfordern
[1] Einige Schutzmechanismen auf Kernel-Ebene sind Ausnahmen, aber GKI verringert dieses Risiko
Das geht jetzt nicht mehr
Natürlich ist mit vollständigem Quellcode alles möglich, und man kann ein Android-System-Image, in dem dieses Modul deaktiviert ist, von Grund auf bauen; GrapheneOS/LineageOS können ebenfalls reagieren
Aber es entsteht viel neue Arbeit, und wenn man sich bei Kernkomponenten von der Android-Implementierung entfernt, kann das künftig noch mehr Wartungsaufwand bedeuten
Für die meisten betroffenen Nutzer liegt „baue zuerst selbst ein System-Image“ weit außerhalb ihrer Komfortzone und des Zeitaufwands, den sie investieren können
Am Ende wird es andere Lösungen geben, aber sie werden darauf hinauslaufen, sich in Namespaces hineinzuwühlen und die Mounts des Zielprozesses einzeln zu verändern, ein eigenes APEX-Modul so zu bauen und zu installieren, dass Android ihm vertraut, um das Systemmodul zu ersetzen, oder einzelne Apps mit Frida zu hooken
Trotzdem ist es ein großes Problem, weil es Nutzern erschwert, ihr eigenes Gerät vollständig zu kontrollieren
Wichtige Dinge wie Root-Prüfungen unverzichtbarer Banking-Apps oder Google-bezogene Funktionen sind nicht dokumentiert, und es ist fast unmöglich, Informationen dazu zu finden, ob die Kombination „Handymodell + regionale Banking-App + Custom ROM“ getestet wurde und gut funktioniert
Ich bin für Freiheit und Wahlmöglichkeiten, aber für den durchschnittlichen Smartphone-Nutzer ist das kaum ein realistisches Vorgehen, wenn er nicht mehrere Telefone und mehrere Arbeitstage investieren kann oder von vornherein kein Experte ist
Am Computer bin ich Power-User, aber beim Smartphone finde ich es in Ordnung, wenn es etwas dümmer ist
Schwierig wird das allerdings, wenn man das Telefon zunehmend als Multi-Faktor-Authentifizierungsgerät verwenden muss oder an die Launen von Unternehmen mit stärkerem Hebel, etwa Banken, gebunden ist
Ich habe nicht vor, dreimal mein Bankkonto zu wechseln, nur um eine App zu finden, die auf einem gerooteten Telefon funktioniert
Wenn man fragt: „Inwiefern sind Android-Forks Wettbewerber?“, bedeutet das, dass die Strategie funktioniert
Wenn der neue Weg Zertifikate aus
/apex/com.android.conscrypt/cacertsliest, sofern es existiert, könnte man/apex/com.android.conscrypt/cacertswohl nur für die nötigen Prozesse verstecken, ähnlich wie bei aktuellen SafetyNet-Umgehungen, Root-Hiding oder Magisk-Hiding, sodass auf den alten Weg zurückgefallen wirdSie sind ein Bereich für Hacker, und selbst dort nutzt sie nur ein sehr kleiner Teil
Hier gibt es viele gute Kommentare, aber ich denke immer wieder daran, wie froh man sein kann, dass PCs nicht wie Smartphones funktionieren
Android hat sich selbst so gründlich ruiniert, dass es sich merkwürdig anfühlt, Microsoft dafür dankbar zu sein, dass es die PC-Welt nicht so betreibt, wie Google die Smartphone-Welt betreibt
Windows selbst ist im Vergleich zu Android fast eine Bastion von Stabilität und gesundem Menschenverstand, und man wird auch nicht zu Upgrades gezwungen, bevor die Hardware tatsächlich altersbedingt ausfällt
Microsoft kontrolliert zwar ebenso wenig wie Google die gesamte Hardware-Software-Pipeline, hatte aber die Macht, Normen über den Store durchzusetzen oder Änderungen an der Umgebung über etwas wie SafetyNet zu unterbinden und damit PC-Besitz extrem unbequem zu machen
Ich erinnere mich nur vage, ob Microsoft früher einmal wegen solcher Dinge eine Kartellklage am Hals hatte; ich frage mich, wann Google dasselbe bevorsteht
Microsoft hat ebenfalls eine Menge DRM in Windows eingebaut und später einiges davon wieder aufgebrochen; Remote Attestation ist ebenfalls ins OS integriert
Google hat eine interne Android-Implementierung geändert, auf die Entwickler eigentlich nicht hätten bauen sollen, und ihnen damit das Leben schwer gemacht; Microsoft macht solche Dinge auch ständig
Wahrscheinlich muss man nur ein paar Wochen auf ein aktualisiertes Magisk-Modul warten, und ehrlich gesagt ist das nicht so schlimm
Auf den 5 bis 6 Geräten, die Android 14 bekommen werden, darf man bis dahin einfach nicht auf den Update-Button drücken
Windows 11 verlangt TPM und Secure Boot
Ich habe gehört, dass einige Entwicklungsländer verlangen, eine staatliche CA zu installieren, um alle Verbindungen per Man-in-the-Middle anzugreifen; wenn man das sehr schwierig macht, wird es praktisch schwerer, Nutzer dazu zu bringen, ihre eigene Privatsphäre abzuschalten
Ich nutze ein PinePhone Pro als Daily Driver.
Chase.com versucht wirklich hartnäckig, nicht standardmäßige Browser wie Librewolf sowie Browser auf Smartphones/Tablets zu blockieren, und will einen zur Nutzung der Mobile-App zwingen.
Zumindest solange WEI nicht verpflichtend ist, lassen sich solche dummen Maßnahmen leicht umgehen und sind daher kein ernstes Problem, aber da Chase eine Bank ist, frage ich mich, ob es rechtlich angreifbar wäre.
Mein erster Verdacht geht in Richtung ADA-Compliance, aber sicher bin ich nicht.
Inzwischen bin ich so erschöpft, dass ich nicht einmal weiß, ob es nur so dahingesagt ist, wenn ich sage, ich würde deswegen klagen wollen.
Es ist zwar ein Nebenaspekt, aber relevant, weil es eine weitere Facette davon zeigt, wie nahezu unmöglich es ist, dem Oligopol mobiler Betriebssysteme zu entkommen.
Selbst wenn die Nische der Linux-Phones wie durch ein Wunder auf ein paar Prozent wachsen würde, dürfte Android weiter schlechter werden, und es braucht irgendetwas.
Ich glaube, es kommt eine Ära der digitalen Leibeigenschaft.
Man wird Geräte nutzen, die irgendein „wohlwollendes“ Unternehmen bereitgestellt hat; dieses Unternehmen besitzt jeden Aspekt des Geräts, und man darf es nur gegen Bezahlung so benutzen, wie man ein Auto fährt.
Andere Wege werden größtenteils verschlossen, General-Purpose Computing bleibt nur noch für „Unternehmen“ übrig, und das „freie Web“ wird es zwar geben, aber es wird ziemlich technisch und nutzerfeindlich sein.
Der Großteil des Markts, insbesondere alles, wo es um Geld geht, wird es meiden wie die Pest.
Ich denke, Google hat damit das offene Web getötet.
Es wurde ohnehin schon etwas langweilig, aber es ist ärgerlich, dass es jetzt viel schwieriger wird, ohne Smartphone oder „zugelassenen“ Browser zu leben.
Es ist gut, wenn erfahrene Nutzer zusätzliche Software installieren können, um das Problem zu beheben, aber besser wäre es, wenn Chase die Standard-Website korrigiert, damit auch weniger versierte Nutzer mit ähnlichen Bedürfnissen Hilfe bekommen.
In dieser Hinsicht war Android meines Erachtens schon immer und ist auch heute noch restriktiver als Apple.
Selbst als man neue Root-CAs installieren und ihnen vertrauen konnte, konnten manche Apps das ignorieren und taten es auch.
Sowohl iOS als auch Android erlauben Apps, Certificate Pinning zu verwenden, aber seit Android 7+ ignorieren Apps standardmäßig seit 2016 von Nutzern hinzugefügte CAs[1].
Unter iOS ist der Prozess, einer Root-CA zu vertrauen, umständlich – Profilinstallation und furchteinflößende Warnungen –, was für sich genommen nachvollziehbar ist; meiner Erfahrung nach vertrauen die meisten Apps ihr aber, sofern sie kein Certificate Pinning verwenden.
[1]: https://android-developers.googleblog.com/2016/07/changes-to...
Android, das einem normalen Computer deutlich näher ist als iOS, hat ein sehr großes Stalkerware-Problem.
Stalkerware lässt sich nicht durch Prompts stoppen, macht sich Abwärtskompatibilität zunutze und umfasst alle möglichen Arten von Missbrauch.
Unter iOS ist es erstaunlich leicht, jemandem sein Telefon fünf Minuten zu leihen und danach jahrelang die HTTPS-Privatsphäre auszuhebeln.
Ich möchte die Möglichkeit haben, installierten CA-Zertifikaten tatsächlich zu vertrauen, aber es ärgert mich besonders, dass selbst Firefox als Webbrowser ohne versteckte Tab-Kombinationen und Einstellungen keine Benutzerzertifikate verwendet.
Trotzdem: Wenn man die Risiken für Android-Nutzer weltweit betrachtet, ist schwer zu behaupten, dass diese Funktion für ein paar Dutzend Techniker im Alltag entsprechend wichtig ist.
Ich sehe das hier eher als Nebenwirkung von Googles guten Sandboxing-Verbesserungen und eines lange verzögerten Update-Mechanismus für den CA-Store, nicht als böse Google-Verschwörung, um die Pläne der lokalen IT-Abteilung zu sabotieren.
Ein Magisk-Modul wird sicher bald als Workaround auftauchen, und bestehende Module werden eine Weile kaputt sein, aber das ist nach größeren Android-Updates üblich.
Falls nötig, kann man auch selbst ein Modul schreiben.
Ich denke, so funktionieren Mounts einfach.
Wenn unter
/apex/whateveretwas gemountet ist und jede App einen eigenen Mount-Namespace hat, dann ändert ein erneutes Mounten über/apex/whateverim eigenen Namespace nichts an anderen Namespaces.Man müsste das Dateisystem direkt ändern oder in den Mount-Namespace einer anderen App wechseln und auch dort tmpfs mounten.
Shared Mounts könnten helfen, aber sicher bin ich nicht; man müsste genauer ansehen, was tatsächlich passiert.
Dieses Ergebnis ist meines Erachtens eher ein Nebenprodukt von Googles Namespace-/Containerisierungsarbeit als ein absichtlicher Versuch, Nutzer selbst mit Root-Rechten daran zu hindern, Root-CAs zu ändern.
Das Endergebnis bleibt aber trotzdem ein großes Problem.
Der überraschende Teil hier sind die „separaten Mount-Namespaces“.
Früher konnte man eine Shell öffnen und etwas ins Dateisystem mounten oder es direkt verändern, und Apps lasen die Dateien aus diesem Mount problemlos.
Bei diesen cacert-Dateien ist das jetzt nicht mehr der Fall, und mit der neuen Methode ist auch eine direkte Änderung unmöglich.
Bis zu dieser Änderung wusste ich nicht einmal, dass Android-Apps eigene Mount-Namespaces verwenden.
Es gibt kaum Dokumentation dazu, wie genau das funktioniert, und ich bin mir nicht sicher, ob es bislang schon einmal einen so klar sichtbaren Fall dafür gab.
Siehe Manifest v3.
Ich habe dem Autor auf Twitter geantwortet, aber vielleicht hat er es nicht gesehen, daher hinterlasse ich es auch hier.
Ich bin die Person, die den Blogbeitrag zu den aktualisierbaren Zertifikaten in Android 14 geschrieben hat; dieser Beitrag ist im Artikel verlinkt.
Es gibt tatsächlich eine Systemeigenschaft, mit der man konfigurieren kann, dass das Lesen aus dem APEX-Zertifikatsverzeichnis umgangen wird.
system.certs.enabled=trueQuelle: https://android-review.googlesource.com/c/platform/framework...
Das ist keine OS-Eigenschaft aus
android.os.SystemProperties, also kein Wert, den man mitadbgeräteweit setzen kann, sondern einejava.lang.System-Eigenschaft, sprich eine Konfiguration, die innerhalb einer einzelnen JVM/App gesetzt wird.Meiner Ansicht nach müsste man die App selbst ändern, um Erstere neu zu setzen.
Für automatisierte Tests oder zum Umschalten der Einstellung zwischen Debug- und Prod-Builds ist das nützlich, aber wenn man CA-Zertifikaten auf dem gesamten Gerät vertrauen lassen möchte, hilft es kaum.
Falls du natürlich einen Weg kennst, diese Eigenschaft extern zu setzen und auf alle Apps anzuwenden, würde das wirklich gut funktionieren, und ich würde sehr gern davon hören.
Übrigens bin ich der Autor, und auf Twitter sehe ich so eine Antwort nicht.
Eben typisch Twitter im Jahr 2023.
Für die Sicherheit sieht das gut aus und für manche Entwickler wie die Hölle, aber ich frage mich, was passiert, wenn diese Android-Version in 2–3 Jahren aufgegeben wird.
Muss man dann beten, dass die hartcodierten Zertifikate noch ein paar Jahre halten?
Android 14 macht Root-Zertifikate über Google Play aktualisierbar; es ist also nicht mehr wie früher ein OTA-Update nötig, um Root-Zertifikate hinzuzufügen oder zu entfernen.
Es gibt auch einen Workaround, von dem ich heute erfahren habe [0].
Wer Android 7.0 oder älter nutzt, muss unter Umständen Maßnahmen ergreifen, um weiterhin auf Websites zugreifen zu können, die mit Let’s-Encrypt-Zertifikaten geschützt sind; empfohlen wird die Installation und Nutzung von Firefox Mobile, das einen eigenen Trust Store statt des Android-OS-Trust-Stores verwendet.
[0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
[1] https://www.xda-developers.com/android-14-root-certificates-...
Denn in Googles Update fehlte das Zwischenzertifikat, das Let’s Encrypt verwendet.
Das ist kein hypothetisches Zukunftsproblem, sondern ein Problem, das genau jetzt existiert.
Warum sollte Google der letzte Schiedsrichter darüber sein, wem ich vertraue?
Auch Google hat ganz sicher blinde Flecken.
Und selbst unter den bereits zugelassenen Zertifikatsanbietern gibt es welche, die in der Vergangenheit Zertifikate an Personen und Organisationen ausgestellt haben, die sie nicht hätten bekommen dürfen, und denen man daher eigentlich nicht vertrauen sollte.
Apps akzeptieren in der Regel keine Nutzerzertifikate, und als Google Cloud oder irgendetwas damit Zusammenhängendes auf ein neueres Zertifikat umgestellt wurde, hörten einige Apps auf zu funktionieren.
Das heißt, sie werden out-of-band über Play Services aktualisiert und erfordern kein OS-Update des OEM.
Mit jedem Android-Release sehe ich, dass irgendetwas entfernt wird und eher bedeutungslose Dinge hinzukommen.
iOS scheint sich in die entgegengesetzte Richtung zu bewegen, sodass sie sich langsam in der Mitte treffen und iOS Android später vielleicht in jeder Hinsicht überholen könnte.
Ich würde gern ehrliche Meinungen von Leuten aus dem Apple-Lager hören.
Ich nutze derzeit macOS und mag es nicht, weil es bei sehr grundlegender User Experience versagt, die unter Windows/Linux seit Jahrzehnten selbstverständlich ist.
Dinge wie Finder sind wirklich furchtbar.
Wenn ich in der nächsten Generation statt Android ein iPhone kaufe, werde ich dann auf iOS genauso negativ reagieren?
Kann man sagen, dass iOS für Smartphone-Use-Cases eine ausgereiftere und nützlichere User Experience bietet als macOS?
Ich würde gern wechseln, möchte aber weder Zeit noch Geld verschwenden.
Früher war Android mehr als nur iOS mit
.apk, wirklich schade.Dafür ist es in Ordnung.
Aber die Nutzer sind so stark eingeschränkt, dass man sich vielleicht Jailbreaking ansehen könnte; ich versuche allerdings, die Nutzung des Telefons zu minimieren und fast alles am Desktop zu erledigen.
Nebenbei bin ich gerade dabei, auch macOS aufzugeben und zu Linux zu wechseln.
Ich nutze eine private PKI, um auf selbst gehostete Software zuzugreifen
Dinge wie E-Mail-Server, Kalenderanbieter, Notizserver und Tools zur Foto-Synchronisierung
Ich muss mein Root-Zertifikat zur Liste der Zertifizierungsstellen hinzufügen können
Ich will die vom System bereitgestellte Liste nicht ändern, sondern einfach nur mein Zertifikat hinzufügen
Es ist mein Gerät, also finde ich, dass ich daran alles ändern können sollte, wenn ich will
E-Mail- und Kalender-Apps gehören sehr wahrscheinlich auch dazu
Was eher nicht funktionieren dürfte, ist, eine eigene CA zu installieren, um Traffic zwischen einer App und den Servern des App-Herstellers abzufangen
Das ist schade, weil man prüfen können sollte, was das eigene Gerät tut; aber der Use Case, private PKI für selbst gehostete Software zu nutzen, wird eindeutig unterstützt
Irgendeinen Weg sollte es dafür geben
getlocalcert baut dafür ein Tool [1]
Weil man damit vermeiden kann, eine Trust Root hinzuzufügen, ist der Ansatz „öffentliches Zertifikat über einem privaten Netz“ für manche Netzwerke insgesamt vorteilhaft
Ehrlich gesagt hatte ich nicht erwartet, dass Android private CAs blockieren würde, aber nun ist es eben so gekommen
[1] https://www.getlocalcert.net/
Ich nutze derzeit kein Android-Smartphone, aber früher konnte man meines Wissens ein eigenes CA-Zertifikat ohne Root-Rechte, nur über eine Option in den Einstellungen, zu einem Android-Smartphone hinzufügen, und zumindest Apps wie Webbrowser haben ihm vertraut
Das ist auch noch nicht ewig her
Deshalb habe ich nicht verstanden, ob das Rooten des Geräts zum Installieren eines benutzerdefinierten Zertifikats für irgendeinen anderen Zweck nötig sein soll
HTTP Toolkit war sehr nützlich, um aus der miserablen E-Auto-Lade-App von Turkey die versteckte API herauszuziehen
Ich habe außerdem Frida benutzt, um SSL-Pinning und Root-Erkennung zu umgehen
Dann wurde mir klar, dass der Grund, warum sie die API verstecken wollen, vielleicht darin liegt, dass diese APIs monströse Dinger sind /s