Android 14, bahkan memblokir modifikasi sertifikat sistem meski dengan hak root?

• Android 14 (API v34) mengubah cara membaca sertifikat CA sistem, dari /system menjadi dari modul com.android.conscrypt berbasis APEX, sehingga alur debugging lama yang menyuntikkan sertifikat dengan hak root menjadi rusak
• Sejak Android 7 Nougat, penyimpanan kepercayaan default aplikasi dipisah menjadi CA sistem dan CA pengguna, sehingga alat pengembangan, pengujian, dan rekayasa balik selama ini bergantung pada cara memodifikasi direktori CA sistem secara langsung
• Struktur baru ini memungkinkan sertifikat CA diperbarui lewat Google Play System Update, sehingga penghapusan CA bermasalah dan distribusi CA baru bisa dilakukan lebih cepat, tetapi kontrol pemilik perangkat berkurang
• Pada emulator beta Android 14, meskipun /system/etc/security/cacerts, /system/etc/security/cacerts_google, /apex/com.android.conscrypt/cacerts dan lainnya ditimpa dengan tmpfs atau dihapus, Settings dan aplikasi tetap melihat daftar CA Google
• Saat artikel ditulis, alternatif yang realistis adalah tetap memakai Android 13 atau OS kustom yang tidak memakai APEX, dan kemudian penulis menyebutkan bahwa beberapa metode bypass untuk injeksi sertifikat di Android 14 telah muncul dalam pembaruan berikutnya

---

Perubahan bertahap dalam pengelolaan CA Android

• Saat Android diumumkan oleh Open Handset Alliance pada 2007, Android menekankan keterbukaan dengan ungkapan seperti “open platform” dan “complete access to handset capabilities and tools”
• Seiring waktu, ruang kontrol pengguna, pengembang, dan peneliti atas perangkat mereka sendiri dinilai makin menyempit

• Perubahan di Android 7 Nougat

  • Daftar CA yang bisa diubah pemilik perangkat dipisah menjadi CA sistem dan CA pengguna
  • Daftar CA sistem tetap yang disediakan vendor OS menjadi default untuk semua aplikasi
  • Daftar CA yang bisa diubah pengguna hanya dipakai jika aplikasi secara eksplisit melakukan opt-in
  • Akibatnya, hampir semua aplikasi tidak lagi mempercayai CA pengguna secara default

Mengapa sertifikat CA penting

• CA tepercaya pada perangkat adalah daftar organisasi yang menjamin keamanan lalu lintas jaringan terenkripsi
• CA dapat menerbitkan sertifikat untuk domain apa pun yang dipakai pada koneksi TLS seperti HTTPS, dan perangkat yang mempercayai CA tersebut akan menerima sertifikat itu sebagai bukti koneksi yang sah
• Jika pengguna membuat sendiri CA lalu menjadikannya tepercaya di perangkat, mereka bisa mencegat dan memeriksa lalu lintas HTTPS atau TLS mereka sendiri
  • Data yang dikirim dan diterima ponsel bisa diperiksa
  • Jika perlu, data itu juga bisa diubah atau diblokir
• Kontrol semacam ini penting untuk riset keamanan dan privasi, rekayasa balik, debugging dan pengujian aplikasi, konfigurasi jaringan internal perusahaan, serta bagi pengguna yang tidak ingin mempercayai CA bawaan
• Memang masuk akal jika pengguna nonteknis dibuat sulit mengubah CA secara tidak sengaja atau perubahan diam-diam dicegah, tetapi jika kontrol pengguna mahir juga dibatasi, banyak kasus penggunaan menjadi sulit

Metode bypass berbasis root setelah Android 7

• Bahkan setelah Android 7, pada perangkat yang sudah mendapat hak root, penyimpanan CA sistem masih bisa dimanipulasi secara langsung
• Cara paling umum adalah menaruh sertifikat tepercaya ke /system/etc/security/cacerts/
• Karena /system biasanya tetap read-only bahkan pada perangkat root, ada dua pendekatan yang biasa dipakai
  • Mengonfigurasi ulang direktori /system agar bisa ditulis lalu reboot, kemudian memodifikasi direktori sertifikat sistem yang sebenarnya
  • Me-mount filesystem baca/tulis sementara di atas direktori read-only, menyalin CA yang ada, lalu menambahkan sertifikat baru
