Imaginez une route interurbaine. Vous montez à bord d'un véhicule blindé aux vitres teintées (vous établissez un tunnel cryptographique robuste), vous verrouillez les portes et vous suivez le GPS vers une autre ville. Soudain, à une intersection, des ouvriers routiers en gilets orange déploient un panneau : « Route principale fermée pour travaux. Nouvelle déviation par la carrière — 15 minutes plus le rapide ».

Le GPS recalcule docilement l'itinéraire, vous tournez sur un chemin de terre, et la voiture entre dans un hangar fermé. Les portes sont verrouillées, les vitres sont intactes, le blindage tient bon. Personne n'essaie de forcer l'habitacle avec un pied-de-biche. On vous pousse simplement sur une balance, on vous passe aux rayons X, on photographie les plaques, on relève le poids de la cargaison et on mesure la trace thermique du moteur, avant de rouvrir les portes de l'autre côté pour vous laisser repartir sur l'autoroute.

Vous êtes arrivé à destination à l'heure. Aucune erreur de connexion, le chiffrement n'a pas été piraté. Mais toutes les informations sur le lieu, le moment et la vitesse de votre déplacement ont fini par s'accumuler sur des serveurs tiers.

C'est à peu près ainsi que fonctionne le BGP Hijacking (le détournement de routes au niveau des systèmes autonomes). Les censeurs et les services de renseignement n'ont plus besoin de casser des clés de 256 bits. Il leur suffit de glisser un tout petit mensonge aux routeurs dorsaux voisins : « Ce trafic passera plus vite par chez moi ».

Stop. Si vous croyez encore qu'un VPN avec une icône de bouclier vert protège contre l'interception au niveau des dorsales optiques, fermez cet onglet. Continuez à croire que l'internet est fait de câbles directs.

Mais si vous avez déjà configuré des liaisons de peering, que vous savez à quoi ressemble une table RIB, et que vous voulez comprendre pourquoi le RPKI reste encore un décor pour rapports esthétiques sur la moitié des transits mondiaux, bienvenue sous le capot du routage mondial.

La faille architecturale du protocole de confiance : comment fonctionne le BGP

L'internet mondial repose sur le protocole de passerelle frontière, le Border Gateway Protocol (BGP-4). C'est un club fermé de systèmes autonomes (ASN), bâti dans les années quatre-vingt sur une confiance mutuelle absolue et aveugle.

Les routeurs ne vérifient pas l'existence physique d'une route. Ils s'échangent des messages BGP UPDATE par lesquels ils annoncent des préfixes réseau.

La manipulation de routage repose sur deux vulnérabilités de la logique de sélection du meilleur chemin (BGP Best Path Selection) :

1. La règle du préfixe le plus spécifique (Longest Prefix Match).
2. 
   
3. Si un centre de données légitime annonce un grand réseau /22 (par exemple, 198.51.100.0/22), tandis qu'un nœud de transit malveillant annonce depuis les profondeurs de son réseau deux préfixes étroits en /24 (198.51.100.0/24 et 198.51.101.0/24), le réseau mondial dirigera toujours le trafic vers l'itinéraire le plus spécifique. Les routeurs dorsaux ne jetteront même pas un œil à la réputation de la source : la logique du protocole ordonne d'envoyer les paquets là où le masque est le plus long.
4. 
   
5. L'attaque AS-Path Prepending et Poisoning.
6. 
   
7. En cas de détournement, le préfixe « étranger » est injecté dans la table avec une liste falsifiée de systèmes autonomes (AS_PATH). Pour forcer les paquets à traverser un site d'inspection spécifique (par exemple, un miroir doté d'un cluster DPI), le nœud raccourcit artificiellement la longueur du chemin ou empoisonne les attributs MED (Multi-Exit Discriminator) et Local Preference aux jonctions avec des liaisons amont naïves.
8. 
   

Pourquoi détourner le trafic si la charge utile est chiffrée ?

La principale idée reçue des ingénieurs réseau débutants est d'avoir la certitude qu'un tunnel chiffré (WireGuard, IPsec, OpenVPN) rend le détournement de route totalement inutile.

Lorsque le trafic est redirigé via un nœud intercepteur contrôlé, l'attaquant n'a nul besoin de déchiffrer la charge utile à la volée :

• Corrélation des temps et des volumes (Traffic Analysis & Metadata Correlation).
• 
  
• En comparant le flux entrant depuis l'IP du client et le flux sortant du point de terminaison du tunnel grâce aux pics à la milliseconde près et aux tailles de MTU, le système désanonymise les adresses finales des ressources visitées avec une précision statistique supérieure à 94 %.
• 
  
