En fin de compte, le tweet de Jeff Johnson a clairement indiqué la cause profonde. Il s'est avéré que le service OCSP Responder d'Apple était trop surchargé, de sorte que macOS n'a pas pu vérifier les certificats cryptographiques des développeurs d'applications.
Mais pourquoi OCSP Responder est-il sur le chemin critique pour lancer des applications? Dans cet article, nous discuterons brièvement de la signature de code, du fonctionnement du protocole OCSP (Online Certificate Status Protocol), des raisons pour lesquelles il est complètement faux et de certaines des meilleures alternatives. Contrairement à d'autres notes sur cet incident, je souhaite discuter des aspects cryptographiques pratiques (à un niveau élevé) et offrir une perspective équilibrée.
Signature de code
Sur le portail des développeurs, Apple explique le but de la signature de code:
La signature du code de votre application garantit aux utilisateurs qu'elle provient d'une source connue et qu'elle n'a pas été modifiée depuis la dernière fois qu'elle a été signée. Une application doit être signée avec un certificat émis par Apple avant de pouvoir être intégrée, installée sur un appareil ou entrée dans le catalogue d'applications.
En d'autres termes, pour qu'une application soit approuvée sur macOS, elle doit être signée avec son propre certificat basé sur une paire de clés. Un trousseau est utilisé pour créer un certificat «ID développeur» unique qui comprend une clé privée à utiliser par le développeur et une clé publique à distribuer. Lorsque Apple a signé un certificat d'identification de développeur, le développeur peut utiliser la clé privée pour créer des signatures cryptographiques sur ses applications à chaque version.
Lorsque l'application est lancée, sa signature est vérifiée par rapport à la clé publique du certificat du développeur. Le certificat lui-même est ensuite vérifié pour s'assurer qu'il n'a pas expiré (les certificats sont généralement valides pendant un an) et qu'il est finalement signé par le certificat racine Apple. Il peut également y avoir des certificats intermédiaires dans le cadre de la chaîne jusqu'au certificat racine. Il s'agit d'une «chaîne de confiance» car le certificat Developer ID a été signé par l'application, le certificat intermédiaire a signé le certificat Developer ID et le certificat racine Apple a signé le certificat intermédiaire. Tout appareil Apple peut vérifier cette chaîne de confiance et donc approuver le lancement de l'application.
Ceci est similaire à l'infrastructure de clé publique TLS d'Internet. Mais aussi fondamentalement différent, car Apple a un contrôle total sur sa propre chaîne de confiance. Les autres autorités de certification ne sont pas autorisées à émettre des certificats de signature de code valides car tous les certificats doivent être liés à Apple.
Si la vérification échoue, l'utilisateur verra une fenêtre terrible:
Retour d'information
Que se passe-t-il si un développeur enfreint les politiques Apple ou perd sa clé privée? L'autorité de certification doit révoquer instantanément les certificats émis. Si un certificat est utilisé de manière malveillante, il est inacceptable d'attendre des jours ou des mois pour qu'il expire naturellement, sinon une fuite de la clé privée rendrait le système entier inutile.
C'est dans cette situation que le certificat est révoqué. Il s'agit d'une étape supplémentaire dans le processus de vérification de la signature, qui consiste à demander à l'autorité de certification que le certificat est toujours valide.
Sur Internet, cela se fait de la manière la plus simple. L'autorité de certification vous donne une liste de révocation de certificats (CRL) avec les numéros de série de tous les certificats révoqués et vous vérifiez que le certificat ne figure pas dans la liste. Cependant, les navigateurs ont cessé d'utiliser cette approche à mesure que la liste s'allongeait de plus en plus. Surtout après des exploits horribles comme Heartbleed qui ont nécessité des révocations massives de certificats.
Le protocole OCSP (Online Certificate Status Protocol) est une alternative qui vous permet de valider les certificats en temps réel. Chaque certificat contient un répondeur OCSP intégré, qui est l'URL que vous demandez et qui vous indique si le certificat a été révoqué. Dans le cas d'Apple, c'est
ocsp.apple.com... Alors maintenant, en plus de vérifier la validité cryptographique de la signature, chaque fois que vous lancez l'application, vous effectuez une vérification en temps réel sur le site d'Apple (avec une certaine mise en cache) qu'ils considèrent toujours le certificat du développeur comme légitime.
Problème de disponibilité OCSP
L'énorme problème avec OCSP est que le service externe devient un point de défaillance unique. Que se passe-t-il si le répondeur OCSP est en panne ou indisponible? Refusons-nous simplement de vérifier le certificat (hard-fail)? Ou prétendons-nous que la vérification a réussi (échec logiciel)?
Apple est obligé d'utiliser un comportement d'échec logiciel, sinon les applications ne fonctionneront pas hors ligne. Tous les principaux navigateurs implémentent également un comportement de défaillance logicielle car les répondeurs OCSP ne sont généralement pas fiables et le navigateur souhaite charger le site même si le répondeur CA est temporairement arrêté.
Mais le soft-fail n'est pas une bonne option, car avec le contrôle du réseau, un attaquant peut bloquer les requêtes adressées au répondeur et la vérification sera ignorée. En fait, un tel "correctif" de l'erreur a été largement diffusé sur Twitter lors de cet incident: le trafic a été
ocsp.apple.combloqué par une ligne dans le fichier / etc / hosts. Beaucoup quitteront cette ligne pendant un certain temps, car la désactivation d'OCSP ne pose aucun problème notable.
Incident
Si la validation OCSP d'Apple repose sur une défaillance logicielle, pourquoi les applications se bloquent-elles lorsque le répondeur OCSP est désactivé? Probablement parce qu'il s'agissait en fait d'un autre problème: le répondeur OCSP n'était pas complètement désactivé. Cela n'a tout simplement pas bien fonctionné.
En raison de la charge de millions d'utilisateurs dans le monde qui effectuaient la mise à jour vers macOS Big Sur, les serveurs d'Apple ont ralenti et n'ont pas répondu correctement aux demandes OCSP. Mais en même temps, ils fonctionnaient suffisamment bien pour que l'échec progressif ne fonctionne pas.
Problème de confidentialité OCSP
En plus du problème de disponibilité OCSP, le protocole n'a pas été conçu pour protéger la confidentialité en premier lieu. La requête OCSP de base comprend une requête HTTP non chiffrée adressée au répondeur OCSP avec le numéro de série du certificat. Ainsi, non seulement le répondeur peut déterminer le certificat qui vous intéresse, mais également votre FAI et toute autre personne interceptant des paquets. Apple peut répertorier, dans l'ordre, les applications de développement que vous ouvrez, et les tiers peuvent faire de même.
Le chiffrement aurait pu être ajouté, et il existe une version meilleure et plus privée appelée agrafage OCSP , mais Apple ne l'a pas fait non plus. L'agrafage OCSP n'a pas vraiment de sens dans ce scénario, mais cette technologie montre qu'OCSP ne doit pas divulguer de données par défaut.
Meilleur futur
L'incident a déclenché une discussion animée dans la communauté, avec un côté déclarant: «Votre ordinateur n'est pas vraiment le vôtre», et l'autre affirmant: «Établir la confiance dans les applications est difficile, mais Apple le fait bien» . J'essaie de montrer qu'OCSP est de toute façon un moyen terrible de gérer les révocations de certificats, et à l'avenir, cela entraînera davantage d'incidents liés à la disponibilité et à la confidentialité des répondeurs. À mon avis, c'est une mauvaise décision d'ingénierie - définir la dépendance du lanceur d'application sur OCSP. Au moins à court terme, ils ont atténué les dégâts en augmentant les temps de mise en cache des réponses .
Heureusement, la meilleure méthode pour révoquer les certificats, CRLite, est presque mûre. Il vous permet de raccourcir toutes les listes de révocation de certificats à une taille raisonnable. Dans Scott Helme, le blog fournit un bon résumé de la façon dont CRLite utilise les filtres Bloom pour renvoyer l'ancienne approche avec une liste de certificats révoqués, qui fonctionnaient jusqu'à OCSP.
Les appareils MacOS peuvent recevoir périodiquement des mises à jour de cette liste CRL et effectuer des vérifications localement sur l'appareil, pour résoudre les problèmes de disponibilité et de confidentialité OCSP. D'autre part, étant donné que la liste de révocation de l'ID de développeur est beaucoup plus petite que la liste de tous les certificats révoqués PKI, il convient de se demander pourquoi Apple n'utilise pas de CRL. Ils peuvent ne pas vouloir divulguer quels certificats ont été révoqués.
Conclusion
Dans l'ensemble, cet incident était une bonne raison de réfléchir au modèle de confiance promu par des organisations telles qu'Apple et Microsoft. Les logiciels malveillants sont devenus plus sophistiqués et la plupart des gens sont incapables de déterminer s'il est sûr d'exécuter certains binaires. La signature de code semble être un excellent moyen cryptographique d'établir la confiance pour les applications et au moins de lier les applications avec des développeurs bien connus. Et la révocation des certificats est une partie nécessaire de cette confiance.
Mais quelques problèmes dans le processus de vérification OCSP gâchent l'élégance cryptographique du processus de signature et de vérification du code. OCSP est également largement utilisé pour les certificats TLS sur Internet, mais les échecs y sont moins catastrophiques en raison du grand nombre d'autorités de certification et de l'ignorance généralisée des pannes des navigateurs. De plus, les gens ont l'habitude de voir des sites Web indisponibles de temps en temps, mais ils n'attendent pas la même chose des applications sur leurs propres ordinateurs. Les utilisateurs de MacOS craignaient que leurs propres applications soient affectées par les problèmes d'infrastructure d'Apple. Cependant, il s'agit d'un résultat inévitable, provenant du fait que la validation des certificats dépend d'une infrastructure externe et qu'aucune infrastructure n'est fiable à 100%.
Scott Helme exprime également des inquiétudes quant à la puissance que les autorités de certification obtiennent si la révocation des certificats fonctionne vraiment. Même si vous ne vous inquiétez pas du potentiel de censure, des erreurs se produisent parfois et doivent être mises en balance avec les avantages en matière de sécurité. Comme un développeur l'a découvert lorsque Apple a révoqué par erreur son certificat , le risque de fonctionner sur une plate-forme isolée est que vous pouvez en être isolé.