• Agar sertifikat diterima sistem, syarat seperti nama file, permission, dan label SELinux juga harus sesuai
• HTTP Toolkit selama ini mengotomatisasi prosedur berbasis mount sementara tersebut untuk menyediakan pengaturan intersepsi satu klik pada perangkat Android root atau emulator
• Pendekatan ini bekerja di perangkat root kustom, distribusi Android khusus, dan sebagian besar image emulator resmi Google
  • Pengecualian utamanya adalah image edisi penuh “Google Play” yang terkunci seperti perangkat OEM biasa
• Dokumentasi konfigurasi mitmproxy, berbagai posting blog, jawaban StackOverflow, tulisan forum, paket Magisk, dan panduan cacert.org juga memakai pendekatan serupa

Struktur pembaruan CA baru di Android 14

• Android 14 pada saat artikel ditulis berada di tahap beta final dan dijadwalkan rilis dalam beberapa minggu
• Salah satu fitur keamanan utamanya adalah sertifikat CA yang bisa diperbarui dari jarak jauh
• Pengelolaan sertifikat CA dipisahkan dari image inti OS dan dipindahkan ke komponen terpisah yang didistribusikan dan diperbarui lewat Google Play
• Dengan struktur ini, Google bisa lebih cepat mencabut kepercayaan terhadap CA yang bermasalah
  • Tidak perlu terlalu lama menunggu tiap vendor ponsel merilis pembaruan OTA OS penuh
  • Daftar CA pada perangkat Android 14+ bisa diubah hanya lewat Google Play System Update
• Karena CA tepercaya bawaan punya kewenangan besar, diperlukan pengawasan dan sanksi, dan kewenangan CA yang gagal harus bisa dicabut dengan cepat
• Sebagai contoh, pada Januari 2023 TrustCor kehilangan kepercayaan sebagai CA dari Google dan pihak besar lain setelah ditemukan memiliki hubungan dekat dengan organisasi penyebar malware serta kontraktor pertahanan dan intelijen AS
• Sebaliknya, keterlambatan distribusi CA baru juga bisa menimbulkan masalah
  • Let’s Encrypt beberapa kali harus menunda distribusi perbaikan rantai penandatanganan karena perangkat Android lama tidak memiliki root CA terbaru
• Struktur yang meningkatkan responsivitas pembaruan CA memang bernilai, tetapi implementasi Android 14 membuat modifikasi CA sistem pada praktiknya jauh lebih sulit

Lokasi file sebenarnya dan cara kerja APEX

• Perubahan inti di Android 14 adalah: alih-alih memakai /system/etc/security/cacerts, sistem akan membaca sertifikat dari /apex/com.android.conscrypt/cacerts jika lokasi itu tersedia
• /apex adalah jalur tempat kontainer APEX dipasang, singkatan dari Android Pony EXpress
• Modul APEX adalah komponen sistem yang bisa diperbarui secara independen dan didistribusikan sebagai kontainer immutable yang ditandatangani
• Di Android 14, sertifikat CA menjadi bagian dari modul com.android.conscrypt, yaitu pustaka TLS/SSL inti Android
• Perilaku APEX tingkat rendah disebut belum terdokumentasi dengan baik, dan beberapa tautan detail penting hanya tersedia di situs internal Google
• Hasil pengujian menunjukkan isi modul APEX tampaknya diekspos langsung ke proses individual, sehingga perubahan file di lokasi lain tidak tercermin pada isi yang dilihat aplikasi

Gejala yang terkonfirmasi pada emulator Android 14

• Image AOSP dan “Play Services” pada emulator resmi beta Android 14 memungkinkan akses root
  • Sementara image “Google Play” tetap terkunci seperti perangkat OEM biasa
• Emulator bisa dibuat dengan image API 34 “Google APIs” dan dibuka dengan root shell
• Bahkan jika jalur berikut ditimpa dengan tmpfs memakai metode mount sementara lama, efek yang diharapkan tidak muncul
  • /system/etc/security/cacerts
  • /system/etc/security/cacerts_google
  • /apex/com.android.conscrypt/cacerts
  • /apex/com.android.conscrypt@340818022/cacerts
