MUSCULAR 2013 : interception des liaisons entre data centers

MUSCULAR 2013 : interception des liaisons entre data centers

En octobre 2013, le Washington Post publie, à partir des documents fournis par Edward Snowden, l’existence de MUSCULAR : un programme conjoint de la NSA (National Security Agency) et du GCHQ (Government Communications Headquarters) qui copiait le trafic circulant sur les liaisons privées entre les data centers de Google et de Yahoo, hors du territoire américain. Ces flux internes circulaient en clair, parce que le réseau privé était réputé de confiance. L’affaire a enterré une hypothèse d’architecture : le chiffrement qui s’arrête à la porte du data center.

Explication de la marmotte

Imagine une banque qui fouille chaque client à l’entrée, avec portique et vigile, puis transporte l’argent entre ses agences dans une camionnette bâchée sur une route publique, persuadée que la route lui appartient. Quelqu’un s’est posté au bord de cette route. Cette histoire raconte ce qui arrive quand on protège la porte et qu’on oublie le chemin.

→ Lire l’explication complète de la marmotte

Ce que MUSCULAR révèle : le TLS s’arrêtait au front-end

Le document le plus cité est un schéma manuscrit intitulé « Google Cloud Exploitation ». On y voit Internet, le serveur frontal de Google (le GFE, Google Front End, qui termine les connexions des utilisateurs), et derrière lui le « Google Cloud », c’est-à-dire le réseau interne. Une flèche désigne la frontière entre les deux, avec l’annotation « SSL added and removed here! » et un smiley. SSL (Secure Sockets Layer) y désigne le chiffrement que l’on appelle aujourd’hui TLS (Transport Layer Security).

Le smiley résume l’architecture mieux que n’importe quel audit. Le TLS protégeait le segment entre le navigateur et le front-end, puis disparaissait. Derrière, les appels RPC (Remote Procedure Call) entre services, la réplication des boîtes de messagerie, les synchronisations de bases traversaient des fibres louées sans aucune protection cryptographique. Un acteur placé sur le transport n’avait rien à casser : il lisait.

Trois traits distinguent MUSCULAR des autres programmes révélés la même année :

• Aucune coopération de l’hébergeur. Le programme PRISM passait par des demandes légales adressées aux entreprises sur le sol américain (section 702 du FISA, Foreign Intelligence Surveillance Act). MUSCULAR se servait directement sur les câbles, sans que Google ou Yahoo le sachent.
• Un cadre juridique plus lâche. L’accès se faisait depuis l’étranger, via un point de collecte désigné DS-200B et un opérateur de télécommunications non nommé, sous l’Executive Order 12333, sans contrôle de la cour FISA.
• Une cible de valeur maximale. Le trafic inter-data centers contient ce que le front-end ne montre jamais en un seul endroit : des copies complètes de comptes, des métadonnées agrégées, des formats internes (Yahoo répliquait des archives de messagerie entières, au format interne « NArchive »).

La leçon technique ne porte pas sur le renseignement. Elle porte sur une erreur de modèle de menace que l’on retrouve partout : confondre « réseau qui m’appartient » et « réseau que personne d’autre ne touche ». Le premier se signe chez un juriste, le second se démontre avec une clé.

Le modèle de menace d’une liaison privée inter-data centers

Une « liaison privée » entre deux sites est rarement une fibre posée par l’exploitant lui-même d’un bout à l’autre. C’est le plus souvent une longueur d’onde sur un système DWDM (Dense Wavelength Division Multiplexing) d’opérateur, une fibre noire louée qui traverse des chambres de tirage, des répartiteurs et des points de régénération appartenant à des tiers, parfois dans plusieurs juridictions. L’exploitant voit deux extrémités ; tout ce qui se trouve entre elles relève d’un contrat.

Sur la topologie suivante, regarder ce qui est chiffré (le segment utilisateur) et ce qui ne l’est pas (tout le reste), ainsi que l’endroit où se branche le point de collecte : sur le transport, hors des deux sites.

Le modèle de menace correct pour ce lien est celui d’Internet : un adversaire capable de lire, copier, rejouer et injecter, sans laisser de trace côté extrémités. Le RFC 7258, publié par l’IETF (Internet Engineering Task Force) en 2014 dans la foulée de ces révélations, le formule sans détour : la surveillance massive est une attaque, et les protocoles doivent la traiter comme telle. Ce qui vaut pour un protocole Internet vaut pour une fibre louée qui en a toutes les propriétés, sauf l’étiquette.