• Épuisement actif des sessions (Selective RST Injection).
• 
  
• Se trouvant sur la trajectoire directe du trafic (on-path), l'intercepteur peut injecter de manière sélective de faux TCP RST ou interrompre les paquets Keep-Alive du tunnel, forçant l'application cliente à basculer sur un canal de secours non protégé ou à réinitialiser ses sessions via des DNS compromissions.
• 
  
• Man-in-the-Middle lors de la négociation TLS.
• 
  
• Si le tunnel utilise un proxy TLS classique sans épinglage strict (certificate pinning) ni émulation de comportement de navigateur, le nœud de transit délivre un faux certificat émanant d'une autorité de certification nationale de confiance préinstallée de force dans les systèmes d'exploitation clients.
• 
  

Pourquoi le RPKI (ROA) ne protège-t-il pas à 100 % ?

La signature cryptographique des routes — RPKI (Resource Public Key Infrastructure) — est censée protéger le réseau contre les fausses annonces grâce à la création d'objets ROA (Route Origin Authorization). Mais en pratique, l'architecture comporte des angles morts critiques :

• Absence de validation du chemin (BGPsec est mort).
• 
  
• Le RPKI vérifie uniquement le système autonome d'origine (Origin AS) ayant revendiqué le préfixe. Le protocole ne valide pas la chaîne des fournisseurs de transit intermédiaires au sein de l'attribut AS_PATH. Il suffit à l'attaquant d'inclure le numéro légitime de l'AS cible à la fin de la liste de sa fausse annonce pour que le validateur juge la route correcte (Valid).
• 
  
• Politique de dégradation souple (Soft-Fail) chez les opérateurs amont.
• 
  
• De nombreux opérateurs Tier-1 et Tier-2 sont configurés en mode de dégradation logicielle pour préserver la connectivité : lorsqu'ils reçoivent une route marquée NotFound (lorsque le propriétaire du préfixe n'a pas créé d'enregistrement ROA), le trafic continue d'être routé sans restriction.
• 
  

Protocole de défense ingénierie : construire une défense en profondeur

Protéger le périmètre réseau contre l'interception de transit exige des mesures tant du côté du serveur qu'au niveau physique du routeur client.

• Mise en œuvre d'une validation RPKI stricte sur les sessions BGP de bordure.
• 
  
• Si vous gérez votre propre système autonome (BGP Anycast / Multihoming), activez un rejet strict des annonces non valides sur l'ensemble de vos pairs eBGP :
• 
  
• Plaintext
• 
  

# Пример директивы для BIRD2
roa table r4;
protocol rpki {
    roa4 { table r4; };
    remote "rpki-validator.local" port 8282;
}
# В фильтре импорта:
if roa_check(r4, net, bgp_path.last) = ROA_INVALID then {
    reject "Drop: RPKI invalid route detected";
}

• Utilisation de protocoles de transport avec masquage de la taille des paquets (Flow Padding).
• 
  
• Abandon des en-têtes WireGuard statiques en clair sur les canaux transfrontaliers. Migration vers le combo VLESS + REALITY avec l'activation obligatoire des mécanismes de randomisation des paquets (Vision). Cela empêche l'identification du type de trafic par les systèmes d'analyse de flux (NetFlow/IPFIX) sur les nœuds d'interception.
• 
  
• Surveillance des anomalies de préfixes en temps réel.
• 
  
• Connexion aux systèmes d'alerte précoce publics (BGPmon, RIPE RIS, Cloudflare Radar Alerts). Configuration de déclencheurs automatiques : si le préfixe de votre réseau est annoncé via un AS intermédiaire inattendu, des scripts sur le routeur de bordure doivent immédiatement révoquer le préfixe problématique et basculer le trafic vers des interfaces de tunnel de secours empruntant des systèmes autonomes alternatifs.
• 
  
• TCP MD5 / Authentification BGP Keychain.
• 
  
• Toutes les sessions de peering direct avec les liaisons amont doivent obligatoirement être chiffrées à l'aide de clés d'authentification cryptographiques (TCP Authentication Option, TCP-AO), ce qui élimine toute injection de faux paquets BGP UPDATE par des tiers sur le segment physique situé entre vous et votre fournisseur.
• 
  

Il n'existe pas de zones géographiques sécurisées sur l'internet mondial. Tant que l'architecture d'internet fera confiance aux tables de routage tierces sans vérification totale de chaque segment de chemin, le chiffrement aux extrémités ne résoudra que la moitié du problème. La véritable sécurité commence là où l'ingénieur maîtrise non seulement l'algorithme de chiffrement, mais aussi le vecteur de déplacement physique de chaque octet à travers les dorsales mondiales.