• Pada Settings → Security & Privacy → More → Encryption → Trusted Credentials, tab “System” tetap menampilkan sertifikat yang seharusnya sudah disembunyikan
• Sebagai contoh, jika file sertifikat “ACCV” 3c9a4d3b.0 dicari di seluruh filesystem, file itu tidak terlihat saat mount penutup aktif, tetapi tetap muncul di Settings
• Jika prosedur yang sama dilakukan pada image Android 13, daftar sertifikat di Settings menjadi kosong, sehingga metode lama bekerja sesuai perkiraan

Modifikasi langsung image sistem juga gagal

• Emulator Android 14 bisa dijalankan dengan -writable-system, lalu dibuat writable melalui adb root, adb remount, avbctl disable-verification, reboot, dan langkah terkait lainnya
• Setelah itu, sertifikat di /system/etc/security/cacerts/* dan /system/etc/security/cacerts_google/* memang bisa dihapus
• Namun, sertifikat di /apex tidak bisa dihapus
  • Bahkan setelah remount, jalur itu tetap read-only
  • Perintah mount -o remount,rw ... juga gagal
• Manipulasi terdekat yang mungkin dilakukan hanyalah umount pada jalur sertifikat tersebut agar tidak lagi terlihat di output mount
• Meski begitu, daftar “Trusted” di Settings tetap terus memuat sertifikat CA
• Ini dinilai bukan sekadar masalah cache aplikasi Settings, melainkan gejala yang sama dari sudut pandang penyimpanan sertifikat yang dilihat aplikasi
• Apa pun modifikasi pada filesystem, aplikasi tampaknya tetap melihat daftar CA milik Google

Dampak dan keterbatasan

• Di Android 14, alur lama yang memasang sertifikat CA sistem untuk debugging, rekayasa balik, pengujian, dan riset menjadi rusak
• Pada saat artikel ditulis, alternatifnya adalah tetap menggunakan Android 13 atau memakai rilis OS kustom yang tidak menggunakan modul APEX untuk pengelolaan sertifikat CA
• Seiring waktu, alternatif seperti itu bisa makin tidak praktis karena harus terus memakai perangkat lunak lama atau menyimpang dari komponen internal inti Android Mainline
• Jika isi modul APEX memang tidak bisa dimodifikasi bahkan dengan hak root, maka kontrol pengguna bisa makin berkurang untuk tiap komponen sistem yang nantinya dipindahkan ke APEX
• Ini juga bisa menjadi masalah bagi fork Android seperti GrapheneOS dan LineageOS, serta Magisk dan berbagai modulnya
• Namun, seperti disebut dalam pembaruan di bagian atas, diskusi dan riset bypass berikutnya telah menghasilkan beberapa solusi untuk memungkinkan injeksi sertifikat di Android 14
• Untuk men-debug lalu lintas HTTPS di Android 14, sulit lagi mengandalkan hanya injeksi CA sistem berbasis root seperti sebelumnya

[GN⁺]

Opini Hacker News

• Sebagai orang yang pernah mengerjakan tool root Android lama, ROM kustom serbaguna modern, dan berbagai pekerjaan terkait OS Android, menurut saya judulnya keliru, baik sekarang maupun ke depannya
  Kalau bicara root di Android, itu benar-benar berarti hak akses root, dan Anda bisa melakukan apa pun yang diinginkan [1]
  Magisk, root Android saat ini, bahkan mencakup fitur untuk “memodifikasi” kode Java, jadi semestinya tetap bisa diakses meski tersembunyi jauh di dalam
  Fakta bahwa penulis tidak berhasil melakukannya bukan berarti itu mustahil; kemungkinan masalahnya adalah zygote melakukan cache CA sehingga perlu direstart dengan stop;start, atau harus berpindah ke namespace mount yang benar sebelum menjalankan perintah
  GrapheneOS dan LineageOS punya akses penuh ke source code, jadi bisa diubah sesuka hati; kendalanya hanya repot mengikuti hal-hal yang dirusak Google dengan kecepatan luar biasa
  Saya berharap makin banyak orang pindah ke ROM kustom seiring Android menjadi makin memusuhi pengguna, terutama power user
  Dalam mimpi, saya membuat fork Android seperti “OwnerDroid” yang baris pertama model keamanannya bukan “pengguna adalah musuh”, tetapi sejauh ini saya baru membuat beberapa bata kecil; proyek utuhnya membutuhkan pekerjaan yang sangat besar
  [1] Dengan pengecualian beberapa proteksi tingkat kernel, tetapi GKI mengurangi risiko itu

  • Intinya, dulu bahkan pada image OS bawaan Google, siapa pun bisa memodifikasi sertifikat ini secara langsung cukup dengan menulis ke disk tanpa memasang tool apa pun, dan cara ini banyak dipakai serta masuk dalam panduan konfigurasi banyak tool
    Sekarang hal itu tidak bisa dilakukan lagi
    Tentu saja, jika punya source code lengkap, apa pun mungkin dilakukan; Anda juga bisa membangun image sistem Android dari awal dengan modul seperti ini dinonaktifkan, dan GrapheneOS/LineageOS pun bisa menanganinya
    Namun itu menciptakan banyak pekerjaan baru, dan jika komponen inti menyimpang dari implementasi Android, bisa jadi diperlukan lebih banyak pemeliharaan ke depannya
    Bagi mayoritas pengguna yang terdampak, “bangun dulu image sistem sendiri” jauh melampaui zona nyaman dan tingkat investasi waktu mereka
    Pada akhirnya solusi lain pasti akan muncul, tetapi kemungkinan bentuknya adalah menggali namespace untuk memodifikasi mount proses target satu per satu, membangun dan memasang modul APEX sendiri dengan cara yang dipercaya Android untuk menggantikan modul sistem, atau melakukan hooking pada aplikasi per aplikasi dengan Frida
    Meski begitu, ini masalah besar karena membuat pengguna lebih sulit mengendalikan perangkatnya sendiri sepenuhnya
  • Saya bertanya-tanya bagaimana dengan orang-orang yang sudah kurang lebih menyerah mengutak-atik ROM kustom
    Bagian penting seperti pemeriksaan root pada aplikasi perbankan wajib atau fitur terkait Google tidak terdokumentasi, dan hampir mustahil menemukan informasi bahwa kombinasi “model ponsel + aplikasi bank lokal + ROM kustom” sudah diuji dan berjalan baik
    Saya mendukung kebebasan dan pilihan, tetapi bagi pengguna ponsel rata-rata, ini sulit dianggap sebagai tindakan yang realistis kecuali mereka punya beberapa ponsel dan beberapa hari waktu kerja, atau memang sudah ahli sejak awal
    Di komputer saya adalah power user, tetapi saya merasa tidak apa-apa jika ponsel lebih “bodoh”
    Namun itu menjadi sulit jika ponsel makin harus dipakai sebagai perangkat autentikasi multifaktor, atau jika kita terikat pada kemauan perusahaan yang punya daya ungkit lebih besar seperti bank
    Saya tidak berniat berganti rekening bank tiga kali demi menemukan aplikasi yang berjalan di ponsel yang di-root
  • Google merusak sesuatu dengan kecepatan luar biasa dan membuat pihak lain sibuk mengejar adalah strategi untuk membuat pesaing sibuk mengejar ketertinggalan: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
    Jika Anda bertanya “memangnya fork Android itu pesaing?”, berarti strategi itu sedang berhasil
  • Kalau hanya membaca sekilas artikelnya, bypass-nya sendiri terlihat cukup mudah
    Jika cara baru membaca sertifikat dari /apex/com.android.conscrypt/cacerts saat lokasi itu ada, sepertinya kita bisa menyembunyikan /apex/com.android.conscrypt/cacerts hanya dari proses yang diperlukan, seperti bypass SafetyNet, penyembunyian root, atau penyembunyian Magisk saat ini, sehingga proses itu fallback ke cara lama
  • Saya rasa ROM kustom tidak akan menjadi arus utama, seburuk apa pun perilaku Google atau Apple
    Itu wilayah para hacker, dan bahkan di antara mereka hanya sebagian sangat kecil yang memakainya

• Ada banyak komentar bagus di sini, tetapi saya terus terpikir betapa beruntungnya PC tidak berperilaku seperti smartphone
  Android sudah merusak dirinya sendiri sedemikian rupa sehingga terasa aneh ketika saya bersyukur Microsoft tidak menjalankan dunia PC seperti Google menjalankan dunia smartphone
  Windows sendiri, dibandingkan Android, nyaris menjadi benteng stabilitas dan akal sehat, dan kita juga tidak perlu dipaksa upgrade sampai hardware benar-benar rusak karena usia
  Seperti Google, Microsoft memang tidak mengendalikan seluruh pipeline hardware-software, tetapi mereka punya kekuatan untuk membuat kepemilikan PC menjadi sangat merepotkan dengan memaksakan norma lewat store atau menekan modifikasi lingkungan lewat mekanisme seperti SafetyNet
  Ingatan saya agak samar apakah Microsoft dulu pernah terkena gugatan antimonopoli karena hal semacam ini, dan saya penasaran kapan hal yang sama akan datang ke Google

  • Windows sudah melakukan pembaruan CA berkala selama sekitar 20 tahun, dan pada titik ini justru Android yang berperilaku seperti Windows
    Microsoft juga menambahkan banyak DRM ke Windows, lalu belakangan merusak sebagian di antaranya, dan remote attestation juga tertanam di OS
    Google mengubah implementasi internal Android yang memang seharusnya tidak diandalkan, sehingga membuat developer tidak nyaman; Microsoft juga selalu melakukan hal seperti ini
    Kemungkinan besar tinggal menunggu beberapa minggu untuk modul Magisk yang diperbarui, dan jujur saja itu tidak terlalu buruk
    Pada 5–6 perangkat yang akan mendapat Android 14, cukup jangan tekan tombol update sampai saat itu
  • Microsoft juga pernah mencoba, hanya saja gagal, dan sekarang pun masih terus mencoba
    Windows 11 mewajibkan TPM dan Secure Boot
  • Saya melihat ini juga bisa menguntungkan pengguna
    Saya pernah mendengar bahwa beberapa negara berkembang mewajibkan pemasangan CA negara untuk melakukan serangan man-in-the-middle terhadap semua koneksi; jika ini dibuat sangat sulit, secara praktis menjadi lebih sulit membuat pengguna mematikan privasinya sendiri

• Saya memakai PinePhone Pro sebagai daily driver
  Chase.com benar-benar gigih mencoba memblokir browser non-standar seperti Librewolf serta penggunaan browser ponsel/tablet, dan berusaha memaksa orang memakai aplikasi mobile
  Setidaknya sampai WEI diwajibkan, langkah-langkah bodoh seperti ini mudah diakali, jadi belum jadi masalah serius, tetapi karena Chase adalah bank, saya penasaran apakah ada celah untuk menggugatnya secara hukum
  Dugaan awal saya terkait kepatuhan ADA, tapi saya tidak yakin
  Sekarang saya sudah terlalu lelah sampai-sampai tidak tahu apakah ucapan ingin menggugat soal ini masih sekadar omong kosong atau tidak
  Memang agak menyimpang, tetapi tetap relevan karena ini menunjukkan sisi lain bahwa keluar dari oligopoli OS mobile hampir mustahil
  Bahkan kalau ceruk ponsel Linux secara ajaib tumbuh sampai beberapa persen, Android kemungkinan besar akan terus memburuk, dan kita butuh sesuatu

  • Zaman kegelapan sedang datang, saya serius
    Sepertinya era perhambaan digital akan tiba
    Kita akan memakai perangkat yang disediakan oleh suatu perusahaan yang “baik hati”, perusahaan itu memiliki setiap aspek perangkat tersebut, dan kita hanya bisa menggunakannya seperti menyetir jika membayar
    Sebagian besar jalur lain akan dikunci, komputasi serbaguna hanya tersisa untuk “perusahaan”, dan “web bebas” akan tetap ada, tetapi cukup teknis dan tidak ramah pengguna
    Mayoritas pasar, terutama semua tempat yang berurusan dengan uang, akan menghindarinya seperti wabah
  • Jika tetap menjadi nasabah Chase, itu berarti mendukung sikap predatoris mereka dan mengirim sinyal bahwa industri lain juga boleh mengambil sikap yang sama
  • Bagian “setidaknya sampai WEI diwajibkan” itu menyedihkan
    Menurut saya Google sudah membunuh web terbuka dengan ini
    Memang web sudah mulai agak membosankan, tetapi menyebalkan karena sekarang jauh lebih sulit hidup tanpa ponsel atau browser yang “disetujui”
  • Jika Anda membutuhkan fitur aksesibilitas yang hanya tersedia di browser alternatif, sebaiknya hubungi Chase
    Memang bagus jika pengguna mahir tahu cara memasang software tambahan untuk memperbaiki masalah, tetapi lebih baik Chase memperbaiki situs web dasarnya agar pengguna pemula dengan kebutuhan serupa juga terbantu

• Dalam hal ini, menurut saya Android dulu dan sekarang lebih memaksa daripada Apple
  Bahkan ketika kita masih bisa memasang dan memercayai root CA baru, sebagian aplikasi bisa mengabaikannya, dan memang mengabaikannya
  Baik iOS maupun Android memungkinkan aplikasi memakai certificate pinning, tetapi di Android 7+ sejak 2016 aplikasi secara default mengabaikan CA yang ditambahkan pengguna[1]
  Proses memercayai root CA di iOS memang merepotkan, lewat pemasangan profil dan peringatan yang menakutkan, dan itu sendiri masuk akal, tetapi dari pengalaman saya sebagian besar aplikasi akan memercayainya kecuali mereka memakai certificate pinning
  [1]: https://android-developers.googleblog.com/2016/07/changes-to...

  • Saya paham mengapa Google melakukan itu di Android 7
    Android, yang jauh lebih mirip komputer umum dibanding iOS, punya masalah stalkerware yang sangat besar
    Stalkerware tidak bisa dihentikan dengan prompt, mempersenjatai kompatibilitas mundur, dan mencakup berbagai macam penyalahgunaan
    Di iOS, sangat mudah secara mengejutkan bagi seseorang yang meminjam ponsel selama 5 menit untuk membalikkan privasi HTTPS selama bertahun-tahun
    Saya memang ingin ada opsi untuk benar-benar memercayai sertifikat CA yang dipasang, tetapi menyebalkan bahwa bahkan Firefox, khususnya sebagai browser web, tidak memakai sertifikat pengguna tanpa kombinasi tab dan pengaturan tersembunyi
    Meski begitu, jika memikirkan risiko bagi pengguna Android di seluruh dunia, sulit menganggap fitur ini sama pentingnya bagi beberapa puluh teknisi yang memakainya sehari-hari
    Menurut saya kasus ini lebih merupakan efek samping dari peningkatan sandboxing Google yang bagus dan mekanisme pembaruan CA store yang sudah lama tertunda, bukan konspirasi jahat Google untuk menghalangi rencana departemen TI lokal
    Modul Magisk kemungkinan akan segera muncul sebagai workaround, dan modul yang ada akan rusak untuk sementara, tetapi itu hal umum setelah pembaruan besar Android
    Kalau perlu, Anda juga bisa menulis modul sendiri
  • Di iOS juga ada aplikasi yang bisa mengabaikan koneksi VPN: https://restoreprivacy.com/latest-ios-found-to-bypass-vpn-co...

• Rasanya ini hanya cara kerja mount, bukan?
  Jika sesuatu di-mount di /apex/whatever dan setiap aplikasi punya mount namespace terpisah, maka sekalipun Anda me-mount ulang sesuatu di atas /apex/whatever dalam namespace Anda sendiri, tidak ada yang berubah di namespace lain
  Anda harus mengubah filesystem secara langsung, atau masuk ke mount namespace aplikasi lain dan me-mount tmpfs di sana juga
  Shared mount mungkin bisa membantu, tetapi saya tidak yakin, dan perlu melihat lebih detail apa yang sebenarnya terjadi
  Menurut saya hasil ini kemungkinan besar adalah produk sampingan dari pekerjaan namespace/kontainerisasi Google, bukan upaya disengaja untuk mencegah pengguna mengubah root CA bahkan dengan akses root

  • Secara praktik, saya pikir perkataan itu benar
    Namun hasil akhirnya tetap masalah besar
    Bagian yang mengejutkan di sini adalah “mount namespace terpisah”
    Dulu, jika membuka shell lalu melakukan mount ke filesystem atau mengubahnya langsung, aplikasi akan membaca file dari mount itu tanpa masalah
    Sekarang tidak demikian untuk file cacert ini, dan dengan cara baru perubahan langsung juga tidak mungkin
    Sampai perubahan ini, saya bahkan tidak tahu bahwa aplikasi Android memakai mount namespace sendiri
    Hampir tidak ada dokumentasi tentang cara kerjanya secara persis, dan saya juga tidak yakin apakah sebelumnya pernah ada kasus yang memperlihatkannya sejelas ini
  • Teknologi sangat nyaman ketika sudah cukup kompleks untuk menemukan dalih yang sesuai dengan tujuan bisnis
    Lihat saja manifest v3

• Saya sudah membalas penulis di Twitter, tetapi mungkin tidak terlihat, jadi saya tinggalkan juga di sini
  Saya orang yang menulis artikel blog tentang sertifikat yang dapat diperbarui di Android 14, dan artikel itu ditautkan dalam berita tersebut
  Sebenarnya ada properti sistem yang bisa diatur untuk melewati pembacaan dari direktori sertifikat APEX
  system.certs.enabled=true
  Sumber: https://android-review.googlesource.com/c/platform/framework...

  • Sayangnya, sepertinya itu tidak akan banyak membantu
    Itu adalah properti OS android.os.SystemProperties, jadi bukan nilai yang bisa diatur secara global di perangkat lewat adb, melainkan properti java.lang.System, dengan kata lain nilai konfigurasi yang disetel di dalam satu JVM/aplikasi
    Menurut saya, untuk mengatur ulang yang pertama, aplikasinya sendiri harus dimodifikasi
    Itu berguna untuk pengujian otomatis atau untuk mengubah setelan antara build debug/prod, tetapi tidak banyak membantu jika ingin membuat seluruh perangkat memercayai sertifikat CA
    Tentu saja, kalau Anda tahu cara mengatur properti seperti itu dari luar dan menerapkannya ke semua aplikasi, itu pasti akan bekerja sangat baik, jadi saya sangat ingin mendengarnya
    Sebagai catatan, saya penulisnya, dan saya tidak melihat balasan seperti itu di Twitter
    Memang Twitter tahun 2023 sekali

• Ini terlihat bagus untuk keamanan dan seperti neraka bagi sebagian developer, tetapi saya bertanya-tanya apa yang terjadi ketika versi Android ini ditinggalkan 2–3 tahun lagi
  Apakah kita harus berdoa agar sertifikat yang di-hardcode bertahan beberapa tahun lagi

  • Ini adalah masalah yang sudah diketahui dan sudah lama seharusnya dipertimbangkan oleh penyedia sertifikat [0], tetapi mulai Android 14 tampaknya tidak lagi begitu [1]
    Android 14 membuat sertifikat root dapat diperbarui melalui Google Play, dan tidak lagi memerlukan pembaruan OTA untuk menambah atau menghapus sertifikat root seperti dulu
    Ada juga solusi bypass yang baru saya ketahui hari ini [0]
    Katanya, jika memakai Android 7.0 atau lebih rendah, Anda mungkin perlu mengambil tindakan agar tetap bisa mengakses situs web yang diamankan dengan sertifikat Let’s Encrypt, dan disarankan memasang serta menggunakan Firefox Mobile, yang memakai trust store sendiri alih-alih trust store Android OS
    [0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
    [1] https://www.xda-developers.com/android-14-root-certificates-...
  • Saya harus memasang sertifikat Let’s Encrypt agar password manager yang saya host sendiri bisa berjalan
    Karena pembaruan Google tidak menyertakan sertifikat perantara yang digunakan Let’s Encrypt
    Ini bukan masalah hipotetis di masa depan, melainkan masalah yang ada sekarang juga
    Mengapa Google harus menjadi penentu akhir soal siapa yang saya percayai
    Google jelas juga punya celah
    Dan di antara penyedia sertifikat yang sudah disetujui pun, ada yang sebenarnya tidak boleh dipercaya karena punya riwayat menerbitkan sertifikat kepada orang dan organisasi yang seharusnya tidak mendapatkannya
  • Istri saya harus mengganti ponselnya karena alasan itu persis
    Aplikasi umumnya tidak menerima sertifikat pengguna, dan ketika Google Cloud atau sesuatu yang terkait dengannya beralih ke sertifikat yang lebih baru, sebagian aplikasi mulai berhenti berfungsi
  • Sertifikat kini menjadi modul APEX, dan justru itulah inti keluhan penulis
    Artinya, sertifikat diperbarui di luar jalur melalui Play Services dan tidak memerlukan pembaruan OS dari OEM
  • Mulai Android 14, sertifikat bisa diperbarui lewat Google Play, jadi tidak terikat pada pembaruan OS

• Setiap kali rilis Android baru keluar, saya melihat ada sesuatu yang dihapus dan hal-hal yang tidak terlalu berarti ditambahkan
  iOS tampaknya bergerak ke arah sebaliknya, jadi sepertinya perlahan keduanya akan bertemu di tengah, lalu nantinya iOS mungkin melampaui Android dalam segala hal
  Saya ingin mendengar pendapat jujur dari orang-orang di pihak Apple
  Belakangan ini saya memakai macOS, dan saya tidak suka karena gagal pada pengalaman pengguna yang sangat mendasar, yang sudah dianggap wajar di Windows/Linux sejak puluhan tahun lalu
  Hal seperti Finder benar-benar buruk
  Jika di generasi berikutnya saya membeli iPhone alih-alih Android, apakah saya juga akan bereaksi negatif yang sama terhadap iOS
  Untuk use case smartphone, apakah iOS bisa dianggap sebagai pengalaman pengguna yang lebih matang dan berguna daripada macOS
  Saya memang ingin pindah, tetapi tidak ingin membuang waktu dan uang

  • Jika batasan App Store hilang dan sideloading aplikasi menjadi mudah, rasanya saya tidak bisa memikirkan satu pun keunggulan Android dibanding iOS
    Android dulu bukan sekadar iOS yang punya .apk, jadi ini sungguh disayangkan
  • Saya memakai iPhone hanya untuk scrolling HN di pagi hari, sebagai pemutar audio portabel, mencari macam-macam saat bepergian, dan menelepon
    Untuk kegunaan itu, ponsel ini oke
    Namun pengguna terlalu dibatasi, jadi mungkin saya bisa mencari tahu soal jailbreak, tetapi saya berusaha meminimalkan penggunaan ponsel dan melakukan hampir semua hal di desktop
    Sebagai catatan, saya juga sedang meninggalkan macOS dan pindah ke Linux
  • Ada kebijakan pengembalian barang, jadi coba saja dengan operator prabayar seperti Mint

• Saya memakai PKI pribadi untuk mengakses perangkat lunak yang saya host sendiri
  Hal-hal seperti server email, penyedia kalender, server catatan, dan alat sinkronisasi foto
  Saya harus bisa menambahkan sertifikat root saya ke daftar otoritas sertifikat
  Saya bukan ingin mengubah daftar yang disediakan sistem, hanya ingin menambahkan sertifikat saya sendiri
  Karena ini perangkat saya, menurut saya saya seharusnya bisa mengubah apa pun yang saya mau

  • Anda bisa memasang sertifikat CA sendiri di penyimpanan sertifikat pengguna, dan Chrome serta aplikasi lain yang memilih untuk memercayai CA yang dipasang pengguna akan memercayainya
    Kemungkinan besar aplikasi email dan kalender juga termasuk di dalamnya
    Yang kemungkinan besar tidak bisa adalah memasang CA sendiri untuk menyadap lalu lintas antara aplikasi dan server pembuat aplikasi
    Itu memang disayangkan, karena kita seharusnya bisa memeriksa apa yang dilakukan perangkat sendiri, tetapi kasus penggunaan PKI pribadi untuk perangkat lunak yang di-host sendiri jelas didukung
  • Saya juga begitu, bukankah kebijakan TI perusahaan juga banyak menyebarkan sertifikat root ke perangkat?
    Sepertinya harus ada suatu cara
  • Salah satu alternatif adalah memakai CA publik di jaringan privat
    getlocalcert sedang membuat alat untuk ini [1]
    Karena bisa menghindari kebutuhan menambahkan root kepercayaan, di sebagian jaringan pendekatan “sertifikat publik di atas jaringan privat” secara keseluruhan menguntungkan
    Jujur saja saya tidak menyangka Android akan memblokir CA privat, tetapi akhirnya memang begitu
    [1] https://www.getlocalcert.net/
  • Saya juga bingung soal bagian itu
    Saya tidak memakai ponsel Android sekarang, tetapi dulu saya ingat bisa menambahkan sertifikat CA sendiri ke ponsel Android hanya lewat opsi di pengaturan tanpa akses root, dan setidaknya aplikasi seperti browser web memercayainya
    Itu juga bukan cerita dari zaman yang sangat lama
    Jadi saya tidak mengerti mengapa memasang sertifikat kustom membutuhkan rooting perangkat; apakah itu untuk penggunaan lain

• HTTP Toolkit sangat berguna untuk mengekstrak API tersembunyi dari aplikasi pengisian daya mobil listrik Turki yang buruk
  Saya juga memakai Frida untuk mencegah SSL pinning dan deteksi root
  Lalu saya menyadari bahwa alasan mereka ingin menyembunyikan API itu mungkin karena API-API tersebut memang monster /s