La même logique s’applique au réseau à l’intérieur d’un seul bâtiment, avec un adversaire différent : un serveur compromis, un commutateur mal configuré, un port miroir oublié. La page voisine sur le chiffrement est-ouest traite ce cas général ; MUSCULAR en est la démonstration la plus coûteuse.

Surface d’attaque des liaisons inter-sites et contre-mesures

Les points d’accès connus à un trafic inter-data centers non chiffré, et ce qui les neutralise :

Vecteur	Ce qu’il permet	Contre-mesure
Coupleur optique passif sur la fibre	Copie intégrale, sans interruption détectable si la perte de puissance reste dans la marge	Chiffrement de lien ou de service ; surveillance des niveaux optiques
Accès chez l’opérateur (équipement de transport, port miroir, réquisition)	Copie intégrale, invisible depuis les extrémités	Chiffrement de bout en bout sous clés de l’exploitant, jamais de l’opérateur
Chiffrement fourni par l’opérateur (« ligne chiffrée » vendue en option)	Rien de nouveau : l’opérateur détient les clés, donc le clair	Chiffrement géré par l’exploitant, en plus ou à la place
Équipement de bordure compromis (routeur, appliance)	Clair disponible si le chiffrement s’arrête dans cet équipement	Chiffrement au niveau des services, pas seulement des liens
Rétrogradation vers le clair (négociation qui échoue « proprement »)	Retour au trafic non chiffré sans alerte	Politique « doit chiffrer », alerte sur toute session en clair
Collecte puis déchiffrement différé	Lecture future si les clés de session sont dérivables d’une clé long terme	PFS (Perfect Forward Secrecy), échange hybride post-quantique

Deux pièges reviennent systématiquement. Le premier : la surveillance optique ne remplace pas le chiffrement. Un coupleur bien posé prélève une fraction de la lumière qui reste sous le seuil d’alarme d’un lien dimensionné avec de la marge, et un OTDR (Optical Time-Domain Reflectometer) ne voit que ce qu’on lui demande de mesurer, quand on le lui demande. Le second : un chiffrement de lien dont la clé est provisionnée par l’opérateur n’est qu’un changement de propriétaire du texte en clair.

MACsec, IPsec ou mTLS : choisir la couche de chiffrement est-ouest

Trois couches se disputent le travail.

• MACsec (Media Access Control Security, IEEE 802.1AE) chiffre trame par trame, saut par saut, au débit de la ligne dans le silicium des interfaces. Les clés de session (SAK, Secure Association Key) sont distribuées par le protocole MKA (MACsec Key Agreement, défini dans IEEE 802.1X), à partir d’une clé de connectivité (CAK, Connectivity Association Key).
• IPsec (Internet Protocol Security) en mode ESP (Encapsulating Security Payload, RFC 4303) chiffre entre deux passerelles ou deux hôtes, au niveau IP, indépendamment des sauts intermédiaires.
• mTLS (mutual TLS) ou un équivalent maison (Google a publié par la suite ALTS, Application Layer Transport Security) chiffre de service à service, avec une identité cryptographique pour chaque charge de travail.

Le compromis central tient en une phrase : plus le chiffrement descend dans la pile, moins il coûte et moins il protège. MACsec est transparent pour les applications et quasi gratuit en CPU, mais le trafic redevient clair dans chaque commutateur et chaque routeur qu’il traverse : exactement le profil « ajouté puis retiré ici » du schéma de 2013, déplacé d’un cran. mTLS protège de processus à processus et porte une identité exploitable pour l’autorisation, au prix d’une PKI (Public Key Infrastructure) interne qui délivre et renouvelle des certificats à courte durée pour chaque service, et de cycles CPU sur chaque nœud.

Le schéma suivant donne l’arbre de décision ; il se lit de haut en bas, chaque branche dépendant de la question posée sur le flux.

La position défendue ici : le chiffrement au niveau du service est le socle, le chiffrement de lien est une ceinture. Toute donnée applicative entre services passe en mTLS, avec authentification mutuelle et refus du clair. Toute liaison qui sort d’un bâtiment ou traverse un transport tiers reçoit en plus MACsec ou IPsec sous clés de l’exploitant, parce que cette couche protège aussi les protocoles de contrôle (routage, supervision, réplication de stockage bas niveau) que personne ne pensera à passer en mTLS. Cette recommandation suppose une PKI interne capable d’émettre à la chaîne ; sans elle, mieux vaut commencer par la PKI que par la liste des services (les pages PKI et TLS détaillent ce chantier).

