Cet automne, iOS 27 pourra refuser les connexions aux serveurs mal configurés

Ce qui change exactement en version 27.0

Le document d'Apple s'adresse aux administrateurs informatiques et aux développeurs de solutions de gestion d'appareils, et sa formulation ne laisse pas de place au doute : à partir de la version 27.0 d'iOS, iPadOS, macOS, watchOS, tvOS et visionOS, le système « pourra refuser les connexions vers des serveurs dont la configuration TLS est obsolète ou non conforme ».

Il s'agit d'un durcissement d'App Transport Security, la politique qu'Apple impose au trafic réseau des applications depuis 2016, désormais étendue à une série de processus système. Aujourd'hui, sur les versions 26.4 et suivantes, une connexion non conforme produit un avertissement dans le journal système et aboutit quand même. En version 27, la même connexion produit une erreur et s'arrête.

Quelles connexions sont visées

Six activités entrent dans le périmètre : la gestion des appareils mobiles (MDM), la gestion déclarative (DDM), l'inscription automatisée, l'installation de profils de configuration, l'installation d'applications — y compris la distribution interne en entreprise — et les mises à jour logicielles. Deux cas sont explicitement exclus : les serveurs SCEP joints pendant l'installation d'un profil ou la résolution d'une ressource DDM, et les serveurs de mise en cache de contenu, même lorsque la ressource demandée est une application ou une mise à jour système.

Le trafic ordinaire des applications n'est pas le sujet. Une organisation dont l'API interne est en retard sur TLS ne verra pas sa propre application cesser de fonctionner à cause de ce document. Ce qui casse, c'est la tuyauterie qui installe l'application sur l'appareil.

Les exigences, en clair

Les serveurs doivent négocier TLS 1.2 au minimum, et Apple recommande la version 1.3. Un serveur resté en 1.2 doit franchir trois barres supplémentaires : un échange de clés assurant la confidentialité persistante, c'est-à-dire ECDHE ; des suites AEAD fondées sur AES-GCM avec SHA-256, SHA-384 ou SHA-512 ; et l'extension extended master secret définie par la RFC 7627. Les certificats ont leur propre plancher — clé RSA d'au moins 2048 bits ou ECDSA d'au moins 256 bits, et signature du certificat terminal en SHA-2. Le HTTP en clair est refusé purement et simplement.

Prise une à une, aucune de ces exigences n'est exotique : un serveur configuré de zéro en 2026 les satisferait par défaut. L'extended master secret est celle qui risque le plus de piéger un système en état de marche, parce qu'elle corrige une faiblesse du protocole identifiée en 2015 et que beaucoup d'équipements ont été livrés avec un TLS 1.2 conforme par ailleurs, sans jamais l'activer.

Comment le savoir avant septembre

La procédure d'Apple ne repose pas sur des suppositions. Installez le profil de journalisation Network Diagnostics sur un appareil de test représentatif en version 26.4 ou ultérieure — mais pas encore en version 27, car sur celle-ci une connexion bloquée peut masquer les échecs qui auraient suivi. Faites passer l'appareil par ses parcours normaux d'inscription et d'installation, collectez un sysdiagnose, puis filtrez l'archive de journaux sur les événements marqués ATS Violation ou ATS FCPv2.1 violation. Chaque événement nomme le domaine, le processus qui a ouvert la connexion et la contrainte précise qui a été violée.

Un serveur pris isolément se vérifie ensuite avec nscurl --ats-diagnostics https://exemple.com/, en cherchant un PASS dans la section FCP_v2.1.

Le conseil de couverture est celui qu'on saute le plus souvent et qui compte le plus : des rôles d'appareils différents joignent des serveurs différents. Un iPad en borne, un iPad partagé, le Mac d'un ingénieur et l'iPhone d'un commercial peuvent chacun toucher une infrastructure que les autres ne voient jamais. Tester une seule configuration ne prouve rien sur les autres.

La partie inconfortable, ce sont les prestataires

Apple écrit sans détour que la mise en conformité « peut demander beaucoup de temps, en particulier pour les serveurs maintenus par des prestataires externes ». Cette phrase porte l'essentiel du risque opérationnel. Une organisation peut reconfigurer son propre répartiteur de charge cette semaine. Elle ne peut pas reconfigurer le point d'entrée de son fournisseur de MDM, l'hébergeur de distribution d'applications qu'elle loue, ou l'équipement dont le constructeur a cessé de publier des micrologiciels en 2023. Chacun de ces cas est un ticket de support, une discussion contractuelle ou une migration.

La consigne d'Apple pour ces situations est de transmettre au prestataire l'article d'assistance accompagné des lignes d'avertissement exactes observées — ce qui est plus utile qu'une demande générale, puisque le texte de l'avertissement nomme la contrainte violée et le correctif dans la même phrase.

Pour tous ceux qui ne sont pas administrateurs

Si vous utilisez un iPhone ou un Mac que votre employeur ne gère pas, rien de tout cela ne changera quoi que ce soit de perceptible. Si votre appareil est inscrit auprès d'un employeur ou d'un établissement scolaire, le symptôme visible d'une flotte non préparée serait une mise à jour ou une installation d'application qui échoue sans s'expliquer, une fois le parc passé en version 27 — et le correctif serait du côté de l'organisation, pas de celui d'Apple.

Le schéma est familier chez Apple, et il tourne depuis une décennie : publier une échéance, passer un cycle de version à avertir, puis appliquer. On en a vu une variante dans le travail de sécurité derrière les correctifs WebKit d'iOS 26.6.1, où les correctifs n'étaient que la moitié visible d'une campagne plus longue. La différence, cette fois, tient à ce que la date d'application est arrimée à une version grand public que des millions de personnes installeront dans les jours suivant sa parution.