Android 14, root yetkisiyle bile sistem sertifikası değişikliklerini engelliyor mu?

• Android 14 (API v34), sistem CA sertifikalarını /system yerine APEX tabanlı com.android.conscrypt modülünden okuyacak şekilde değiştirerek, sertifikaları root yetkisiyle enjekte etmeye dayanan mevcut hata ayıklama akışlarını bozuyor
• Android 7 Nougat’tan sonra uygulamaların varsayılan güven deposu sistem CA’ları ve kullanıcı CA’ları olarak ayrılınca, geliştirme, test ve tersine mühendislik araçları sistem CA dizinini doğrudan değiştirme yöntemine dayanıyordu
• Yeni yapı, CA sertifikalarının Google Play System Update ile güncellenmesini sağlayarak sorunlu CA’ların kaldırılmasını ve yeni CA’ların dağıtımını hızlandırıyor; ancak cihaz sahibinin kontrolünü azaltıyor
• Android 14 beta emülatöründe /system/etc/security/cacerts, /system/etc/security/cacerts_google, /apex/com.android.conscrypt/cacerts gibi yollar tmpfs ile örtülse veya silinse bile Settings ve uygulamalar Google CA listesini görmeye devam ediyor
• Yazının yazıldığı sırada Android 13’te kalmak veya APEX kullanmayan özel bir OS gerçekçi alternatifti; daha sonraki güncellemelerde ise Android 14 sertifika enjeksiyonu için birden fazla atlatma yöntemi ortaya çıktığı belirtiliyor

---

Android CA yönetiminin değişim süreci

• Android, 2007’de Open Handset Alliance duyurusu sırasında “open platform”, “complete access to handset capabilities and tools” gibi ifadelerle açıklığı vurgulamıştı
• Zaman içinde kullanıcıların, geliştiricilerin ve araştırmacıların kendi cihazlarını kontrol edebildiği alanın giderek daraldığı değerlendiriliyor

• Android 7 Nougat ile dönüşüm

  • Cihaz sahibinin değiştirebildiği CA listesi sistem CA’ları ve kullanıcı CA’ları olarak ayrıldı
  • OS üreticisinin sağladığı sabit sistem CA listesi tüm uygulamalar için varsayılan hâle geldi
  • Kullanıcının değiştirebildiği CA listesi yalnızca uygulama açıkça opt-in yaptığında kullanılmaya başladı
  • Sonuç olarak neredeyse tüm uygulamalar kullanıcı CA’larını varsayılan olarak güvenilir kabul etmemeye başladı

CA sertifikaları neden önemli?

• Cihazın güvendiği CA’lar, şifreli ağ trafiğinin güvenliğini garanti eden kuruluşların listesidir
• CA’lar, HTTPS gibi TLS bağlantılarında kullanılan sertifikaları herhangi bir alan adı için düzenleyebilir; o CA’ya güvenen cihazlar da bu sertifikayı normal bir bağlantının kanıtı olarak kabul eder
• Kullanıcının kendi oluşturduğu bir CA’yı cihaza güvenilir olarak eklemesi, kendi HTTPS veya TLS trafiğini araya girerek görmesini sağlar
  • Telefonun gönderdiği ve aldığı veriler incelenebilir
  • Gerekirse değiştirilebilir veya engellenebilir
• Bu kontrol güvenlik ve gizlilik araştırmaları, tersine mühendislik, uygulama hata ayıklama ve testleri, kurumsal iç ağ ayarları ve varsayılan CA’lara güvenmeyen kullanıcılar için önemlidir
• Teknik olmayan kullanıcıların yanlışlıkla CA değiştirmesini zorlaştırmak veya kullanıcıdan habersiz değişiklik yapılmasını engellemek makuldür; ancak ileri seviye kullanıcıların kontrolünü de sınırlamak birçok kullanım senaryosunu zorlaştırır

Android 7 sonrası root tabanlı atlatma yöntemi

• Android 7’den sonra da root yetkisi alınmış cihazlarda sistem CA deposu doğrudan manipüle edilebiliyordu
• En yaygın yöntem, güvenilecek sertifikayı /system/etc/security/cacerts/ içine koymaktı
• /system, root’lu cihazlarda bile genellikle salt okunur olduğundan iki yöntem kullanılıyordu
  • /system dizinini yazılabilir olacak şekilde yeniden yapılandırıp yeniden başlattıktan sonra gerçek sistem sertifika dizinini değiştirmek
  • Salt okunur dizinin üzerine geçici bir okuma/yazma dosya sistemi mount edip mevcut CA’ları kopyaladıktan sonra yeni sertifikayı eklemek