Vingt ans de métier apprennent qu’un projet « zéro confiance » commence souvent par un nouveau logo sur l’accès distant et s’arrête avant le premier flux de réplication, celui précisément qu’un acteur à budget illimité viendrait lire.

Ce que le chiffrement des liaisons ne garantit pas

Chiffrer les liaisons inter-sites ferme la porte que MUSCULAR avait trouvée ouverte. Il n’en ferme aucune autre.

• Les métadonnées de trafic restent visibles. Volumes, horaires, couples d’adresses de bordure et cadence des réplications se lisent sur un lien chiffré. Brouiller ces signaux demande du bourrage et du lissage de trafic, rarement justifiés hors contexte militaire.
• L’accès légal par l’hébergeur n’est pas concerné. Une demande adressée à l’exploitant porte sur des données qu’il déchiffre lui-même. Seul un chiffrement côté client, dont l’exploitant ne détient pas la clé, change cette équation, avec ses propres coûts (recherche, indexation, récupération de compte).
• Les extrémités restent la cible. Un serveur compromis lit son propre trafic déchiffré. Le chiffrement déplace l’attaque du câble vers l’hôte, ce qui est un progrès (l’hôte se supervise, la fibre beaucoup moins), pas une immunité.
• La donnée au repos est un autre sujet. Les disques des deux sites, leurs sauvegardes et leurs index relèvent du chiffrement au repos et de la gestion de clés, traités dans la section Cryptographie.
• Le passé collecté reste exposé si les clés le permettent. Sans PFS, une clé privée long terme volée plus tard déchiffre les captures anciennes. Avec des échanges classiques seuls, un ordinateur quantique suffisamment grand ferait de même : c’est l’argument « collecter maintenant, déchiffrer plus tard », qui pousse vers les échanges hybrides post-quantiques sur les flux à longue durée de confidentialité.

Prérequis et conditions d’exploitation du chiffrement inter-data centers

Prérequis de plateforme. Pour MACsec à 100 Gbit/s et au-delà, des interfaces qui implémentent AES-GCM (Advanced Encryption Standard, Galois/Counter Mode) en 256 bits avec XPN (Extended Packet Numbering, IEEE 802.1AEbw). Avec un compteur de paquets sur 32 bits, environ 4,3 milliards de trames, un lien à 100 Gbit/s saturé de petits paquets épuise l’espace en moins d’une minute, ce qui impose des renégociations de SAK en rafale ; XPN porte le compteur à 64 bits. Vérifier aussi que le chiffrement passe le transport : certains équipements DWDM ou de multiplexage interprètent ou rejettent des trames Ethernet modifiées, et MACsec sur une longueur d’onde louée se valide en essai avant contrat. Pour mTLS, une PKI interne automatisée, un mécanisme d’identité de charge de travail et un inventaire des flux ; sans inventaire, la bascule en mode strict se fait par découverte des pannes.

Clés et rotation. Les CAK de MACsec sont des secrets partagés de longue durée : les stocker dans un coffre ou un HSM (Hardware Security Module), jamais dans le fichier de configuration sauvegardé sur le serveur de gestion. Les SAK tournent automatiquement via MKA ; les CAK doivent tourner sur calendrier, ce que la plupart des équipements supportent par trousseau avec fenêtre de recouvrement. Pour mTLS, des certificats de service à durée de vie de l’ordre de l’heure ou du jour : la révocation se propage mal, l’expiration courte la remplace.

Supervision. Le mode d’échec par défaut de nombreuses implémentations MACsec est « should-secure » : si la négociation échoue, le trafic passe en clair. Configurer « must-secure » sur les liens inter-sites et alerter sur toute session MKA tombée, tout compteur de trames non protégées non nul, toute connexion de service acceptée sans certificat client. Un chiffrement qui se désactive silencieusement pour préserver la disponibilité finit toujours par choisir la disponibilité.

Reprise. Un lien en « must-secure » dont la CAK a divergé entre les deux bouts coupe le site. Prévoir une procédure de reprise qui ne passe pas par le lien concerné (accès hors bande), et un test régulier de la rotation de bout en bout. La PKI interne devient une dépendance de démarrage de tout le parc : son autorité émettrice se sauvegarde et se restaure comme une base de production, pas comme un serveur de test.

Exemple : le flux d’une requête avant et après MUSCULAR

Le schéma ci-dessous suit une même requête de lecture de messagerie, servie depuis le site A mais stockée sur le site B. Les quatre premières lignes décrivent l’architecture de 2013, les suivantes celle qui la remplace.

