Cuando se establecen conexiones encriptadas, las aplicaciones a menudo miran con mucho cuidado para ver si están hablando con el servidor correcto, es decir, si el servidor realmente se identifica con el certificado TLS esperado. Hasta ahora, los desarrolladores de aplicaciones siempre tenían que escribir su propio código para instalar esta certificación; con iOS 14 esto ahora es mucho más fácil. Apple informa a la comunidad de desarrolladores de esta posibilidad en gran parte desconocida de instalar el certificado a través de la configuración A través de un boletín; Aquí hay una introducción rápida a la instalación general y la implementación concreta en iOS.
Esto es lo que hace la instalación
Al establecer una conexión encriptada TLS, el propio servidor autentica la aplicación con un certificado. La clave pública del servidor contenida en el certificado se utiliza para acordar un secreto de cifrado compartido. Para que la aplicación sepa que en realidad está hablando con el backend previsto, no con el atacante de una máquina en el medio, por ejemplo, primero se debe verificar la autenticidad del certificado. Para ello, cada certificado está firmado por una autoridad de certificación (CA).
Luego, el sistema operativo verifica que cada vez que se establece una conexión, entre otras cosas, el nombre de host especificado en el certificado coincide con el nombre del sistema solicitado y que el certificado presentado por el servidor ha sido emitido y firmado por una autoridad de certificación confiable ( CA de confianza). Para este último paso, iOS tiene un almacén de certificados de todo el sistema (almacén de confianza) donde se preinstalan los certificados raíz de muchas CA públicas.
Si lo miras Lista de certificados raíz preinstalados en iOS 14 Pero más exactamente, uno puede sentir miedo y ansiedad. Trust Store contiene más de 150 certificados raíz confiables de organismos de certificación relacionados con el gobierno más o menos conocidos de muchos países.
Instalar: antes del flujo de datos, la aplicación comprueba si el certificado cumple con los criterios especificados.
A la luz de los muchos incidentes que han ocurrido en el pasado, desde comprometer los poderes de toda la CA hasta emitir certificados falsos, una cierta desconfianza es ciertamente apropiada. Para evitar el abuso tanto como sea posible, en los últimos años se han introducido controles como la transparencia de certificados (CT). Sin embargo, la pregunta que surge es si realmente desea confiar en todas las autoridades de certificación (CA) en Trust Store sin restricciones.
También existe el riesgo de que los usuarios reciban los llamados perfiles de configuración o perfiles de gestión de dispositivos móviles a través de la ingeniería social, obteniendo así referencias certificadas adicionales inadvertidas. Apple ha levantado barreras para tales ataques, pero persisten algunos riesgos.
Validación de la aplicación
Por estas razones, cada vez más aplicaciones están comenzando a depender de la validación del sistema operativo, en lugar de verificar sus certificados por sí mismos. Con lo que se llama una instalación de certificado, el certificado TLS esperado generalmente se almacena en la aplicación durante el desarrollo y luego se verifica cada vez que se establece una conexión si el backend también presenta el certificado esperado.
También estándares como este Estándar de verificación de seguridad de aplicaciones móviles OWASP (MASVS) requiere validaciones de certificación específicas de la aplicación en el nivel de validación L2 para todas las aplicaciones que manejan datos sensibles, como aplicaciones de salud o financieras.
En la práctica, se han creado muchas instalaciones donde todo el certificado se almacena en la aplicación o solo la clave pública ubicada en el certificado (instalación de clave pública). Hasta ahora, los desarrolladores de aplicaciones tenían que escribir o crear su propio código para esto. Soluciones de código abierto como TrustKit Integración en su aplicación. Con iOS 14, esto ahora es mucho más fácil sin la necesidad de adaptar el código de la aplicación.
Seguridad de transporte para aplicaciones
En las plataformas de Apple, existe un mecanismo llamado Seguridad de transferencia de aplicaciones (ATS) HTTPS se aplica a todas las aplicaciones y se cumplen los requisitos mínimos para una comunicación TLS segura. Este mecanismo ahora se ha ampliado con iOS 14 y, a partir de ahora, proporciona a las aplicaciones la capacidad de almacenar claves esperadas para los socios que llaman en el archivo de configuración central Info.plist.
Para todas las comunicaciones que la aplicación utiliza a continuación a través de la API estándar, específicamente a través de Sistema de subida de URL A partir, iOS compara las claves informadas por el backend con las claves almacenadas en la configuración. Si las claves no coinciden, la conexión se cancela y se devuelve un mensaje de error. De esta manera, los ataques a la conexión se pueden bloquear incluso si el atacante posee un certificado falsificado de una autoridad de certificación confiable.
Es importante que este mecanismo de protección solo funcione para conexiones a través del sistema de carga de URL. Si los desarrolladores no usan API estándar, pero crean sus propias soluciones utilizando métodos de bajo nivel como Network Framework, CFNetwork o Sockets, las restricciones no se aplicarán.
Por cierto, este mecanismo está disponible para aplicaciones de Android a través de Configuración de seguridad de red Ha estado disponible durante mucho tiempo. Desde Android 7.0, la seguridad y el certificado o la configuración de la clave se pueden establecer de manera similar a través de la configuración.
Variantes de fijación: hoja, medio o raíz
La certificación o fijación de clave pública se puede aplicar a diferentes niveles. La aplicación puede verificar directamente el certificado final (certificado final) o la clave del servidor y luego establecer una conexión solo si el servidor devuelve la clave preconfigurada exacta. Sin embargo, esto puede generar problemas rápidamente si la clave del servidor cambia, por ejemplo, porque se vuelve a llamar o se reemplaza. Entonces, la aplicación ya no llega al backend.
Por lo tanto, describir solo la autoridad de certificación en lugar de los certificados de servidor individuales es menos propenso a errores. Lo hace clavando los certificados de nivel superior dentro de la cadena de certificados, como algunos certificados intermedios o raíz para una CA. Este enfoque es más sólido frente a los cambios de certificación y aún garantiza la aceptación de solo los certificados emitidos por el organismo de certificación especificado. Esto significa que solo debe confiar en una CA, pero no en cientos de otras en la tienda de confianza. Para aplicaciones empresariales, aquí se puede implementar fácilmente una CA corporativa interna.
Apropos CA: Surgirán problemas en las redes corporativas en las que las comunicaciones protegidas por TLS se escanean con un monitor instalado activamente en la conexión. Incluso si la CA parece estar emitiendo certificados válidos, la instalación reconoce el certificado MITM bajo el cual se coloca y rompe la conexión.
