Android 14: ¿incluso el acceso root bloquea la modificación de certificados del sistema?

• Android 14 (API v34) cambió la lectura de los certificados CA del sistema para que ya no se tomen de /system, sino del módulo com.android.conscrypt basado en APEX, rompiendo el flujo tradicional de depuración que inyectaba certificados con acceso root
• Desde Android 7 Nougat, el almacén de confianza predeterminado de las apps quedó dividido en CA del sistema y CA del usuario, por lo que las herramientas de desarrollo, testing e ingeniería inversa venían dependiendo de modificar directamente el directorio de CA del sistema
• La nueva estructura permite actualizar los certificados CA mediante Google Play System Update, acelerando la eliminación de CA problemáticos y la distribución de nuevas CA, pero reduciendo el control del propietario del dispositivo
• En el emulador beta de Android 14, aunque se sobrescriban con tmpfs o se eliminen rutas como /system/etc/security/cacerts, /system/etc/security/cacerts_google y /apex/com.android.conscrypt/cacerts, Settings y las apps siguen viendo la lista de CA de Google
• Al momento de escribirlo, las alternativas reales eran quedarse en Android 13 o usar un OS personalizado que no use APEX, aunque luego se aclaró que aparecieron varios métodos para sortear la inyección de certificados en Android 14

---

Cómo ha ido cambiando la gestión de CA en Android

• Cuando se anunció Android en 2007 dentro de la Open Handset Alliance, se enfatizaba su apertura con expresiones como “open platform” y “complete access to handset capabilities and tools”
• Con el tiempo, se considera que el margen de control de usuarios, desarrolladores e investigadores sobre sus propios dispositivos se ha ido reduciendo

• El cambio de Android 7 Nougat

  • La lista de CA que el dueño del dispositivo podía modificar se separó en CA del sistema y CA del usuario
  • La lista fija de CA del sistema provista por el vendor del OS pasó a ser el valor predeterminado para todas las apps
  • La lista de CA modificable por el usuario solo se usa cuando la app hace opt-in explícitamente
  • Como resultado, casi ninguna app confía por defecto en las CA del usuario

Por qué son importantes los certificados CA

• Las CA de confianza del dispositivo son la lista de organizaciones que garantizan la seguridad del tráfico de red cifrado
• Una CA puede emitir certificados para cualquier dominio que se usarán en conexiones TLS como HTTPS, y los dispositivos que confían en esa CA aceptarán esos certificados como prueba de una conexión legítima
• Si el usuario hace que el dispositivo confíe en una CA creada por él mismo, puede interceptar y ver su propio tráfico HTTPS o TLS
  • Puede revisar los datos que el teléfono envía y recibe
  • Si hace falta, también puede modificarlos o bloquearlos
• Este control es importante para la investigación de seguridad y privacidad, la ingeniería inversa, la depuración y pruebas de apps, la configuración de redes internas corporativas y para usuarios que no confían en las CA predeterminadas
• Tiene sentido dificultar que un usuario no técnico cambie una CA por error o impedir cambios sin su conocimiento, pero restringir también el control de usuarios avanzados complica muchos casos de uso

Métodos de evasión basados en root después de Android 7

• Incluso después de Android 7, en dispositivos con acceso root todavía era posible manipular directamente el almacén de CA del sistema
• El método más común era colocar el certificado de confianza en /system/etc/security/cacerts/
• Como /system normalmente es de solo lectura incluso en dispositivos rooteados, se usaban dos enfoques
  • Reconfigurar el directorio /system para permitir escritura, reiniciar y luego modificar el directorio real de certificados del sistema
  • Montar un sistema de archivos temporal de lectura/escritura sobre el directorio de solo lectura, copiar las CA existentes y añadir el nuevo certificado
• Para que el sistema aceptara el certificado también había que cumplir condiciones como el nombre del archivo, los permisos y la etiqueta SELinux
• HTTP Toolkit automatizaba el procedimiento basado en montaje temporal para ofrecer configuración de interceptación con un clic en dispositivos Android rooteados o emuladores
• Este enfoque funcionaba en la mayoría de dispositivos rooteados personalizados, distribuciones especiales de Android y las imágenes oficiales del emulador de Google
  • La excepción eran las imágenes full “Google Play” bloqueadas, como en dispositivos OEM normales
