Steven Lilley, CC BY-SA 2.0, Wikimedia Commons
Este otoño, iOS 27 podría rechazar conexiones con servidores mal configurados
Los requisitos TLS más estrictos de Apple para los sistemas 27 pueden convertir las advertencias en fallos de conexión al gestionar dispositivos, instalar apps y actualizar software. Los administradores tienen poco margen para auditar su infraestructura.
Qué cambia realmente en la versión 27.0
El documento de Apple está dirigido a administradores de TI y a desarrolladores de gestión de dispositivos, y su redacción no deja lugar a dudas: a partir de la versión 27.0 de iOS, iPadOS, macOS, watchOS, tvOS y visionOS, el sistema operativo «podría rechazar conexiones con servidores que tengan configuraciones TLS obsoletas o no conformes».
El cambio endurece App Transport Security, la política que Apple aplica al tráfico de red de las apps desde 2016, ahora extendida a un conjunto de procesos del sistema. Hoy, en la versión 26.4 y posteriores, una conexión no conforme genera una advertencia en el registro del sistema y continúa. En la versión 27, la misma conexión genera un error y se detiene.
Qué conexiones están cubiertas
Seis actividades quedan dentro del perímetro: la gestión de dispositivos móviles, Declarative Device Management, la inscripción automática de dispositivos, la instalación de perfiles de configuración, la instalación de apps —incluida la distribución empresarial— y las actualizaciones de software. Dos quedan explícitamente excluidas: los servidores SCEP a los que se accede al instalar un perfil o al resolver un recurso de DDM, y los servidores de almacenamiento en caché de contenido, incluso cuando el recurso almacenado es una app o una actualización del sistema.
El tráfico habitual de las apps no es el objeto de esta medida. Una organización cuya API interna vaya retrasada en TLS no verá que su propia app deje de funcionar por este documento. Lo que puede romperse es la infraestructura que coloca la app en el dispositivo en primer lugar.
Los requisitos, en términos sencillos
Los servidores deben negociar TLS 1.2 o posterior, y Apple recomienda la 1.3. Un servidor que siga en 1.2 debe superar tres exigencias adicionales: intercambio de claves con secreto perfecto hacia adelante, es decir ECDHE; conjuntos de cifrado AEAD basados en AES-GCM con SHA-256, SHA-384 o SHA-512; y la extensión extended master secret definida en el RFC 7627. Los certificados tienen su propio mínimo: al menos una clave RSA de 2048 bits o una clave ECDSA de 256 bits, y una firma SHA-2 en el certificado hoja. El HTTP en texto plano se rechaza sin excepción.
Tomados uno a uno, ninguno de estos requisitos es exótico; un servidor configurado desde cero en 2026 los cumpliría todos por defecto. El requisito del extended master secret es el que más probablemente sorprenda a un sistema en funcionamiento, porque corrige una debilidad del protocolo detectada en 2015, y muchos equipos llegaron a implementar un TLS 1.2 conforme sin llegar a activarlo nunca.
Cómo averiguarlo antes de septiembre
El procedimiento de Apple no deja lugar a las suposiciones. Instale el Network Diagnostics Logging Profile en un dispositivo de prueba representativo con la versión 26.4 o posterior —pero, y esto es importante, todavía no con la versión 27, porque una conexión bloqueada en la 27 puede ocultar los fallos que se habrían producido después—. Haga pasar el dispositivo por sus flujos normales de inscripción e instalación, recoja un sysdiagnose y filtre el archivo de registro en busca de eventos etiquetados como ATS Violation o ATS FCPv2.1 violation. Cada evento indica el dominio, el proceso que abrió la conexión y la exigencia concreta que se incumplió.
Los servidores individuales pueden comprobarse directamente con nscurl --ats-diagnostics https://ejemplo.com/, buscando un PASS en la sección FCP_v2.1.
La recomendación sobre cobertura es la que más se suele saltar y la que más importa: distintos perfiles de dispositivo llegan a distintos servidores. Un iPad en modo quiosco, un iPad compartido, el Mac de un ingeniero y el iPhone de un comercial pueden tocar infraestructuras que los demás nunca ven, y probar una sola configuración no dice nada sobre el resto.
La parte incómoda: el proveedor externo
Apple dice sin rodeos que la corrección «podría requerir mucho tiempo, especialmente en servidores mantenidos por proveedores externos». Esa frase concentra la mayor parte del riesgo operativo. Una organización puede reconfigurar su propio balanceador de carga esta misma semana. No puede reconfigurar el endpoint de su proveedor de MDM, el host de distribución de apps empresariales que tiene contratado, ni el equipo cuyo fabricante dejó de publicar firmware en 2023. Cada uno de esos casos exige un ticket de soporte, una conversación contractual o una migración.
La recomendación de Apple para esos casos es enviar al proveedor el artículo de soporte junto con las líneas exactas de advertencia observadas, lo cual resulta más útil que una petición genérica, porque el texto de la advertencia nombra a la vez la exigencia incumplida y el remedio.
Para quienes no son administradores
Si usa un iPhone o un Mac que su empresa no gestiona, esto no cambia nada perceptible. Si su dispositivo está inscrito con un empleador o un centro educativo, el síntoma visible de una flota mal preparada sería una actualización o una instalación de app que falla sin explicación alguna, una vez que la flota pase a la versión 27; y la solución dependería de la organización, no de Apple.
Se trata de un patrón habitual en Apple, que lleva una década aplicándose: fijar una fecha límite, dedicar un ciclo de versión a advertir y, después, hacerla cumplir. Vimos una variante en el trabajo de seguridad detrás de los parches de WebKit de iOS 26.6.1, donde las correcciones eran solo la mitad visible de una campaña más larga. La diferencia esta vez es que la fecha de aplicación está ligada a una versión de consumo que millones de personas instalarán a los pocos días de su publicación.