• Sertifikanın sistem tarafından kabul edilmesi için dosya adı, izinler ve SELinux etiketi gibi koşulların da doğru olması gerekiyordu
• HTTP Toolkit, geçici mount tabanlı prosedürü otomatikleştirerek root’lu Android cihazlarda veya emülatörlerde tek tıkla interception kurulumu sunuyordu
• Bu yaklaşım, özel root’lu cihazlarda, özel Android dağıtımlarında ve Google’ın resmi emülatör imajlarının çoğunda çalışıyordu
  • Normal OEM cihazlar gibi kilitli tam “Google Play” edition imajları bunun istisnasıydı
• mitmproxy kurulum belgeleri, çeşitli blog yazıları, StackOverflow yanıtları, forum gönderileri, Magisk paketleri ve cacert.org yönergeleri de benzer bir yöntem kullanıyordu

Android 14’ün yeni CA güncelleme yapısı

• Android 14, yazının yazıldığı sırada son beta aşamasındaydı ve birkaç hafta içinde yayınlanması bekleniyordu
• Başlıca güvenlik özelliklerinden biri uzaktan güncellenebilir CA sertifikaları idi
• CA sertifikası yönetimi çekirdek OS imajından ayrılarak, Google Play üzerinden dağıtılıp güncellenen ayrı bir bileşene taşındı
• Bu yapıda Google, sorunlu CA’lara duyulan güveni daha hızlı geri çekebiliyor
  • Her telefon üreticisinin tam OS OTA güncellemesi dağıtmasını bekleme ihtiyacı azalıyor
  • Yalnızca Google Play System Update ile Android 14+ cihazların CA listesi değiştirilebiliyor
• Varsayılan güvenilir CA’lar güçlü yetkilere sahip olduğundan denetim ve yaptırım gerekir; başarısız olan CA’ların yetkileri de hızla kaldırılmalıdır
• Örneğin Ocak 2023’te TrustCor, kötü amaçlı yazılım dağıtan yapılar ve ABD savunma/istihbarat yüklenicileriyle yakın ilişkileri ortaya çıktıktan sonra Google dâhil büyük aktörler nezdinde CA güvenini kaybetti
• Tersine, yeni CA dağıtımının gecikmesi de sorun yaratır
  • Let’s Encrypt, eski Android cihazlarda güncel kök CA bulunmadığı için imza zinciri iyileştirmelerinin dağıtımını birkaç kez ertelemek zorunda kaldı
• CA güncellemelerinin tepki hızını artıran yapı kendi başına değerli olsa da Android 14 uygulaması sistem CA’larını değiştirmeyi fiilen zorlaştırıyor

Gerçek dosya konumu ve APEX davranışı

• Android 14’teki temel değişiklik, mevcut /system/etc/security/cacerts yerine /apex/com.android.conscrypt/cacerts varsa sertifikaların buradan okunmasıdır
• /apex, Android Pony EXpress, yani APEX container’larının mount edildiği yoldur
• APEX modülleri bağımsız olarak güncellenebilen sistem bileşenleridir ve imzalı, değiştirilemez container’lar olarak dağıtılır
• Android 14’te CA sertifikaları, Android’in çekirdek TLS/SSL kütüphanesi olan com.android.conscrypt modülünün bir parçası hâline gelir
• APEX’in düşük seviyeli işleyişi yeterince belgelenmemiştir ve bazı kritik ayrıntı bağlantılarının yalnızca Google iç sitelerinde olduğu söylenir
• Test sonuçları, APEX modülü içeriklerinin tek tek süreçlere doğrudan açıldığı ve başka konumlardaki dosyalar değiştirilse bile uygulamaların gördüğü içeriğe bunun yansımadığı bir davranış gösterdi

Android 14 emülatöründe gözlemlenenler

• Android 14 beta resmi emülatörünün AOSP ve “Play Services” imajlarında root erişimi mümkündür
  • “Google Play” imajları normal OEM cihazlar gibi kilitlidir
• API 34 “Google APIs” imajıyla emülatör oluşturup root shell açılabilir
• Mevcut geçici mount yöntemiyle aşağıdaki yollar tmpfs ile örtüldüğünde de beklenen etki görülmedi
  • /system/etc/security/cacerts
  • /system/etc/security/cacerts_google
  • /apex/com.android.conscrypt/cacerts
  • /apex/com.android.conscrypt@340818022/cacerts