• La documentación de mitmproxy, varias entradas de blog, respuestas de StackOverflow, publicaciones en foros, paquetes de Magisk y las guías de cacert.org también usaban métodos parecidos

La nueva estructura de actualización de CA en Android 14

• Android 14 estaba en fase beta final al momento de escribirse el artículo y su lanzamiento se esperaba en pocas semanas
• Una de sus funciones de seguridad principales era la de certificados CA actualizables de forma remota
• La gestión de certificados CA se separó de la imagen central del OS y pasó a un componente independiente distribuido y actualizado por Google Play
• Con esta estructura, Google puede retirar más rápido la confianza en CA problemáticas
  • Ya no hace tanta falta esperar a que cada fabricante distribuya una actualización OTA completa del OS
  • Con solo Google Play System Update se puede cambiar la lista de CA en dispositivos Android 14+
• Como las CA de confianza predeterminadas tienen un poder muy alto, requieren supervisión y sanciones, y los privilegios de una CA fallida deben retirarse rápidamente
• Como ejemplo, en enero de 2023 TrustCor perdió la confianza como CA ante actores importantes, incluido Google, luego de descubrirse vínculos estrechos con una organización distribuidora de malware y con contratistas de defensa e inteligencia de EE. UU.
• También hay problemas cuando se retrasa la distribución de nuevas CA
  • Let’s Encrypt tuvo que retrasar varias veces mejoras en la distribución de su cadena de firmas porque dispositivos Android antiguos no contaban con la CA raíz más reciente
• La idea de una estructura más ágil para responder con actualizaciones de CA tiene valor, pero la implementación en Android 14 hace que modificar las CA del sistema sea, en la práctica, muy difícil

Ubicación real de los archivos y funcionamiento de APEX

• El cambio clave en Android 14 es que, si existe /apex/com.android.conscrypt/cacerts, los certificados se leen desde ahí en vez de desde /system/etc/security/cacerts
• /apex es la ruta donde se montan los contenedores APEX, siglas de Android Pony EXpress
• Los módulos APEX son componentes del sistema que pueden actualizarse de manera independiente y se distribuyen como contenedores inmutables firmados
• En Android 14, los certificados CA pasan a formar parte del módulo com.android.conscrypt, que contiene la biblioteca central TLS/SSL de Android
• Se menciona que el funcionamiento de bajo nivel de APEX no está bien documentado y que algunos enlaces clave de detalles internos solo estarían disponibles en sitios internos de Google
• En las pruebas, el contenido del módulo APEX parecía exponerse directamente a cada proceso, de modo que modificar archivos en otras ubicaciones no se reflejaba en lo que ven las apps

Lo observado en el emulador de Android 14

• Las imágenes AOSP y “Play Services” del emulador oficial beta de Android 14 permiten acceso root
  • La imagen “Google Play” está bloqueada como un dispositivo OEM normal
• Es posible crear un emulador con la imagen API 34 “Google APIs” y abrir un shell root
• Al sobrescribir con tmpfs las rutas siguientes usando el método temporal tradicional, no se obtuvo el efecto esperado
  • /system/etc/security/cacerts
  • /system/etc/security/cacerts_google
  • /apex/com.android.conscrypt/cacerts
  • /apex/com.android.conscrypt@340818022/cacerts
• En Settings → Security & Privacy → More → Encryption → Trusted Credentials, la pestaña “System” seguía mostrando los certificados que supuestamente habían sido ocultados
• Por ejemplo, si se buscaba en todo el sistema de archivos el certificado “ACCV” 3c9a4d3b.0, este ya no aparecía mientras la ruta estaba cubierta por el mount, pero en Settings seguía mostrándose
• Al repetir el mismo procedimiento en una imagen de Android 13, la lista de certificados en Settings quedaba vacía, mostrando que el método anterior seguía funcionando como se esperaba

También falla modificar directamente la imagen del sistema