Ce qu’il faut y lire : dans la version de 2013, un seul point d’accès sur le transport suffit pour tout obtenir, sans toucher aux sites. Dans la version corrigée, le même point d’accès ne livre que des métadonnées ; pour lire le contenu, il faut désormais compromettre un hôte de service, ce qui expose l’attaquant à la supervision de l’exploitant. Le chiffrement n’a rien rendu impossible, il a déplacé l’attaque vers un endroit qu’on surveille. Google et Yahoo ont tous deux annoncé après les révélations le chiffrement de leurs liaisons inter-data centers ; d’autres affaires de collecte de trafic en clair, comme Google Street View et le Wi-Fi, rappellent que le clair finit toujours par être lu par quelqu’un, l’index des failles en recense d’autres.

Sources

• RFC 7258, IETF.
• RFC 4303, IETF.
• IEEE 802.1AE, IEEE.
• IEEE 802.1X, IEEE.
• Executive Order 12333, Maison-Blanche.

🐝 Ce qui arrive si on s’en passe

Sans chiffrement des liaisons inter-sites, toute personne qui accède au transport obtient le contenu complet des réplications : comptes entiers, jetons de session internes, sauvegardes en transit. Elle l’obtient sans toucher à aucun serveur de l’exploitant, donc sans déclencher la moindre journalisation ni alerte côté sites. Les jetons et identifiants internes copiés au passage permettent ensuite d’injecter des requêtes dans les services, puisque rien n’authentifie l’émetteur d’un appel interne. Enfin, l’exploitant perd toute capacité à démontrer après coup ce qui a fuité : une copie optique ne laisse aucune trace exploitable, et l’enquête bute sur un contrat d’opérateur plutôt que sur des journaux.

🦫 Explication de la marmotte 🍫

Quand tu ouvres ta messagerie, ton navigateur crée une connexion chiffrée avec le premier serveur de l’entreprise : personne sur le chemin ne peut lire ce qui passe. Mais ce serveur n’a pas tes messages. Il les demande à d’autres ordinateurs, parfois installés dans un autre pays, reliés par des câbles en fibre optique loués à des entreprises de télécommunications. En 2013, on a appris que ces échanges internes n’étaient pas chiffrés : les grandes entreprises pensaient que ces câbles étaient privés, donc sûrs. Des services de renseignement américains et britanniques ont obtenu un accès à ces câbles, hors des États-Unis, et copiaient ce qui y passait, sans demander l’autorisation aux entreprises. La correction consiste à chiffrer aussi ces échanges internes. Deux niveaux se combinent : chiffrer chaque programme qui parle à un autre, en vérifiant l’identité des deux côtés, et chiffrer le câble lui-même avec des clés que seule l’entreprise possède. Ce chiffrement ne cache pas tout : on voit encore quand et combien de données circulent, et un serveur piraté lit toujours ce qu’il reçoit. Il faut aussi changer les clés régulièrement et surveiller les liens, car un réglage mal fait peut, en cas d’erreur, renvoyer les données en clair sans prévenir personne.

À lire aussi

• DigiNotar 2011 : compromission d'une autorité de certificationRécit et analyse de la compromission de l'autorité de certification DigiNotar en 2011, de l'interception de Gmail en Iran à la naissance de Certificate Transparency.
• WannaCry et MS17-010 : fenêtre d'exposition et correctifsWannaCry, EternalBlue et MS17-010 montrent comment les deux mois entre un correctif publié et un correctif déployé deviennent la fenêtre d'exposition d'un parc Windows.
• TLS ou tunnel VPN IPsec contre l'homme du milieuComparer TLS et un tunnel VPN IPsec pour protéger les données en transit contre l'interception et l'homme du milieu.
• GRE, IPsec ou GRE dans IPsec pour un tunnel site à siteChoisir entre GRE, IPsec et GRE dans IPsec pour relier deux sites, selon le chiffrement, le routage dynamique, le multicast et le coût en MTU.

Pages voisines

La citent

• Sécuriser un load balancer cloud et la terminaison TLS
• TLS ou tunnel VPN IPsec contre l'homme du milieu

MUSCULAR 2013 : interception des liaisons entre data centers

Elle cite

• ⇄Lien dans les deux sens :Chiffrer les flux est-ouest dans un data center
• Google Street View Wi-Spy 2010 : trames Wi-Fi en clair et droit

⇄ : les deux pages se citent l’une l’autre.