• Settings → Security & Privacy → More → Encryption → Trusted Credentials içindeki “System” sekmesinde, gizlendiği düşünülen sertifikalar aynen görünmeye devam etti
• Örneğin “ACCV” sertifika dosyası 3c9a4d3b.0 tüm dosya sisteminde arandığında, mount ile gizlendiği sırada görünmüyordu; ancak Settings’te görünmeye devam ediyordu
• Aynı prosedür Android 13 imajında uygulandığında Settings’teki sertifika listesi boştu; yani mevcut yöntem beklendiği gibi çalışıyordu

Sistem imajını doğrudan değiştirmek de başarısız

• Android 14 emülatörü -writable-system ile başlatılıp adb root, adb remount, avbctl disable-verification, yeniden başlatma gibi adımlardan sonra yazılabilir hâle getirilebiliyor
• Sonrasında /system/etc/security/cacerts/*, /system/etc/security/cacerts_google/* içindeki sertifikalar silinebiliyordu
• Ancak /apex içindeki sertifikalar silinemiyordu
  • remount sonrası bile salt okunur kalıyorlardı
  • mount -o remount,rw ... komutu da başarısız oluyordu
• Yapılabilen en yakın müdahale, ilgili sertifika yolunu umount ederek mount çıktısında görünmez kılmaktan ibaretti
• Buna rağmen Settings’teki “Trusted” listesinde CA sertifikaları yüklenmeye devam ediyordu
• Bunun Settings uygulamasının önbellek sorunu değil, uygulamaların gördüğü sertifika deposu açısından da aynı davranış olduğu değerlendiriliyor
• Dosya sistemi nasıl değiştirilirse değiştirilsin, uygulamaların Google’ın CA listesini görmeye devam ettiği ortaya çıktı

Etkiler ve sınırlamalar

• Android 14’te sistem CA sertifikası yükleyerek hata ayıklama, tersine mühendislik, test ve araştırma yapmaya dayanan mevcut akış bozuluyor
• Yazının yazıldığı tarih itibarıyla alternatifler Android 13’te kalmak veya CA sertifikası yönetiminde APEX modülü kullanmayan özel bir OS sürümü kullanmaktı
• Zaman geçtikçe Android Mainline’ın çekirdek iç bileşenlerinden ayrışmak veya eski yazılımları kullanmayı sürdürmek gerekeceğinden, bu alternatifler giderek daha az pratik hâle gelebilir
• APEX modülü içindeki içerik root yetkisiyle bile değiştirilemiyorsa, gelecekte APEX’e taşınan her sistem bileşeniyle kullanıcı kontrolü azalabilir
• GrapheneOS, LineageOS gibi Android fork’ları ile Magisk ve çeşitli modüller için de sorun oluşturabilir
• Ancak üstteki güncellemeye göre, daha sonraki tartışmalar ve atlatma araştırmaları sonucunda Android 14’te de sertifika enjeksiyonunu mümkün kılan çeşitli çözümler ortaya çıktı
• Android 14’te HTTPS trafiğinde hata ayıklama yaparken yalnızca mevcut root tabanlı sistem CA enjeksiyonunu varsaymak zorlaşıyor

[GN⁺]

Hacker News görüşleri

• Eski Android root araçları ve modern genel amaçlı özel ROM'lar üzerinde, ayrıca Android OS ile ilgili çeşitli işler yapmış biri olarak başlığın hem şimdi hem de gelecekte yanlış olduğunu düşünüyorum
  Android'de root dediğimiz şey gerçekten root yetkisidir; istediğiniz her şeyi yapabilirsiniz [1]
  Günümüzdeki Android root aracı Magisk, Java kodunu bile “değiştirme” işlevi içeriyor; dolayısıyla derinlerde saklı olsa bile erişebilmesi gerekir
  Yazarın yapamamış olması bunun imkânsız olduğu anlamına gelmez; zygote CA'ları önbelleğe aldığı için stop;start ile yeniden başlatmak gerekmesi ya da komutu çalıştırmadan önce doğru mount namespace'ine geçmek gerekmesi gibi bir sorun olabilir
  GrapheneOS ve LineageOS tüm kaynak koda erişebildiği için istedikleri gibi değiştirebilirler; tek kısıt, Google'ın inanılmaz bir hızla bozduğu şeylere yetişmenin zahmetli olması
  Android kullanıcıya, özellikle de power user'lara giderek daha düşmanca hâle geldikçe daha fazla kişinin özel ROM'lara geçmesini umuyorum
  Rüyamda, güvenlik modelinin ilk satırı “kullanıcı düşmandır” olmayan “OwnerDroid” gibi bir Android fork'u yapıyorum; ama birkaç küçük tuğla üretmiş olmak dışında tüm proje muazzam miktarda iş gerektiriyor
  [1] Bazı çekirdek düzeyi korumalar bunun istisnası, ancak GKI bu riski azaltıyor

  • Asıl nokta şu: Eskiden Google'ın stok OS imajlarında bile hiçbir araç kurmadan yalnızca diske yazarak herkes bu sertifikayı doğrudan değiştirebiliyordu; bu yöntem yaygın kullanılıyordu ve birçok aracın kurulum kılavuzunda da yer alıyordu
    Artık bunu yapmak mümkün değil
    Elbette tüm kaynak kod sizdeyse her şey mümkün; bu modülü devre dışı bırakmış bir Android sistem imajını sıfırdan derleyebilirsiniz, GrapheneOS/LineageOS da buna uyum sağlayabilir
    Ancak çok fazla yeni iş çıkıyor ve temel bileşenlerde Android uygulamasından ayrışırsanız ileride daha fazla bakım gerektirebilir
    Etkilenen kullanıcıların büyük çoğunluğu için “önce sistem imajını kendin derle” demek, konfor alanlarının ve ayırabilecekleri zamanın çok ötesinde
    Sonunda başka çözümler çıkacaktır; ama bunlar namespace'lerin içine dalıp hedef sürecin mount'larını tek tek değiştirmek, Android'in güvendiği şekilde kendi APEX modülünü derleyip kurarak sistem modülünün yerine geçirmek ya da Frida ile tek tek uygulamalara hook atmak gibi şeyler olacak
    Yine de kullanıcının kendi cihazını tamamen kontrol etmesini zorlaştıran büyük bir sorun
  • Özel ROM'larla uğraşmayı bir noktada bırakmış olanlar ne yapacak, merak ediyorum
    Zorunlu banka uygulamalarının root kontrolleri veya Google ile ilgili işlevler gibi kritik kısımlar belgelenmemiş durumda; “telefon modeli + yerel banka uygulaması + özel ROM” kombinasyonunun test edilip düzgün çalıştığına dair bilgi bulmak da neredeyse imkânsız
    Özgürlük ve seçimden yanayım, ama ortalama bir telefon kullanıcısının birkaç telefon ve günlerce mesai harcamadan ya da zaten uzman değilse bunu gerçekçi bir davranış biçimi olarak görmek zor
    Bilgisayarda power user'ım, ama telefonun daha aptal olmasında sakınca görmüyorum
    Ancak telefonu giderek daha fazla çok faktörlü kimlik doğrulama cihazı olarak kullanmak zorunda kalınca ya da bankalar gibi daha güçlü kaldıraçlara sahip şirketlerin kaprislerine bağlanınca bunu yapmak zorlaşıyor
    Root'lu telefonda çalışan bir uygulama bulmak için banka hesabımı üç kez değiştirmeyi düşünmüyorum
  • Google'ın inanılmaz bir hızla bir şeyleri bozup başkalarını yetişmeye zorlaması, rakipleri yetişmekle meşgul tutma stratejisi: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
    “Android fork'u nasıl rakip olabilir ki?” diye soruyorsanız, bu stratejinin işe yaradığı anlamına gelir
  • Makaleyi sadece üstünkörü tarayınca, atlatmanın kendisi epey kolay görünüyor
    Yeni yöntem /apex/com.android.conscrypt/cacerts varsa sertifikaları oradan okuyorsa, mevcut SafetyNet atlatma, root gizleme veya Magisk gizleme yöntemlerinde olduğu gibi yalnızca gerekli süreçlerde /apex/com.android.conscrypt/cacerts yolunu gizleyip eski yönteme fallback yaptırmak mümkün olabilir
  • Özel ROM'ların, Google ya da Apple ne kadar kötü davranırsa davransın ana akım olacağını sanmıyorum
    Hacker'ların alanı; onların içinde bile çok küçük bir kesimin kullandığı bir şey

• Burada çok iyi yorumlar var ama PC'lerin akıllı telefonlar gibi çalışmamasının ne kadar büyük bir şans olduğunu düşünmeden edemiyorum
  Android kendini öyle kapsamlı biçimde mahvetti ki, Microsoft'un PC dünyasını Google'ın akıllı telefon dünyasını yönettiği gibi yönetmemesine şükrettiğimi söylemek bana bile tuhaf geliyor
  Windows'un kendisi Android'e kıyasla neredeyse bir istikrar ve sağduyu kalesi; donanım gerçekten eskilikten arızalanana kadar yükseltmeye zorlanmanız da gerekmiyor
  Microsoft da Google gibi donanım-yazılım hattının tamamını kontrol etmiyor; ama mağaza üzerinden normları dayatma veya SafetyNet benzeri yöntemlerle ortam değişikliklerini caydırarak PC sahipliğini aşırı zahmetli hâle getirme gücüne sahipti
  Microsoft'un geçmişte böyle şeyler yüzünden antitröst davasına uğrayıp uğramadığını net hatırlamıyorum; Google'ın başına da aynısının ne zaman geleceğini merak ediyorum

  • Windows yaklaşık 20 yıldır düzenli CA güncellemeleri yapıyor; bu noktada aslında Android, Windows gibi davranıyor
    Microsoft da Windows'a çok sayıda DRM ekledi, sonra bunlardan bazılarını kırdı; uzaktan attestation da OS'e yerleşik
    Google, aslında güvenilmemesi gereken Android iç uygulamasını değiştirip geliştiricileri rahatsız etmiş; Microsoft da böyle şeyleri sürekli yapar
    Güncellenmiş bir Magisk modülü için birkaç hafta beklemek yeterli olacak gibi duruyor ve açıkçası o kadar da kötü değil
    Android 14 alacak 5-6 cihazda o zamana kadar güncelleme düğmesine basmamak yeterli
  • Microsoft da denedi ama sadece başarısız oldu; hâlâ da denemeye devam ediyor
    Windows 11 TPM ve Secure Boot gerektiriyor
  • Bunun kullanıcıya faydası da olabilir diye düşünüyorum
    Bazı gelişmekte olan ülkelerin tüm bağlantılara ortadaki adam saldırısı yapmak için ulusal CA kurulmasını istediğini duymuştum; bunu çok zorlaştırmak, kullanıcının kendi gizliliğini kapatmasını sağlama işini pratikte zorlaştırır

• PinePhone Pro’yu günlük ana cihazım olarak kullanıyorum.
  Chase.com, Librewolf gibi standart dışı tarayıcıları ve telefon/tablet tarayıcılarının kullanımını gerçekten ısrarla engellemeye çalışıyor; mobil uygulamayı kullanmaya zorluyor.
  En azından WEI zorunlu hâle gelene kadar bu tür aptalca önlemler kolayca aşılabildiği için ciddi bir sorun değil, ama Chase bir banka olduğundan hukuken tartışılabilecek bir tarafı var mı merak ediyorum.
  İlk tahminim ADA uyumluluğu tarafı, ama emin değilim.
  Artık o kadar yoruldum ki, bu konuda dava açmak istiyorum dememin boş laf olup olmadığından bile emin değilim.
  Bir yan konu olsa da, mobil OS oligopolisinden çıkmanın neredeyse imkânsız olduğuna dair başka bir yüzünü gösterdiği için ilgili.
  Linux telefon nişi mucizevi biçimde birkaç yüzde puana kadar büyüse bile Android büyük olasılıkla kötüleşmeye devam edecek ve bir şeye ihtiyaç var.

  • Karanlık çağ geliyor, ciddiyim.
    Dijital serflik çağının geleceğini düşünüyorum.
    “Hayırsever” bir şirketin sağladığı cihazı kullanacağız; o şirket cihazın her yönüne sahip olacak ve ancak para ödeyerek, araba sürer gibi kullanabileceğiz.
    Diğer yolların çoğu kilitlenecek, genel amaçlı bilişim yalnızca “kurumsal” olarak kalacak ve “özgür web” var olacak ama epey teknik ve kullanıcıya düşmanca olacak.
    Pazarın büyük çoğunluğu, özellikle de parayla ilgilenen her yer, ondan veba gibi kaçacak.
  • Chase müşterisi olarak kalmaya devam ederseniz onların yağmacı tutumunu desteklemiş ve sektörün geri kalanına da aynı tutumu takınmanın sorun olmadığı sinyalini vermiş olursunuz.
  • “En azından WEI zorunlu hâle gelene kadar” kısmı üzücü.
    Google’ın bununla açık web’i öldürdüğünü düşünüyorum.
    Zaten biraz sıkıcılaşmaya başlamıştı, ama artık telefon ya da “onaylı” tarayıcı olmadan yaşamanın çok daha zorlaşması can sıkıcı.
  • Yalnızca alternatif tarayıcılarda bulunan erişilebilirlik özelliklerine ihtiyacınız varsa Chase ile iletişime geçmeniz iyi olur.
    Deneyimli bir kullanıcının ek yazılım kurup sorunu düzeltebilmesi güzel, ama Chase’in temel web sitesini düzeltip benzer ihtiyaçları olan acemi kullanıcıların da yardım almasını sağlaması daha iyi olur.

• Bu konuda Android’in Apple’dan daha zorlayıcı olduğunu ve hâlâ öyle olduğunu düşünüyorum.
  Yeni bir kök CA kurulup güvenilir sayılabildiği dönemde bile bazı uygulamalar bunu yok sayabiliyordu ve gerçekten de yok sayıyordu.
  iOS ve Android’in ikisinde de uygulamalar sertifika sabitleme kullanabilir, ancak Android 7+’da 2016’dan beri uygulamalar varsayılan olarak kullanıcının eklediği CA’ları yok sayıyor[1].
  iOS’ta bir kök CA’ya güvenme süreci profil kurulumu ve korkutucu uyarılardan geçecek şekilde zahmetli; bu başlı başına makul, ama deneyimime göre çoğu uygulama sertifika sabitleme kullanmadığı sürece buna güveniyor.
  [1]: https://android-developers.googleblog.com/2016/07/changes-to...

  • Google’ın Android 7’de bunu neden yaptığını anlıyorum.
    iOS’a kıyasla genel amaçlı bir bilgisayara çok daha yakın olan Android’de stalkerware sorunu çok büyük.
    Stalkerware istemlerle engellenmiyor, geriye dönük uyumluluğu silah hâline getiriyor ve her tür istismarı içeriyor.
    iOS’ta birine telefonu 5 dakikalığına ödünç verdikten sonra HTTPS gizliliğinin yıllarca tersyüz edilmesi şaşırtıcı derecede kolay.
    Kurulan CA sertifikalarına gerçekten güvenebilme seçeneğini istiyorum, ama özellikle bir web tarayıcısı olan Firefox’un bile gizli sekme kombinasyonları ve ayarlar olmadan kullanıcı sertifikalarını kullanmaması sinir bozucu.
    Yine de dünya genelindeki Android kullanıcıları için doğan riski düşününce, bu özelliğin günlük kullanımda birkaç düzine teknisyen için aynı derecede önemli olduğunu söylemek zor.
    Bu olayın, yerel BT departmanının planını engellemeye çalışan kötü niyetli bir Google komplosundan ziyade, Google’ın iyi sandboxing iyileştirmelerinin ve uzun süredir gecikmiş CA deposu güncelleme mekanizmasının bir yan etkisi olduğunu düşünüyorum.
    Magisk modülü yakında bir geçici çözüm olarak çıkar; mevcut modül bir süre bozulacaktır ama büyük Android güncellemelerinden sonra bu yaygın bir şey.
    Gerekirse modülü kendiniz de yazabilirsiniz.
  • iOS’ta VPN bağlantısını yok sayabilen uygulamalar da var: https://restoreprivacy.com/latest-ios-found-to-bypass-vpn-co...

• Bu sadece mount’un çalışma biçimi değil mi diye düşünüyorum.
  /apex/whatever üzerine bir şey mount edilmişse ve her uygulamanın ayrı bir mount ad alanı varsa, kendi ad alanınızda /apex/whatever üzerine tekrar mount etseniz de diğer ad alanlarında hiçbir şey değişmez.
  Dosya sistemini doğrudan değiştirmeniz ya da diğer uygulamanın mount ad alanına girip orada da tmpfs mount etmeniz gerekir.
  Paylaşımlı mount yardımcı olabilir ama emin değilim; gerçekte ne olduğunu daha ayrıntılı görmek gerekir.
  Bu sonucun, kullanıcıların root yetkisiyle bile kök CA’yı değiştirmesini engellemeye yönelik kasıtlı bir girişimden ziyade, Google’ın ad alanı/konteynerleştirme çalışmalarının bir yan ürünü olma ihtimalinin daha yüksek olduğunu düşünüyorum.

  • Aslında bunun doğru olduğunu düşünüyorum.
    Ama nihai sonuç hâlâ büyük bir sorun.
    Buradaki şaşırtıcı kısım “ayrı mount ad alanı”.
    Eskiden bir shell açıp dosya sistemine mount eder ya da doğrudan değiştirirseniz uygulamalar o mount’tan dosyaları sorunsuz okurdu.
    Artık bu cacert dosyaları için böyle değil ve yeni yöntemde doğrudan değiştirmek de imkânsız.
    Bu değişiklikten önce Android uygulamalarının kendi mount ad alanlarını kullandığını bile bilmiyordum.
    Tam olarak nasıl çalıştığına dair belge neredeyse yok ve bugüne kadar bunun böyle açıkça ortaya çıktığı bir örnek var mıydı, ondan da pek emin değilim.
  • Teknoloji, iş hedeflerine uyan bahaneler bulacak kadar karmaşık olduğunda çok kullanışlı oluyor.
    manifest v3’e bakın.

• Yazara Twitter’da yanıt bıraktım ama görmemiş olabilir diye buraya da bırakıyorum
  Android 14’ün güncellenebilir sertifikaları hakkında blog yazısını yazan kişiyim; söz konusu yazı makalede bağlantı olarak verilmiş
  Aslında APEX sertifika dizininden okumayı atlayacak şekilde ayarlanabilen bir sistem özelliği var
  system.certs.enabled=true
  Kaynak: https://android-review.googlesource.com/c/platform/framework...

  • Ne yazık ki çok yardımcı olacağını sanmıyorum
    Bu, android.os.SystemProperties OS özelliği, yani adb ile cihaz genelinde ayarlanabilen bir değer değil; java.lang.System özelliği, başka bir deyişle tek bir JVM/uygulama içinde ayarlanan bir yapılandırma değeri
    Bana göre ilkini yeniden ayarlamak için uygulamanın kendisini değiştirmek gerekir
    Otomasyon testleri için ya da debug/prod derlemeleri arasında ayarı açıp kapatmak için yararlı olabilir, ama cihaz genelinde CA sertifikalarına güvenilmesini istediğinizde pek işe yaramaz
    Elbette böyle bir özelliği dışarıdan ayarlayıp tüm uygulamalara uygulamanın bir yolunu biliyorsanız gerçekten iyi çalışır; duymayı çok isterim
    Bu arada yazar benim ve Twitter’da böyle bir yanıt görünmüyor
    2023 Twitter’ına yakışır şekilde

• Güvenlik için iyi görünüyor ve bazı geliştiriciler için cehennem gibi olabilir; ama bu Android sürümü 2-3 yıl sonra terk edilince ne olacak merak ediyorum
  Hardcode edilmiş sertifikaların birkaç yıl daha dayanması için dua mı etmek gerekecek

  • Bu, sertifika sağlayıcılarının uzun zamandır hesaba katması gereken bilinen bir sorundu [0], ama Android 14’ten itibaren artık öyle değil gibi görünüyor [1]
    Android 14, kök sertifikaları Google Play üzerinden güncellenebilir hale getiriyor; eskisi gibi kök sertifika eklemek veya kaldırmak için OTA güncellemesi gerekmiyor
    Bugün öğrendiğim bir geçici çözüm de var [0]
    Android 7.0 veya daha eski bir sürüm kullanıyorsanız Let’s Encrypt sertifikasıyla korunan web sitelerine erişmeye devam etmek için işlem yapmanız gerekebilir; Android OS güven deposu yerine kendi güven deposunu kullanan Firefox Mobile’ı kurup kullanmanız öneriliyormuş
    [0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
    [1] https://www.xda-developers.com/android-14-root-certificates-...
  • Kendi barındırdığım parola yöneticisini çalıştırmak için Let’s Encrypt sertifikası yüklemem gerekti
    Çünkü Google güncellemesinde Let’s Encrypt’in kullandığı ara sertifika yoktu
    Bu geleceğe dair varsayımsal bir sorun değil, şu anda var olan bir sorun
    Neden kime güveneceğimin nihai hakemi Google olmalı?
    Google’ın da elbette açıkları var
    Ayrıca zaten onaylı sertifika sağlayıcıları arasında da, sertifika almaması gereken kişi ve kuruluşlara sertifika vermiş geçmişleri olduğu için gerçekte güvenilmemesi gerekenler var
  • Eşim tam da bu nedenle telefonunu değiştirmek zorunda kaldı
    Uygulamalar genelde kullanıcı sertifikalarını kabul etmiyor ve Google Cloud ya da onunla ilgili bir şey daha yeni bir sertifikaya geçince bazı uygulamalar çalışmayı bırakmaya başladı
  • Sertifikalar artık bir APEX modülü oldu; yazarın şikâyetinin özü de tam olarak bu
    Yani Play Services üzerinden bant dışı güncelleniyorlar ve OEM’in OS güncellemesine gerek kalmıyor
  • Android 14’ten itibaren Google Play ile güncellenebilir, bu yüzden OS güncellemesine bağlı değil

• Her Android sürümü çıktığında bir şeylerin kaldırıldığını, pek anlamı olmayan şeylerin eklendiğini görüyorum
  iOS sanki ters yönde ilerliyor; yavaş yavaş ortada buluşacaklar ve sonra iOS her açıdan Android’i geçebilir gibi görünüyor
  Apple tarafındaki insanlardan dürüst görüşlerini duymak isterim
  Son zamanlarda macOS kullanıyorum ve Windows/Linux’ta onlarca yıldır olağan olan çok temel kullanıcı deneyimi noktalarında başarısız olduğu için sevmiyorum
  Finder gibi şeyler gerçekten berbat
  Gelecek nesilde Android yerine iPhone alırsam iOS’a da aynı olumsuz tepkiyi verir miyim?
  Akıllı telefon kullanım senaryolarında iOS’un macOS’tan daha olgun ve kullanışlı bir kullanıcı deneyimi sunduğu söylenebilir mi?
  Geçmek istiyorum ama zaman ve para harcamak istemiyorum

  • App Store kısıtlamaları ortadan kalkar ve uygulama sideload etmek kolaylaşırsa, Android’in iOS’tan daha iyi olduğu tek bir nokta bile aklıma gelmeyebilir
    Eski Android, yalnızca .apk dosyaları olan bir iOS’tan ibaret değildi; gerçekten üzücü
  • iPhone’u sabahları HN’de gezinmek, taşınabilir ses çalar olarak kullanmak, yolda bir şeylere bakmak ve telefon etmek için kullanıyorum
    Bu kullanım için gayet iyi
    Ama kullanıcı çok fazla kısıtlanıyor; jailbreak’e bakılabilir belki, fakat ben telefon kullanımımı minimumda tutup neredeyse her şeyi masaüstünde yapmaya çalışıyorum
    Bu arada macOS’u da bırakıp Linux’a geçen biriyim
  • İade politikası var; Mint gibi ön ödemeli bir operatörle deneyebilirsiniz

• Kendi barındırdığım yazılımlara erişmek için kişisel bir PKI kullanıyorum
  E-posta sunucusu, takvim sağlayıcısı, not sunucusu, fotoğraf senkronizasyon aracı gibi şeyler
  Kök sertifikamı sertifika yetkilileri listesine ekleyebilmeliyim
  Sistem tarafından sağlanan listeyi değiştirmek istemiyorum, sadece kendi sertifikamı eklemek istiyorum
  Bu benim cihazım; istersem istediğimi değiştirebilmem gerektiğini düşünüyorum

  • Kullanıcı sertifika deposuna kendi CA sertifikanızı kurabilirsiniz; Chrome ve kullanıcı tarafından yüklenen CA’lara seçmeli olarak güvenen diğer uygulamalar buna güvenir
    E-posta ve takvim uygulamalarının da buna dahil olma ihtimali yüksek
    Büyük olasılıkla işe yaramayacağı durum, uygulama ile uygulama üreticisinin sunucuları arasındaki trafiği araya girip okumak için kendi CA’nızı kurmanızdır
    Kendi cihazınızın ne yaptığını inceleyebilmeniz gerektiği için bu üzücü, ama kendi barındırdığınız yazılımda kişisel PKI kullanma senaryosu kesinlikle destekleniyor
  • Benim durumum da aynı; kurumsal BT politikaları da cihazlara bolca kök sertifika dağıtmıyor mu?
    Bir yolu olması gerekiyor gibi
  • Bir alternatif, özel ağda genel bir CA kullanmak
    getlocalcert bunun için araç geliştiriyor [1]
    Güven kökü ekleme ihtiyacını ortadan kaldırabildiği için, bazı ağlarda “özel ağ üzerinde genel sertifika” yaklaşımı genel olarak avantajlı
    Açıkçası Android’in özel CA’ları engelleyeceğini beklemiyordum, ama sonuçta böyle oldu
    [1] https://www.getlocalcert.net/
  • Ben de o kısmı karıştırmıştım
    Şu anda Android telefon kullanmıyorum ama eskiden root yetkisi olmadan, ayarlardaki bir seçenekle Android telefona kendi CA sertifikamı ekleyebildiğimi ve en azından web tarayıcısı gibi uygulamaların buna güvendiğini hatırlıyorum
    Çok eski bir zamandan da bahsetmiyorum
    Bu yüzden özel sertifika yüklemek için cihazı rootlamanın neden gerektiğini, bunun başka bir kullanım için mi olduğunu anlayamamıştım

• HTTP Toolkit, Turkey’deki berbat elektrikli araç şarj uygulamasından gizli API’leri çıkarmakta çok işe yaramıştı
  SSL pinning’i ve root algılamasını aşmak için Frida’yı da birlikte kullandım
  Sonra API’lerini saklamaya çalışmalarının sebebinin, o API’lerin canavar gibi şeyler olması olabileceğini fark ettim /s