• El emulador de Android 14 puede iniciarse con -writable-system y, tras usar adb root, adb remount, avbctl disable-verification, reiniciar, etc., volverse escribible
• Después de eso, sí era posible eliminar certificados de /system/etc/security/cacerts/* y /system/etc/security/cacerts_google/*
• Sin embargo, no se podían eliminar los certificados dentro de /apex
  • Incluso tras el remount seguía siendo de solo lectura
  • El comando mount -o remount,rw ... también fallaba
• La maniobra más cercana posible era hacer umount de esa ruta de certificados para que dejara de verse en la salida de mount
• Aun así, la lista “Trusted” de Settings seguía cargando los certificados CA
• Se concluye que no era solo un problema de caché de la app Settings, sino el mismo comportamiento desde la perspectiva del almacén de certificados que ven las apps
• Sin importar cómo se modificara el sistema de archivos, las apps seguían viendo la lista de CA de Google

Impacto y limitaciones

• En Android 14 se rompe el flujo tradicional de instalar certificados CA del sistema para depuración, ingeniería inversa, pruebas e investigación
• En ese momento, las alternativas eran seguir con Android 13 o usar un release de OS personalizado que no empleara módulos APEX para la gestión de certificados CA
• Con el tiempo, estas alternativas pueden perder utilidad práctica porque implican separarse de componentes internos clave del Android mainline o seguir usando software antiguo
• Si el contenido dentro de módulos APEX no puede modificarse ni siquiera con root, el control del usuario podría seguir reduciéndose a medida que más componentes del sistema se migren a APEX
• Esto también podría afectar forks de Android como GrapheneOS y LineageOS, además de Magisk y varios módulos
• Aun así, según la actualización mencionada arriba, después surgieron varias soluciones mediante discusión e investigación de bypass para permitir la inyección de certificados también en Android 14
• Para depurar tráfico HTTPS en Android 14, ya no resulta viable asumir únicamente la inyección de CA del sistema basada en root

[GN⁺]

Opiniones de Hacker News

• Como alguien que trabajó con herramientas de root antiguas para Android, ROMs personalizadas universales modernas y varias tareas relacionadas con el SO Android, creo que el título es y seguirá siendo incorrecto
  Cuando se habla de root en Android, realmente significa permisos de root, y puedes hacer lo que quieras [1]
  Magisk, el root actual para Android, incluye incluso la capacidad de “modificar” código Java, así que debería poder acceder a esto aunque esté profundamente oculto
  Que el autor no haya podido hacerlo no significa que sea imposible; probablemente sea un problema de que zygote cachea las CA y hay que reiniciarlo con stop;start, o de que antes de ejecutar el comando hay que cambiar al espacio de nombres de montaje correcto
  GrapheneOS y LineageOS tienen acceso completo al código fuente, así que pueden cambiarlo como quieran; la limitación es, más bien, lo molesto que resulta seguirle el paso a las cosas que Google rompe a una velocidad enorme
  Espero que, a medida que Android se vuelve cada vez más hostil para los usuarios, especialmente para los usuarios avanzados, más gente se pase a ROMs personalizadas
  En sueños hago un fork de Android tipo “OwnerDroid”, donde la primera línea del modelo de seguridad no sea “el usuario es el enemigo”, pero por ahora solo hice unos cuantos ladrillos pequeños; el proyecto completo requeriría una cantidad enorme de trabajo
  [1] Algunas protecciones a nivel de kernel son la excepción, pero GKI reduce ese riesgo

  • El punto clave es que antes, incluso en las imágenes de SO stock de Google, cualquiera podía modificar directamente estos certificados sin instalar ninguna herramienta, simplemente escribiendo en el disco; este método se usaba ampliamente y estaba incluido en las guías de configuración de muchas herramientas
    Ahora ya no se puede hacer eso
    Por supuesto, si tienes todo el código fuente, todo es posible; también se podría compilar desde cero una imagen de sistema Android con este módulo desactivado, y GrapheneOS/LineageOS también pueden adaptarse
    Pero eso genera mucho trabajo nuevo, y si se separan de la implementación de Android en componentes centrales, podría requerir aún más mantenimiento en el futuro
    Para la gran mayoría de los usuarios afectados, decirles “primero compila tú mismo la imagen del sistema” está muy por encima de su zona de confort y del tiempo que pueden invertir
    Al final aparecerán otras soluciones, pero serán cosas como meterse en los espacios de nombres y modificar individualmente los montajes del proceso objetivo, o compilar e instalar un módulo APEX propio de una forma en que Android confíe para reemplazar el módulo del sistema, o enganchar apps individuales con Frida
    Aun así, es un gran problema que hace más difícil que los usuarios tengan control total sobre sus propios dispositivos
  • Me pregunto qué pasa con quienes más o menos ya se rindieron con trastear ROMs personalizadas
    Las partes importantes, como la detección de root de apps bancarias indispensables o las funciones relacionadas con Google, no están documentadas, y es casi imposible encontrar información de que una combinación de “modelo de teléfono + app de banco local + ROM personalizada” haya sido probada y funcione bien
    Estoy a favor de la libertad y la elección, pero para el usuario promedio de un teléfono no parece una forma realista de actuar, a menos que pueda dedicar varios teléfonos y varios días de trabajo, o que ya sea experto desde el principio
    En computadoras soy un usuario avanzado, pero creo que está bien que mi teléfono sea más tonto
    El problema es que eso se vuelve difícil si cada vez tienes que usar más el teléfono como dispositivo de autenticación multifactor, o si quedas atado a los caprichos de empresas con más poder de presión, como los bancos
    No pienso cambiar tres veces de cuenta bancaria para encontrar apps que funcionen en un teléfono rooteado
  • Que Google rompa cosas a una velocidad enorme y obligue a los demás a seguirle el paso es una estrategia para mantener a los competidores ocupados intentando alcanzarlo: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
    Si preguntas “¿en qué sentido un fork de Android es un competidor?”, eso significa que la estrategia está funcionando
  • Si solo hojeas el artículo, la evasión en sí parece bastante sencilla
    Si el nuevo método lee los certificados desde /apex/com.android.conscrypt/cacerts cuando existe, parece que se podría ocultar /apex/com.android.conscrypt/cacerts solo en los procesos necesarios, como se hace actualmente con las evasiones de SafetyNet, ocultamiento de root u ocultamiento de Magisk, para que vuelva al método anterior como fallback
  • No creo que las ROMs personalizadas vayan a volverse mainstream, por muy mal que se porten Google o Apple
    Son territorio de hackers, y de esos, solo las usa una fracción muy pequeña

• Hay muchos buenos comentarios aquí, pero no puedo dejar de pensar en lo afortunado que es que las PC no se comporten como los smartphones
  Android se arruinó a sí mismo de forma tan completa que me resulta raro encontrarme agradeciendo que Microsoft no administre el mundo de las PC como Google administra el mundo de los smartphones
  Windows en sí, comparado con Android, es casi un bastión de estabilidad y sentido común, y tampoco te obliga a actualizar hasta que el hardware realmente falle por vejez
  Al igual que Google, Microsoft tampoco controla toda la cadena hardware-software, pero sí tenía el poder de imponer normas a través de la tienda o de desalentar modificaciones del entorno con mecanismos tipo SafetyNet, haciendo que poseer una PC fuera extremadamente incómodo
  Recuerdo vagamente que Microsoft alguna vez enfrentó demandas antimonopolio por cosas así; me pregunto cuándo le tocará lo mismo a Google

  • Windows lleva unos 20 años haciendo actualizaciones de CA periódicas, y en este punto es más bien Android el que se comporta como Windows
    Microsoft también agregó muchísimo DRM a Windows, luego también rompió algunas de esas cosas, y la atestación remota también está integrada en el SO
    Google cambió detalles internos de implementación de Android de los que en realidad los desarrolladores no deberían depender y les causó molestias; Microsoft hace este tipo de cosas todo el tiempo
    Probablemente baste con esperar unas semanas a un módulo de Magisk actualizado y, sinceramente, no es tan malo
    En los 5 o 6 dispositivos que recibirán Android 14, basta con no tocar el botón de actualizar hasta entonces
  • Microsoft también lo intentó, solo que fracasó, y todavía lo sigue intentando
    Windows 11 exige TPM y Secure Boot
  • Creo que esto también podría beneficiar a los usuarios
    Escuché que algunos países en desarrollo exigen instalar una CA estatal para hacer ataques de intermediario en todas las conexiones; si esto se vuelve muy difícil, también se vuelve prácticamente más difícil hacer que los usuarios desactiven su propia privacidad

• Uso un PinePhone Pro como dispositivo principal
  Chase.com intenta de forma realmente insistente bloquear navegadores no estándar como Librewolf y el uso de navegadores en teléfonos/tablets, y trata de obligarte a usar la app móvil.
  Al menos hasta que WEI sea obligatorio, estas medidas tontas se pueden eludir fácilmente, así que no es un problema grave, pero como Chase es un banco, me pregunto si hay margen para disputarlo legalmente.
  Mi primera suposición es por el lado del cumplimiento de la ADA, pero no estoy seguro.
  Ya estoy tan cansado que no sé si decir que quiero demandar por esto sea solo una forma de hablar.
  Aunque es una tangente, está relacionado porque muestra otra faceta de lo casi imposible que es escapar del oligopolio de los sistemas operativos móviles.
  Incluso si el nicho de teléfonos Linux creciera milagrosamente hasta unos cuantos puntos porcentuales, es muy probable que Android siga empeorando, y hace falta algo.

  • Se viene una era oscura, lo digo en serio.
    Creo que llegará la era de la servidumbre digital.
    Terminaremos usando dispositivos provistos por alguna empresa “benevolente”, que será dueña de todos los aspectos del dispositivo, y solo podremos usarlos, como al manejar, si pagamos.
    La mayoría de las demás rutas estarán bloqueadas, la computación de propósito general quedará solo para “empresas”, y existirá una “web libre”, pero será bastante técnica y hostil para el usuario.
    La mayor parte del mercado, especialmente todo lo que maneje dinero, la evitará como si fuera una plaga.
  • Si sigues siendo cliente de Chase, estás respaldando su actitud depredadora y enviando la señal de que el resto de la industria también puede adoptar la misma postura.
  • Me entristece la parte de “al menos hasta que WEI sea obligatorio”.
    Creo que Google mató la web abierta con esto.
    De todos modos ya se estaba volviendo algo aburrida, pero molesta que ahora sea mucho más difícil vivir sin un teléfono o un navegador “aprobado”.
  • Si necesitas funciones de accesibilidad que solo están disponibles en navegadores alternativos, conviene contactar a Chase.
    Está bien que un usuario avanzado sepa instalar software adicional para arreglar el problema, pero sería mejor que Chase corrigiera su sitio web base para que también puedan beneficiarse usuarios principiantes con necesidades similares.

• En este punto creo que Android era, y sigue siendo, más coercitivo que Apple.
  Incluso cuando se podía instalar y confiar en una nueva CA raíz, algunas apps podían ignorarla, y de hecho lo hacían.
  Tanto iOS como Android permiten que las apps usen certificate pinning, pero desde Android 7+, a partir de 2016, las apps ignoran por defecto las CA agregadas por el usuario[1].
  En iOS, el proceso para confiar en una CA raíz es engorroso —instalar un perfil y pasar por advertencias alarmantes—, y eso en sí es razonable, pero según mi experiencia la mayoría de las apps confían en ella salvo que usen certificate pinning.
  [1]: https://android-developers.googleblog.com/2016/07/changes-to...

  • Entiendo por qué Google hizo eso en Android 7.
    Android, que se parece mucho más a una computadora común que iOS, tiene un problema enorme de stalkerware.
    El stalkerware no se detiene con avisos, convierte la compatibilidad hacia atrás en un arma e implica todo tipo de abusos.
    En iOS es sorprendentemente fácil que, después de prestarle el teléfono a alguien durante 5 minutos, la privacidad HTTPS quede comprometida durante años.
    Quiero tener la opción de confiar realmente en certificados CA instalados, pero me enfurece que incluso Firefox, que es un navegador web, no use certificados de usuario sin una combinación oculta de pestañas y ajustes.
    Aun así, considerando el riesgo para los usuarios de Android en todo el mundo, es difícil ver esta función como igualmente importante para unas decenas de técnicos que la usan a diario.
    Creo que este caso se parece más a un efecto secundario de las buenas mejoras de sandboxing de Google y de un mecanismo largamente postergado para actualizar el almacén de CA, que a una conspiración malvada de Google para sabotear los planes del departamento de TI local.
    Pronto aparecerá un módulo de Magisk como solución alternativa, y los módulos existentes se romperán por un tiempo, pero eso es común después de actualizaciones importantes de Android.
    Si hace falta, también podrías escribir tu propio módulo.
  • En iOS también hay apps que pueden ignorar una conexión VPN: https://restoreprivacy.com/latest-ios-found-to-bypass-vpn-co...

• Me parece que así es simplemente como funcionan los montajes.
  Si hay algo montado en /apex/whatever y cada app tiene un espacio de nombres de montaje separado, volver a montar algo encima de /apex/whatever dentro de tu propio espacio de nombres no cambia nada en los demás espacios de nombres.
  Tendrías que cambiar directamente el sistema de archivos, o entrar al espacio de nombres de montaje de otra app y montar también allí el tmpfs.
  Los montajes compartidos quizá ayudarían, pero no estoy seguro; habría que mirar con más detalle qué está pasando realmente.
  Creo que este resultado probablemente sea más un subproducto del trabajo de Google en espacios de nombres/contenedorización que un intento deliberado de impedir que los usuarios cambien las CA raíz incluso con permisos root.

  • En realidad creo que eso es correcto.
    Pero el resultado final sigue siendo un problema grande.
    Lo sorprendente aquí es lo de “espacios de nombres de montaje separados”.
    Antes abrías una shell y montabas algo en el sistema de archivos, o lo modificabas directamente, y las apps leían sin problema los archivos desde ese montaje.
    Ahora eso no ocurre con estos archivos cacert, y con el nuevo método tampoco es posible modificarlos directamente.
    Hasta antes de este cambio, ni siquiera sabía que las apps de Android usaban sus propios espacios de nombres de montaje.
    Hay muy poca documentación sobre cómo funciona exactamente, y tampoco estoy seguro de que hasta ahora hubiera habido un caso donde se hiciera tan evidente.
  • La tecnología resulta muy conveniente cuando es lo bastante compleja como para encontrar excusas que encajen con los objetivos de negocio.
    Basta ver manifest v3.

• Le dejé una respuesta al autor en Twitter, pero quizá no la vio, así que también la dejo aquí
  Soy quien escribió la entrada de blog sobre los certificados actualizables de Android 14, y esa entrada está enlazada en el artículo
  En realidad hay una propiedad del sistema que se puede configurar para omitir la lectura desde el directorio de certificados APEX
  system.certs.enabled=true
  Fuente: https://android-review.googlesource.com/c/platform/framework...

  • Lamentablemente, no creo que ayude mucho
    Eso es una propiedad de java.lang.System, es decir, un valor de configuración que se establece dentro de una JVM/app, no una propiedad del SO android.os.SystemProperties, o sea, un valor configurable de forma global en el dispositivo con adb
    A mi entender, para volver a configurar lo primero habría que modificar la propia app
    Es útil para pruebas automatizadas o para alternar la configuración entre builds de debug/prod, pero no ayuda mucho cuando quieres que todo el dispositivo confíe en un certificado CA
    Claro que, si sabes cómo establecer esa propiedad desde afuera para que se aplique a todas las apps, funcionaría muy bien, así que me encantaría escucharlo
    Por cierto, soy el autor, y en Twitter no veo esa respuesta
    Muy propio de Twitter en 2023

• Parece bueno para la seguridad y un infierno para algunos desarrolladores, pero me pregunto qué pasará cuando esta versión de Android quede abandonada en 2 o 3 años
  ¿Habrá que rezar para que los certificados hardcodeados aguanten unos años más?

  • Este era un problema conocido que los proveedores de certificados debían considerar desde hace mucho [0], pero desde Android 14 parece que ya no es así [1]
    Android 14 permite actualizar los certificados raíz mediante Google Play, y ya no se necesita una actualización OTA para agregar o quitar certificados raíz como antes
    También hay una solución alternativa que conocí hoy [0]
    Si usas Android 7.0 o anterior, quizá tengas que tomar medidas para seguir accediendo a sitios web protegidos con certificados de Let’s Encrypt; recomiendan instalar y usar Firefox Mobile, que usa su propio almacén de confianza en lugar del almacén de confianza del SO Android
    [0] https://letsencrypt.org/2023/07/10/cross-sign-expiration.htm...
    [1] https://www.xda-developers.com/android-14-root-certificates-...
  • Tuve que instalar un certificado de Let’s Encrypt para que funcionara mi gestor de contraseñas autoalojado
    Porque la actualización de Google no incluía el certificado intermedio que usa Let’s Encrypt
    Esto no es un problema hipotético del futuro, es un problema que existe ahora mismo
    ¿Por qué Google debería ser el árbitro final de en quién confío?
    Google también tiene fallas, sin duda
    Y entre los proveedores de certificados ya aprobados también hay algunos que, en la práctica, no deberían ser de confianza porque tienen antecedentes de emitir certificados a personas y organizaciones que no deberían tenerlos
  • Mi esposa tuvo que cambiar de teléfono precisamente por eso
    Las apps generalmente no aceptan certificados de usuario, y cuando Google Cloud o algo relacionado pasó a certificados más nuevos, algunas apps empezaron a dejar de funcionar
  • Los certificados ahora son un módulo APEX, y ese es exactamente el punto central de la queja del autor
    Es decir, se actualizan fuera de banda mediante Play Services y no requieren una actualización del SO por parte del OEM
  • Desde Android 14 se pueden actualizar mediante Google Play, así que no dependen de actualizaciones del SO

• Con cada lanzamiento de Android veo que quitan algo y agregan cosas que no tienen mucha importancia
  iOS parece moverse en la dirección opuesta, así que da la impresión de que lentamente se encontrarán en el medio y, más adelante, iOS podría superar a Android en todos los aspectos
  Me gustaría escuchar opiniones sinceras de gente del lado de Apple
  Últimamente uso macOS y no me gusta porque falla en experiencias de usuario muy básicas que en Windows/Linux se dan por sentadas desde hace décadas
  Cosas como Finder son realmente pésimas
  Si compro un iPhone en vez de Android para la próxima generación, ¿tendré la misma reacción negativa ante iOS?
  En los casos de uso de un smartphone, ¿se puede considerar que iOS ofrece una experiencia de usuario más pulida y útil que macOS?
  Tengo ganas de cambiarme, pero no quiero perder tiempo ni dinero

  • Si desaparecieran las restricciones de la App Store y fuera fácil hacer sideloading de apps, creo que no se me ocurriría ni una sola cosa en la que Android sea mejor que iOS
    El Android de antes era más que simplemente un iOS con .apk, y de verdad da pena
  • Uso el iPhone solo para leer HN por la mañana, como reproductor de audio portátil, para buscar cosas aquí y allá mientras me muevo, y para llamadas
    Para eso está bien
    Pero el usuario está demasiado limitado; podría investigar el jailbreak, pero intento minimizar el uso del teléfono y hacer casi todo en la desktop
    Como referencia, también estoy dejando macOS y migrando a Linux
  • Hay políticas de devolución, así que puedes probarlo con un operador prepago como Mint

• Uso una PKI privada para acceder a software autoalojado
  Cosas como mi servidor de correo, proveedor de calendario, servidor de notas y herramienta de sincronización de fotos
  Necesito poder agregar mi certificado raíz a la lista de autoridades certificadoras
  No quiero cambiar la lista que provee el sistema; solo quiero agregar mi certificado
  Es mi dispositivo, así que creo que debería poder cambiar lo que quiera si así lo deseo

  • Se puede instalar un certificado de CA propio en el almacén de certificados de usuario, y Chrome, junto con otras apps que confían opcionalmente en CAs instaladas por el usuario, lo aceptan
    Es muy probable que las apps de correo y calendario también entren en esa categoría
    Lo que probablemente no funcione es instalar una CA propia para interceptar el tráfico entre una app y los servidores del fabricante de esa app
    Es una lástima, porque uno debería poder inspeccionar qué hace su propio dispositivo, pero el caso de uso de una PKI privada para software autoalojado claramente sí está soportado
  • A mí me pasa lo mismo, pero ¿las políticas de TI corporativas no despliegan muchos certificados raíz en los dispositivos?
    Me parece que debería haber alguna forma de hacerlo
  • Una alternativa es usar una CA pública en una red privada
    En getlocalcert están creando herramientas para eso [1]
    Como evita la necesidad de agregar una raíz de confianza, en algunas redes el enfoque de “certificados públicos sobre una red privada” termina siendo una ventaja en general
    Sinceramente, no esperaba que Android bloqueara las CAs privadas, pero al final así resultó
    [1] https://www.getlocalcert.net/
  • Esa parte también me confundió
    No uso un teléfono Android actualmente, pero recuerdo que antes se podía agregar un certificado de CA propio a un teléfono Android solo con una opción en la configuración, sin acceso root, y que al menos apps como los navegadores web confiaban en él
    Tampoco fue hace tanto tiempo
    Por eso no entendía si la razón para necesitar rootear el dispositivo al instalar un certificado personalizado era para algún otro uso

• HTTP Toolkit fue muy útil para extraer una API oculta de una pésima app de carga de vehículos eléctricos de Turquía
  También usé Frida para evitar el SSL pinning y la detección de root
  Luego me di cuenta de que quizá la razón por la que intentaban ocultar la API era que esas APIs eran una monstruosidad /s