Sécurité des réseaux informatiques

Un message peut rester confidentiel tout en étant modifié ou en provenant d’un imposteur. Une communication sécurisée nécessite donc plusieurs propriétés, chacune répondant à une question différente sur l’échange.

Nomme la propriété menacée

Alice et Bob sont les correspondants ; Trudy est l’attaquante. Une attaquante passive capture le trafic sans le modifier. Lire un mot de passe relève de l’écoute. Déduire un emploi du temps chargé à partir des heures de connexion relève de l’analyse du trafic, même lorsque le contenu est chiffré. Une attaquante active injecte, modifie, supprime ou rejoue des paquets. L’usurpation consiste à déclarer une fausse identité source ; le détournement prend le contrôle d’un échange existant ; la submersion cherche à épuiser les ressources.

Les routeurs Internet transfèrent généralement les paquets sans prouver l’authenticité de leurs adresses sources. Les paquets traversent aussi des réseaux qui échappent au contrôle des deux utilisateurs. En Wi-Fi, un autre appareil radio à portée peut capturer les trames transmises. Les protocoles doivent protéger les communications même lorsqu’un attaquant contrôle le chemin.

Suis une connexion exposée

Bob se connecte au point d’accès d’un café et s’identifie en HTTP non chiffré. Trudy lit le mot de passe : la confidentialité est compromise. Elle modifie un lien de téléchargement dans la réponse : l’intégrité est compromise. Si elle fournit un faux point d’accès portant le nom du café, Bob ne dispose pas non plus d’un moyen fiable de vérifier l’identité du point d’accès. Chiffrer uniquement le mot de passe ne corrigerait pas toutes ces failles. Un attaquant peut modifier certains messages chiffrés sans les comprendre et rejouer sans modification un message d’authentification capturé.

Garde la clé secrète

Le principe de Kerckhoffs affirme que la sécurité doit résister à la divulgation de l’algorithme. Le secret est la clé. Un algorithme secret conçu soi-même peut être retrouvé à partir du logiciel ; modifier et distribuer un algorithme entier est aussi plus difficile que remplacer une clé. Remplacer une clé divulguée protège le trafic futur, mais ne sécurise pas les enregistrements réalisés avec l’ancienne clé.

Les connaissances de l’attaquante comptent aussi. Une attaque à texte chiffré seul part de messages chiffrés interceptés. Une attaque à texte clair connu dispose en plus des messages d’origine correspondants, par exemple du texte HTTP/1.1 prévisible commençant par « GET / ». Dans une attaque à texte clair choisi, l’attaquante peut obtenir le chiffrement de messages qu’elle sélectionne. Les chiffrements modernes sont conçus pour résister à ces situations plus exigeantes.

Repère la portion de chemin protégée

La sécurité Wi-Fi et cellulaire protège une liaison radio. TLS protège la communication entre les extrémités applicatives. IPsec protège le trafic IP sélectionné entre des hôtes ou des passerelles. Une protection au niveau du message, comme la messagerie électronique sécurisée, peut rester associée à un message pendant son stockage. Un saut radio sécurisé ne protège pas le reste du trajet sur Internet : une fois que le point d’accès a retiré la protection de la liaison, un autre mécanisme doit protéger la suite du trafic.

Un algorithme de chiffrement symétrique utilise la même clé secrète aux deux extrémités. Le texte en clair est le message d’origine ; le texte chiffré est sa forme chiffrée. Écris le chiffrement $c=E_{K_S}(m)$ et le déchiffrement $m=D_{K_S}(c)$ : la clé est partagée, mais les deux opérations sont inverses.

Taille des clés et faiblesses structurelles

Un décalage de César de 3 transforme « RENDEZ VOUS A MIDI » en « UHQGHC YRXV D PLGL ». Essayer les 25 décalages utiles suffit à le casser. Un chiffrement par substitution possède $26!\approx \mathrm{4,03}\times {10}^{26}$ clés, mais préserve les fréquences des lettres. Un attaquant peut utiliser les lettres répétées et les mots fréquents pour retrouver la correspondance sans essayer toutes les clés. La taille de l’espace de clés ne prouve pas à elle seule la sécurité.

AES est un algorithme de chiffrement par blocs de 128 bits avec des clés de 128, 192 ou 256 bits. DES utilisait des blocs de 64 bits et une clé de 56 bits ; une recherche exhaustive a permis de trouver une clé DES en 1998, et DES et Triple DES ne font plus partie des normes en usage. Chaque bit de clé supplémentaire double le travail de recherche exhaustive. À ${10}^{12}$ essais par seconde, la recherche parmi toutes les clés DES prend environ $2^{56}\mathrm{/}{10}^{12}\approx 72000$ secondes, soit 20 heures ; la découverte prend en moyenne la moitié de ce temps. Chercher parmi toutes les clés AES-128 à ce rythme prend environ $\mathrm{1,1}\times {10}^{19}$ années.

Le mode change la protection du message

Un mode opératoire traite les messages de plus d’un bloc.

Le premier bloc en mode CBC utilise un vecteur d’initialisation, ou IV, à la place du bloc chiffré précédent. L’IV est envoyé en clair ; ce qui compte est qu’il soit imprévisible et nouveau, pas secret. L’ajout d’aléa masque les égalités directement visibles entre messages. Il ne détecte pas en lui-même les altérations.

Étudie la réutilisation d’un flot de clés

Supposons que deux messages utilisent le même flot de clés $k$. Leurs textes chiffrés sont $c_1=m_1\oplus k$ et $c_2=m_2\oplus k$. Leur appliquer un OU exclusif annule le flot de clés répété :

La connaissance d’un texte en clair révèle alors l’autre. Les IV répétés de WEP ont provoqué ce type de défaillance. Une clé de chiffrement plus longue ne corrige pas la répétition d’un flot de clés.

Le chiffrement authentifié avec données associées, ou AEAD, combine confidentialité et intégrité. AES-GCM et ChaCha20-Poly1305 authentifient le texte chiffré et les éventuelles données associées. Les données associées, comme un champ de routage, restent lisibles mais ne peuvent pas être modifiées sans faire échouer la vérification. TLS 1.3 utilise AEAD pour chaque enregistrement protégé.

Distribue le secret

Le chiffrement rapide de grandes quantités de données nécessite toujours une clé partagée. Si chaque paire parmi $n$ utilisateurs a besoin d’une clé différente, le total est de $n(n-1)\mathrm{/}2$. Pour 100 utilisateurs, cela représente 4 950 clés. Les mécanismes à clé publique permettent aux parties d’établir des clés de session sans distribuer au préalable un secret distinct à chaque paire.

Bob publie $K_B^{+}$ et garde $K_B^{-}$ privée. Alice peut chiffrer pour Bob sans avoir d’abord partagé un secret avec lui. Retrouver la clé privée à partir de la clé publique doit être impossible en pratique par le calcul.

Calcule un échange RSA simplifié

RSA commence avec les nombres premiers $p$ et $q$. Calcule $n=pq$ et $z=(p-1)(q-1)$. Choisis un exposant public $e$ premier avec $z$, puis trouve $d$ tel que $ed<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>z=1$. La clé publique est $(n,e)$ ; la clé privée est $(n,d)$. Pour un nombre représentant le message et inférieur à $n$ :

Utilise les nombres premiers simplifiés 11 et 13. Alors $n=143$ et $z=120$. Avec $e=7$, choisis $d=103$ car $7\times 103=721=6\times 120+1$. Pour $m=9$, les mises au carré successives donnent $9^2<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=81$ et $9^4<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=126$. En combinant les puissances, on obtient $9^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=48$. Le déchiffrement donne ${48}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=9$.

Ces nombres rendent les calculs visibles ; en pratique, RSA utilise des modules d’au moins 2 048 bits. La décomposition du module en facteurs révèle les nombres premiers et permet de retrouver la clé. Le chiffrement RSA réel utilise aussi un bourrage OAEP aléatoire : le RSA des manuels sans bourrage produit le même texte chiffré lorsqu’un message se répète.

Établis un secret avec Diffie–Hellman

Diffie–Hellman établit un secret partagé sans l’envoyer. Alice et Bob publient un nombre premier $p$ et un générateur $g$. Alice garde $a$ secret et envoie $A=g^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Bob garde $b$ secret et envoie $B=g^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Alice calcule $B^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$ et Bob calcule $A^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$ ; tous deux obtiennent $g^{ab}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$.

Pour $p=29$, $g=2$, $a=5$ et $b=12$, Alice envoie 3 et Bob envoie 7. Le calcul d’Alice est $7^5<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$ ; celui de Bob est $3^{12}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$. Leur petit exemple est facile à casser ; de grands groupes rendent impossible en pratique la découverte des exposants secrets. Les échanges sur courbes elliptiques comme X25519 remplissent le même rôle avec des clés plus courtes.

Authentifie l’échange

Diffie–Hellman seul n’identifie aucun des participants. Trudy peut substituer ses propres valeurs publiques et créer deux secrets partagés distincts, l’un avec Alice et l’autre avec Bob. Elle lit puis rechiffre le trafic. Un protocole authentifié lie les valeurs échangées à des identités de confiance, à l’aide de signatures et de certificats ou d’un secret partagé établi.

Les protocoles utilisent le chiffrement hybride : les opérations à clé publique établissent une clé de session, et AES ou ChaCha20 traite l’essentiel des données. RSA peut transporter une clé de session aléatoire, mais le vol ultérieur de la clé privée RSA expose les échanges enregistrés. De nouvelles valeurs Diffie–Hellman éphémères, supprimées après usage, assurent la confidentialité persistante contre le vol ultérieur des clés d’authentification à long terme.

Un ordinateur quantique suffisamment grand casserait RSA et Diffie–Hellman classique. ML-KEM, normalisé par le NIST dans FIPS 203 en 2024, répond au besoin d’établissement de clés post-quantique. Une solution hybride telle que X25519MLKEM768 combine des composants classiques et post-quantiques. Dans cet usage, « hybride » décrit deux mécanismes d’établissement de clés ; l’essentiel des données utilise toujours le chiffrement symétrique, notamment des clés de 256 bits pour une grande marge de sécurité.

Une vérification d’intégrité doit résister à un attaquant agissant délibérément, et pas seulement aux erreurs accidentelles. Une somme de contrôle réseau et une fonction de hachage cryptographique ont des rôles différents, et aucune des deux n’authentifie un message à elle seule.

Comprends les propriétés du hachage

Une fonction de hachage cryptographique associe à un message de longueur quelconque une empreinte de taille fixe. SHA-256 produit 256 bits, généralement écrits avec 64 chiffres hexadécimaux. Les bonnes fonctions de hachage présentent trois propriétés de résistance distinctes :

Des collisions existent parce qu’un ensemble fini d’empreintes représente un plus grand nombre de messages possibles. La sécurité signifie qu’il est impossible en pratique de trouver une collision utile. MD5 et SHA-1 font l’objet d’attaques par collision réalisables en pratique et ne conviennent pas aux signatures ni aux certificats. SHA-3 fournit une autre famille moderne de fonctions de hachage.

De petites modifications du message se répercutent sur toute l’empreinte : c’est l’effet d’avalanche. Remplacer « Pay Ana 100 » par « Pay Ana 900 » modifie 124 bits du résultat de SHA-256 ; les empreintes commencent par ECD0D31E et 21736708. À l’inverse, la somme de contrôle Internet de « PAY 1290 » comme de « PAY 9012 » est 0xEC3B : échanger les mots de 16 bits concernés conserve leur somme. Une somme de contrôle conçue pour détecter les dommages aléatoires est facile à conserver délibérément.

Ajoute le secret que l’attaquante ne possède pas

Envoyer un message et son empreinte en clair ne résout pas le problème des altérations actives. Trudy remplace le message et son empreinte : le calcul de vérification du destinataire réussit donc. Un code d’authentification de message, ou MAC, ajoute une clé d’authentification secrète partagée par Alice et Bob.

Alice envoie $m$ et $\mathrm{M}\mathrm{A}\mathrm{C}(s,m)$. Bob calcule un code à partir du message reçu et de sa propre copie de $s$, puis compare les codes. Si Trudy remplace « Paie Ana 100 » par « Paie Ana 900 », Bob calcule le code du texte modifié. L’ancien code copié par Trudy ne correspond pas. Le message peut rester lisible : un MAC assure l’intégrité et l’authentification d’un détenteur de la clé, pas la confidentialité.

HMAC utilise une fonction de hachage en deux passages imbriqués faisant intervenir la clé. HMAC-SHA256 est un choix standard. Utiliser simplement $H(s\mathrm{\parallel }m)$ avec SHA-256 est dangereux : une extension de longueur peut permettre à un attaquant d’ajouter des octets et de calculer un code correspondant sans connaître la clé. La construction de HMAC évite cette faille.

Distingue l’authenticité de la fraîcheur

Un ancien message accompagné de son MAC d’origine possède toujours un code valide. Pour rejeter le rejeu, authentifie un numéro de séquence ou un nouveau défi avec le message, puis vérifie cette valeur de fraîcheur à la réception. Ajouter un numéro non authentifié ne suffit pas, car Trudy pourrait le modifier.

Les deux détenteurs de la clé partagée peuvent produire des codes valides. Un tiers ne peut donc pas utiliser un MAC pour déterminer lequel des détenteurs a écrit un message. Les signatures numériques fournissent cette preuve vérifiable publiquement. Pour combiner chiffrement et MAC distinct, utilise des clés distinctes et chiffre avant de calculer le MAC sur le texte chiffré ; une construction AEAD offre une solution intégrée.

Une signature numérique permet à chacun de vérifier une preuve créée avec une clé privée. La personne ou le système qui vérifie a besoin à la fois d’une vérification fiable de la signature et d’un lien de confiance entre la clé publique et l’identité qu’elle représente.

Signe et vérifie un message

Le signataire utilise une clé privée ; la vérification utilise la clé publique correspondante. Les signatures lient leur preuve au message : une altération fait donc échouer la vérification. La clé privée doit rester sous le contrôle du signataire. Cela permet la non-répudiation : une preuve de signature vérifiable indépendamment, contrairement à un MAC que chacun des détenteurs de la clé partagée pourrait créer.

Les systèmes traitent une empreinte ou une représentation encodée du message. Dans un modèle RSA simplifié, la signature est $K_B^{-}(H(m))$. Le destinataire calcule l’empreinte et la compare à la valeur obtenue avec la clé publique de Bob. Les signatures RSA réelles ajoutent un encodage tel que RSASSA-PSS ; ECDSA et Ed25519 utilisent des calculs différents. La signature n’est pas une méthode générale de chiffrement d’un message avec une clé privée.

Pour une clé RSA simplifiée avec $n=143$, $e=7$ et $d=103$, supposons que le nombre représentant l’empreinte soit 20. Bob calcule $\sigma ={20}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=58$. Alice obtient ${58}^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=20$ et compare le résultat à sa propre empreinte. Si le texte modifié a pour empreinte 21, la valeur 20 obtenue ne correspond pas. La résistance aux collisions compte, car deux messages de même empreinte pourraient sinon fournir la même entrée à la signature.

Lie une clé à un nom

Trudy peut générer une paire de clés parfaitement valide. Si elle présente sa clé publique comme celle de « Bob », la réussite de la vérification d’une signature ne révélera pas à elle seule la substitution. Un certificat lie une identité à une clé publique sous la signature d’une autorité de certification.

Un certificat de site web X.509 contient des noms de domaine dans le champ des noms alternatifs du sujet, la clé publique du sujet, un émetteur, des dates de validité et la signature de l’émetteur. Un serveur fournit normalement son certificat final et les certificats intermédiaires. Le client vérifie cette chaîne jusqu’à une racine à laquelle son système d’exploitation ou son navigateur fait déjà confiance. Ce n’est pas l’autosignature d’une racine qui la rend digne de confiance ; sa présence dans le magasin de certificats de confiance fournit cette confiance initiale.

La vérification porte sur les signatures de la chaîne, les dates de validité, le nom recherché, l’usage autorisé et les informations de révocation lorsqu’elles sont disponibles. Une chaîne qui aboutit à une racine inconnue ne devient pas digne de confiance simplement parce que ses signatures sont mathématiquement valides.

Exige une preuve de possession de la clé

Les certificats sont publics et peuvent être copiés. Un serveur doit aussi montrer qu’il contrôle la clé privée associée en signant de nouvelles données de négociation. Un fichier de certificat volé ne suffit pas à produire cette signature. Un certificat valide ordinaire de site web établit le contrôle de son nom de domaine ; il n’établit pas que le contenu ou l’activité du site est honnête.

L’authentification des extrémités cherche à savoir qui participe à cet instant. Un ancien message valide peut prouver qu’une personne a détenu une clé par le passé, sans prouver que l’émetteur actuel la détient.

Mets en échec les versions faibles

Alice envoie d’abord « Je suis Alice ». Trudy peut envoyer les mêmes mots. Ajouter l’adresse IP source d’Alice échoue, car un datagramme peut contenir une adresse falsifiée. Envoyer un mot de passe l’expose à une personne qui observe. Chiffrer un mot de passe fixe masque son contenu, mais laisse une preuve réutilisable : Trudy enregistre le texte chiffré et l’envoie lors d’une autre connexion.

C’est une attaque par rejeu. L’attaquante ne déchiffre ni ne modifie l’ancienne preuve. La faiblesse vient du fait que Bob accepte les mêmes octets dans une nouvelle session. Un algorithme de chiffrement plus robuste ne corrigerait pas cette erreur de protocole.

Fais dépendre la preuve de cette tentative

Bob envoie un nouveau nonce imprévisible, un défi utilisé une seule fois dans ce contexte d’authentification. Alice renvoie une valeur qui nécessite sa clé secrète, par exemple un HMAC du défi. Bob calcule la réponse attendue avec sa copie de la clé. Une réponse copiée d’un défi antérieur ne correspondra pas.

Par exemple, le défi de lundi est 0x7F3A91C2. Trudy capture sa réponse valide. Mardi, Bob envoie 0x0B66E4D9. Le rejeu de la réponse de lundi échoue, car le code attendu mardi est calculé à partir d’octets différents. Ces courtes valeurs hexadécimales illustrent l’échange ; les défis réels nécessitent suffisamment de bits aléatoires pour éviter une prédiction ou une répétition exploitable.

L’imprévisibilité empêche aussi la collecte à l’avance. Si le prochain défi de Bob est facile à deviner, Trudy peut se faire passer pour Bob, demander à Alice de répondre à ce futur défi, puis présenter plus tard à Bob la réponse recueillie. Un défi doit être lié à l’échange en cours du protocole, et pas seulement paraître différent du précédent.

Authentifie avec des clés publiques

Alice peut signer un nouveau défi avec sa clé privée. Bob vérifie la signature avec la véritable clé publique d’Alice. Si Bob accepte une clé publique de substitution fournie par Trudy, celle-ci peut signer elle-même le défi de Bob. Les certificats établissent le lien entre l’identité et la clé ; la nouvelle signature prouve la possession actuelle de cette clé.

Dans l’authentification mutuelle, les deux pairs prouvent leur identité. Un protocole doit distinguer leurs rôles et lier les preuves à la session afin que la réponse d’une partie ne puisse pas simplement être renvoyée comme celle de l’autre. Sur le Web, TLS authentifie généralement le serveur avec un certificat ; l’utilisateur s’authentifie ensuite dans ce canal protégé avec un mot de passe ou une clé d’accès. Les connexions entre services et les réseaux privés virtuels authentifient souvent les deux extrémités.

Protège la suite de la session

Une authentification réussie ne protège pas le trafic ultérieur en clair. Trudy pourrait attendre la fin de la connexion de l’utilisateur, puis injecter des commandes ou détourner la connexion. Les négociations sécurisées établissent des clés de session et les messages suivants bénéficient d’une protection de l’intégrité liée à cette session.

Le défi-réponse ne renforce pas non plus automatiquement un mot de passe humain faible. Si une personne qui observe peut recalculer une réponse capturée pour chaque mot de passe essayé, elle peut mener une attaque par dictionnaire hors ligne. La vérification de fraîcheur empêche le rejeu, tandis qu’un secret robuste ou un échange adapté authentifié par mot de passe répond aux essais de mots de passe ; ces deux protections résolvent des problèmes différents.

TLS fournit à deux processus applicatifs un canal confidentiel et authentifié sur un flux d’octets fiable. Dans le cas courant de HTTPS, HTTP utilise TLS sur TCP, généralement sur le port 443. Une bibliothèque applicative comme OpenSSL ou BoringSSL gère TLS ; TCP transporte ses octets sans les interpréter.

Établis les clés, puis protège les enregistrements

Une négociation authentifie le pair et établit des éléments de clé partagés. La dérivation des clés transforme ces éléments en secrets distincts pour le trafic de négociation et les données applicatives, avec des clés différentes pour chaque sens. Un enregistrement envoyé par Alice ne peut pas simplement lui être renvoyé comme s’il provenait de Bob, car le sens de réception utilise une protection différente.

TLS découpe les données en enregistrements, ce qui permet au destinataire de vérifier un élément à la fois. Un enregistrement en clair contient au plus $2^{14}=16384$ octets de contenu. Son court en-tête comprend un type, un ancien champ de version et une longueur. Le chiffrement ajoute des données supplémentaires : un enregistrement chiffré est donc plus grand que le contenu d’origine. Dans TLS 1.3, le type externe de l’enregistrement protégé ne révèle pas directement le type du contenu applicatif ou de négociation qu’il renferme.

TLS 1.3 impose le chiffrement AEAD. Le destinataire vérifie le code d’authentification d’un enregistrement avant de transmettre son texte en clair à l’application. Si Trudy modifie une requête HTTP protégée, la vérification du code échoue : le destinataire met fin à la connexion en utilisant bad_record_mac pour signaler un échec de protection de l’enregistrement. TLS détecte l’altération ; il ne transforme pas les octets modifiés de façon malveillante en une requête valide.

Compte les enregistrements dans chaque sens

Chaque émetteur et chaque récepteur maintient un numéro de séquence implicite pour les enregistrements. Il n’est pas envoyé dans l’en-tête de l’enregistrement TLS. TLS 1.3 lui applique un OU exclusif avec un IV propre à chaque sens pour produire le nonce AEAD. Rejouer un ancien enregistrement à un nouvel endroit utilise un numéro différent de celui attendu et fait échouer l’authentification. Supprimer ou réordonner des enregistrements protégés perturbe de même la séquence attendue lorsque les octets suivants sont traités.

Les numéros de séquence TCP assurent toujours l’acheminement et le réordonnancement ordinaires. Ils n’authentifient pas le pair : un attaquant qui contrôle le chemin peut falsifier les en-têtes TCP. Le décompte des enregistrements TLS est lié à une protection à clé secrète : un acheminement TCP réussi ne signifie donc pas à lui seul que la vérification TLS réussira.

Détecte une fin incomplète

Supposons que Bob attende un document, mais que la connexion TCP se ferme à mi-parcours. Un FIN falsifié ou une liaison rompue peut mettre fin à l’acheminement sans prouver que l’émetteur TLS a terminé. TLS utilise l’alerte protégée close_notify pour signaler une fin normale de son flux d’émission. Sans elle, le destinataire doit envisager une troncature possible et appliquer les règles de l’application pour vérifier que les données sont complètes ; une fin de fichier TCP inattendue n’est pas un marqueur de fin authentifié.

Un attaquant peut toujours rejeter des paquets et interrompre la progression. La confidentialité et l’intégrité ne garantissent pas la disponibilité. La longueur complète d’un message HTTP peut aider une application à reconnaître qu’un message est arrivé, mais cette vérification est distincte de celle d’une fermeture TLS normale.

Distingue les protocoles apparentés

TLS 1.3 est défini par la RFC 9846, qui a remplacé la RFC 8446 en 2026. TLS 1.2 reste déployé ; SSL 2.0/3.0 et TLS 1.0/1.1 sont obsolètes. DTLS adapte la conception de sécurité aux datagrammes. QUIC transporte la négociation TLS 1.3 dans son protocole de transport fondé sur UDP, puis protège lui-même les paquets QUIC ; il ne transporte pas sur UDP les enregistrements ordinaires de TLS sur TCP.

Une négociation TLS doit établir un secret et montrer à qui il appartient. Dans un échange TLS 1.3 complet fondé sur un certificat, un accord de clés éphémère fournit de nouveaux éléments de clé et des signatures lient la négociation à l’identité du serveur.

Suis les ensembles de messages

1. ClientHello propose des versions, des suites cryptographiques AEAD, des groupes d’échange de clés, des algorithmes de signature, des données aléatoires et une ou plusieurs valeurs key_share. Il indique généralement le nom du serveur par SNI.
2. ServerHello sélectionne les paramètres et fournit la part de clé du serveur. Les deux pairs calculent des éléments de clé partagés et en dérivent les clés du trafic de négociation.
3. Le serveur envoie les messages chiffrés EncryptedExtensions, Certificate, CertificateVerify et Finished. CertificateVerify signe une entrée structurée comprenant l’empreinte de la transcription de la négociation ; Finished authentifie la transcription avec une clé MAC dérivée.
4. Le client vérifie la chaîne, le nom du serveur, la signature et Finished, puis envoie son propre Finished. Le trafic applicatif utilise des secrets de trafic dérivés séparément.

Le certificat du serveur associe un nom à une clé publique. CertificateVerify prouve le contrôle de la clé privée dans cet échange. Finished détecte les altérations de la transcription de la négociation. Ce sont des vérifications distinctes : réussir à dériver un secret partagé n’établit pas l’identité du serveur.

Compte les allers-retours

Avec un RTT de 40 ms, en négligeant les délais de traitement et de transmission, l’établissement TCP prend 40 ms et une négociation TLS 1.3 complète ajoute 40 ms. Le client envoie sa requête à 80 ms ; une réponse peut revenir vers 120 ms. Une négociation TLS 1.2 complète ajoute deux RTT après TCP : les temps correspondants sont donc de 120 ms et 160 ms. QUIC combine l’établissement du transport et la négociation TLS, ce qui permet à une nouvelle connexion d’envoyer sa requête après un RTT, à 40 ms.

Un HelloRetryRequest ajoute un aller-retour lorsque le serveur a besoin d’une autre part de clé. La prise en charge commune d’un groupe ne suffit pas si la proposition initiale ne contenait pas de part acceptable.

Lie la négociation et sépare les secrets

Si Trudy retire des suites cryptographiques robustes d’un ClientHello pendant son acheminement, le client et le serveur enregistrent des transcriptions différentes. L’authentification de ces transcriptions échoue. TLS comprend aussi un signal de déclassement de version lorsqu’un serveur capable d’utiliser une version plus récente négocie une version antérieure.

Le processus de dérivation des clés utilise HKDF, fondé sur HMAC, pour dériver des secrets propres à chaque usage. Les clés de négociation protègent les messages d’établissement ; les clés applicatives protègent les données ultérieures. KeyUpdate remplace les clés de trafic applicatif pendant une longue connexion. TLS 1.3 a supprimé le transport de clé RSA statique : un certificat RSA peut toujours authentifier une négociation par signature, tandis qu’un accord de clés éphémère assure la confidentialité persistante.

Reprends sans répéter l’authentification par certificat

Après l’établissement, NewSessionTicket permet aux pairs de préparer la reprise. Ils dérivent une PSK de reprise à partir du secret de reprise et du nonce du ticket ; le client présente ensuite le ticket comme identifiant de la PSK et prouve qu’il la détient. La reprise peut comprendre un nouvel échange Diffie–Hellman pour assurer la confidentialité persistante.

0-RTT envoie des données précoces avec le premier ensemble de messages, mais ces données peuvent être rejouées. Utilise ce mécanisme uniquement lorsque la répétition d’une requête est sans risque, jamais pour une opération de paiement pouvant être répétée sans protection. Les protections de la négociation ultérieure ne rendent pas rétroactivement les données précoces résistantes au rejeu.

TLS mutuel ajoute un certificat client demandé et une preuve de possession de sa clé privée. Les groupes hybrides post-quantiques tels que X25519MLKEM768, défini dans la RFC 10024, combinent X25519 et ML-KEM-768 pour que le secret reste protégé si au moins l’un des composants reste sûr.

Le chiffrement n’est utile que s’il atteint le pair souhaité. Un client doit valider l’identité associée aux clés avant d’envoyer des données applicatives sensibles.

Vérifie l’ensemble de l’identité déclarée

Un client TLS vérifie que la chaîne de certificats atteint une racine présente dans son magasin de certificats de confiance, que les signatures et les périodes de validité sont correctes, que le nom demandé correspond au certificat et que celui-ci autorise l’authentification d’un serveur TLS. Lorsqu’il vérifie la révocation, cette vérification doit aussi réussir. CertificateVerify démontre ensuite la possession de la clé privée correspondante.

La correspondance des noms porte sur l’hôte que le client voulait contacter, et non sur un nom suggéré par le serveur après la connexion. Un certificat pour *.example.com couvre www.example.com et mail.example.com. Il ne couvre ni example.com ni a.b.example.com : le caractère générique remplace exactement une composante du nom. Un certificat parfaitement valide pour le mauvais domaine échoue tout de même à l’authentification.

Par exemple, un client demande shop.example.net mais reçoit un certificat valide et de confiance pour *.example.com. La chaîne et les dates peuvent être acceptées ; la vérification du nom échoue. Le client doit rejeter cette connexion. Un certificat n’autorise pas son détenteur à se faire passer pour n’importe quel serveur.

Comprends une interception chiffrée

Si la vérification des certificats est désactivée, Trudy peut terminer la connexion TLS provenant du client et créer une seconde connexion TLS vers le véritable serveur. Les deux liaisons sont chiffrées, mais Trudy dispose du texte en clair entre les deux. Vérifier le chiffrement sans vérifier le pair laisse donc passer l’attaque. Maintiens la validation des certificats activée et traite un échec de vérification d’identité comme un échec de connexion.

Un serveur mandataire d’inspection TLS d’une organisation suit délibérément une structure apparentée. Les appareils administrés font confiance à la racine de l’organisation, ce qui permet à son serveur mandataire de délivrer des certificats qu’ils acceptent. Le serveur mandataire termine une connexion sécurisée et en ouvre une autre. Le chemin entre le navigateur et le serveur comporte alors une extrémité de confiance supplémentaire ayant accès au texte en clair.

Protège la première requête

Lors d’un déclassement HTTPS, un attaquant maintient le côté utilisateur en HTTP tout en contactant le site en HTTPS. Cela peut commencer lorsqu’un navigateur essaie d’abord une adresse sans protocole en HTTP. HSTS indique au navigateur d’utiliser HTTPS pour les visites ultérieures. Une entrée préchargée peut imposer HTTPS avant même la première visite ; une politique apprise seulement après une visite HTTPS réussie ne peut pas protéger rétroactivement une requête HTTP antérieure.

Identifie ce qui reste visible

TLS 1.3 chiffre le certificat du serveur et le contenu applicatif, mais les observateurs voient toujours les adresses réseau, les ports, le moment des échanges et les tailles des enregistrements. Le SNI ordinaire du ClientHello expose le nom du serveur demandé. Encrypted Client Hello, normalisé dans la RFC 9849, protège ce nom lorsqu’il est déployé. Une résolution DNS qui n’est pas protégée séparément peut aussi révéler le nom de destination.

TLS protège les données entre ses extrémités pendant leur acheminement. Il ne peut pas corriger un logiciel malveillant sur le client, un serveur compromis, des données stockées sans protection ou des failles applicatives. Il ne peut pas non plus empêcher le rejet de paquets. IPsec intervient à une autre échelle : il applique une protection à la couche réseau à une sélection de trafic IP sans imposer à chaque application d’utiliser TLS. Les deux peuvent protéger des portions différentes d’un même trajet.

IPsec applique une protection à la couche IP, où il peut couvrir le trafic TCP, UDP et ICMP sans modifier les applications correspondantes. Ses extrémités peuvent être des hôtes individuels ou des passerelles reliant des réseaux entiers.

Choisis un protocole et un mode

AH utilise le numéro de protocole IP 51 ; ESP utilise 50. ESP est le choix habituel pour le trafic des réseaux privés virtuels modernes. La protection d’AH comprend des champs d’adresse que le NAT réécrit, ce qui rend la traduction d’adresses ordinaire incompatible avec sa vérification d’authentification. ESP n’authentifie pas l’en-tête IP externe.

En mode transport, l’en-tête ESP se trouve entre l’en-tête IP d’origine et le segment de transport. Les routeurs voient toujours la source et la destination d’origine. En mode tunnel, un nouvel en-tête IP contient les adresses des deux extrémités du tunnel et le datagramme IP d’origine voyage à l’intérieur. Avec ESP chiffré en mode tunnel, les observateurs extérieurs ne peuvent pas lire les adresses des hôtes d’origine ni les ports de transport, mais ils peuvent lire les adresses des passerelles nécessaires au transfert. AH en mode tunnel n’assure toujours aucune confidentialité.

IPsec peut assurer la confidentialité, l’intégrité, l’authentification de l’origine et la protection anti-rejeu. Les services effectifs dépendent du protocole, des algorithmes et de la politique ; choisir AH ne fournit pas de chiffrement simplement parce qu’il fait partie d’IPsec.

Conserve un état dans chaque sens

Une association de sécurité, ou SA, définit un sens de trafic protégé. Elle contient les algorithmes, les clés, le mode, les extrémités, l’état des numéros de séquence, l’état de la fenêtre anti-rejeu et une durée de vie. Un index des paramètres de sécurité, ou SPI, de 32 bits aide le récepteur à sélectionner la bonne association. C’est un identifiant, pas une clé de chiffrement ; il peut circuler en clair dans l’en-tête ESP.

Le trafic dans les deux sens nécessite deux associations de sécurité IPsec. Une passerelle de siège desservant une succursale et 50 ordinateurs portables en déplacement a 51 pairs. Avec une paire ESP par pair, elle a besoin de $2\times 51=102$ associations ESP, plus une association IKE par pair pour la gestion. Le renouvellement des clés ou des classes de trafic distinctes peuvent ajouter d’autres associations ; le décompte ici suit la conception indiquée avec une paire par pair.

Bien que le transfert IP soit sans connexion, cet état cryptographique est maintenu aux extrémités qui assurent la protection. Les routeurs intermédiaires n’ont pas besoin de connaître les clés de session ni de maintenir l’association de sécurité IPsec.

Distingue la politique de l’état de protection actif

La base des politiques de sécurité (SPD) recherche les correspondances avec des sélecteurs de trafic tels que les adresses, les protocoles et les ports. Elle décide de protéger le trafic sélectionné, de le laisser passer sans protection ou de le rejeter. La base des associations de sécurité (SAD) stocke les paramètres et l’état évolutif des associations établies. Un récepteur utilise le SPI du paquet et le contexte pertinent pour retrouver cet état.

La SPD répond à « Que doit-il arriver à ce trafic ? ». La SAD répond à « Quelles clés et quels compteurs établis mettent en œuvre cette protection ? ». Une politique de réseau privé virtuel peut protéger les sous-réseaux des bureaux tout en laissant une autre destination passer sans protection. Activer IPsec ne signifie pas que chaque paquet envoyé par un hôte entre dans un tunnel.

Un réseau privé virtuel entre sites relie deux réseaux par des passerelles ; un réseau privé virtuel d’accès distant relie l’appareil d’un utilisateur à une passerelle. Tous deux encapsulent le trafic afin que les routeurs Internet ordinaires puissent le transporter entre les extrémités qui assurent la protection.

Établis les associations

IKEv2 établit les clés et les associations de sécurité. IKE_SA_INIT échange des propositions d’algorithmes, des valeurs Diffie–Hellman et des nonces. Les clés obtenues protègent IKE_AUTH, où les pairs authentifient leur identité et créent la première paire d’associations de sécurité ESP. Avec des signatures ou une clé prépartagée, cela prend normalement quatre messages en deux allers-retours. L’authentification EAP peut ajouter des échanges IKE_AUTH. Des échanges ultérieurs créent d’autres associations ou remplacent les clés proches de l’expiration.

IKE utilise d’abord le port UDP 500. Lorsqu’un NAT est détecté, IKE et ESP encapsulé dans UDP utilisent le port 4500. ESP lui-même n’a pas de ports TCP ou UDP ; l’encapsulation permet aux correspondances NAT fondées sur les ports de le transporter de manière fiable, y compris pour plusieurs clients. Le transport externe change, tandis qu’ESP protège toujours le trafic interne.

Envoie un datagramme

L’hôte 10.1.0.5 envoie un datagramme à 10.2.0.9. La passerelle de la succursale est 198.51.100.1 ; le siège utilise 203.0.113.1.

1. La SPD de la succursale sélectionne une protection par tunnel pour le sous-réseau de destination et la passerelle obtient l’association de sécurité correspondante.
2. Elle traite le datagramme d’origine complet comme la charge utile interne d’ESP, en ajoutant une fin de paquet avec le bourrage, sa longueur et la valeur 4 du champ d’en-tête suivant pour IPv4.
3. Elle chiffre le datagramme interne et la fin de paquet, puis ajoute l’en-tête ESP contenant le SPI et le numéro de séquence suivant. La protection de l’intégrité couvre l’en-tête ESP et la charge utile protégée ; un algorithme AEAD intègre le chiffrement et la génération du code.
4. Elle ajoute l’en-tête IP externe, adressé de la passerelle de la succursale à celle du siège. ESP natif utilise le protocole 50 ; la traversée de NAT transporte ESP dans UDP.

Les routeurs Internet voient les adresses des extrémités externes. Les adresses et les ports internes se trouvent dans la charge utile chiffrée.

Reçois et authentifie

Le siège utilise le SPI pour sélectionner une association de sécurité, vérifie d’abord le numéro de séquence, vérifie l’intégrité et déchiffre. Il ne met à jour l’état anti-rejeu de confiance qu’après la réussite de l’authentification. Il retire la protection du tunnel et transfère le datagramme d’origine retrouvé à 10.2.0.9. Le champ d’en-tête suivant identifie la charge utile retrouvée : 4 pour IPv4, 41 pour IPv6 ou 6 pour TCP dans un exemple ESP en mode transport.

Accepte le réordonnancement mais rejette le rejeu

Une fenêtre anti-rejeu de 64 paquets dont le plus grand numéro authentifié est 1 000 couvre de 937 à 1 000. Le paquet 990, jamais vu auparavant, peut arriver en retard et être accepté. Sa copie suivante est rejetée. Le paquet 930 est trop ancien. Après un paquet valide 1 005, la fenêtre couvre les numéros compris entre 942 et 1 005. Un attaquant ne peut pas déplacer la fenêtre de confiance simplement en envoyant un paquet non authentifié avec un grand numéro.

Un réseau privé virtuel ne protège que le chemin entre ses extrémités. Après le retrait du tunnel, l’acheminement interne nécessite sa propre protection lorsque c’est nécessaire. La tunnellisation fractionnée envoie une partie du trafic hors du réseau privé virtuel. Un réseau privé virtuel commercial fait de son fournisseur un autre opérateur réseau auquel on fait confiance. Les réseaux privés virtuels fondés sur TLS ou DTLS et WireGuard utilisent d’autres protocoles pour mettre en œuvre des tunnels ; « réseau privé virtuel » désigne l’organisation du réseau, pas un protocole de chiffrement obligatoire.

Une trame Wi-Fi est accessible aux appareils radio à portée. Un attaquant proche peut capturer le trafic ou annoncer un jumeau maléfique, un faux point d’accès utilisant un nom de réseau familier. La sécurité sans fil doit authentifier l’accès et protéger les trames, et non simplement masquer le nom du réseau.

Pourquoi WEP a échoué

WEP combinait un secret partagé de 40 ou 104 bits à un IV public de 24 bits pour initialiser RC4. Sa vérification CRC-32 détectait les erreurs, mais n’était pas un mécanisme d’authentification à clé. L’espace des IV ne compte que $2^{24}=16777216$ possibilités ; avec des IV choisis aléatoirement, la probabilité d’une répétition atteint environ 50 % après à peu près 4 823 trames.

Un IV répété avec la même clé reproduit le même flot de clés. Appliquer un OU exclusif à deux textes chiffrés révèle alors le OU exclusif des textes en clair. La structure linéaire de CRC-32 permet aussi à un attaquant de modifier des bits et d’ajuster la vérification d’erreur. Des faiblesses dans la génération des clés de RC4 permettaient de retrouver la clé à partir de trames capturées. Ces défaillances concernent la réutilisation de nonces, l’intégrité non authentifiée et la construction du chiffrement ; choisir simplement un nom de réseau moins évident ne corrige aucune d’elles.

Remplace la protection des trames

WPA2, fondé sur IEEE 802.11i, utilise CCMP : le chiffrement AES en mode compteur combiné à l’intégrité CBC-MAC. Son numéro de paquet aide à construire des nonces uniques et à rejeter le rejeu. L’ancien WPA/TKIP était une mesure transitoire pour les matériels anciens et est obsolète.

La connexion passe par la découverte, l’authentification qui établit une clé maîtresse par paire (PMK), la négociation en quatre temps et le transfert protégé. Dans WPA2-Personal, une phrase secrète et le nom du réseau produisent une PMK de 256 bits par PBKDF2 avec 4 096 itérations de HMAC-SHA1. Toute personne utilisant cette phrase secrète et ce SSID dérive la même PMK. L’authentification n’a pas encore fourni de nouvelle clé de trafic propre à l’association.

Suis la négociation en quatre temps

1. Le point d’accès envoie ANonce.
2. La station génère SNonce et dérive la PTK à partir de la PMK, des deux nonces et des deux adresses MAC. Elle envoie SNonce et un code d’intégrité du message (MIC).
3. Le point d’accès dérive la même PTK et vérifie le MIC. Il fournit la clé de trafic de groupe (GTK) dans un message protégé.
4. La station confirme la réception et l’installation.

La PMK n’est pas envoyée pendant la négociation. De nouveaux nonces produisent de nouvelles clés de session à partir de la PMK existante. La GTK sert au trafic de groupe, tandis que la clé par paire sert à la communication entre cette station et le point d’accès.

Comprends ce que permet le mot de passe

Une négociation WPA2-Personal capturée permet de tester des mots de passe hors ligne : dériver une PMK et une PTK candidates, recalculer le MIC et le comparer à celui de la capture. Un utilisateur qui connaît déjà la phrase secrète du réseau peut aussi dériver la PTK d’un autre utilisateur à partir de la négociation capturée de celui-ci. KRACK exploitait la réinstallation de clés et la réutilisation de nonces dans certaines implémentations ; des correctifs remédient à cette faille.

WPA2-Enterprise utilise 802.1X. La station est le solliciteur ; le point d’accès est l’authentificateur et relaie EAP vers un serveur d’authentification, généralement par RADIUS. EAP-TLS utilise des certificats clients ; PEAP et EAP-TTLS transportent les identifiants dans une protection TLS. Les utilisateurs obtiennent des éléments de clé individuels et leur accès peut être révoqué séparément. Dans les deux modes, la protection Wi-Fi s’arrête au point d’accès ; TLS peut poursuivre la protection jusqu’à un serveur applicatif.

Une liaison sans fil protégée nécessite une méthode fiable pour établir ses clés. WPA3 modifie l’établissement des clés Wi-Fi fondé sur un mot de passe, tandis que les réseaux cellulaires partent d’un secret d’abonné détenu par la carte SIM et le réseau nominal.

Améliore le Wi-Fi à mot de passe

WPA3-Personal utilise SAE, l’authentification simultanée des égaux, pour établir la PMK. Un échange SAE capturé ne permet pas de tester les mots de passe hors ligne comme avec WPA2 : chaque essai nécessite une interaction active. SAE assure aussi la confidentialité persistante : la découverte ultérieure du mot de passe n’expose donc pas les sessions passées enregistrées. La négociation en quatre temps dérive ensuite les clés de trafic à partir de la PMK.

WPA3 exige la protection des trames de gestion (PMF), qui authentifie les trames de gestion robustes telles que les messages de désauthentification. Cela bloque les faux messages de fermeture ; cela ne peut pas empêcher le brouillage radio. WPA3-Enterprise conserve 802.1X et propose un mode de sécurité facultatif de 192 bits utilisant des algorithmes plus robustes tels que GCMP-256.

Le mode de transition accepte WPA2 et WPA3 sous un même nom de réseau. Cette compatibilité peut exposer les appareils à la solution WPA2, moins robuste. Dans la bande des 6 GHz, WPA3 ou Enhanced Open est obligatoire et le mode de transition WPA2 n’est pas autorisé ; WPA3-Personal utilise la méthode de hachage vers un élément de SAE.

Enhanced Open, fondé sur OWE, établit un chiffrement sans mot de passe grâce à Diffie–Hellman. Il empêche les personnes qui écoutent passivement de lire les trames, mais n’authentifie pas le point d’accès. Un jumeau maléfique peut établir sa propre liaison chiffrée avec l’utilisateur.

Authentifie un abonné cellulaire

Un secret à long terme $K$ réside dans l’USIM et dans l’infrastructure d’authentification du réseau nominal : HSS en 4G et UDM/ARPF en 5G. Un réseau visité reçoit des données d’authentification sans connaître ce secret à long terme.

Dans 4G AKA, la MME du réseau visité obtient du HSS nominal un vecteur contenant RAND, AUTN, XRES et des éléments de clé. Le téléphone reçoit le défi aléatoire RAND et le jeton d’authentification AUTN. Son USIM vérifie AUTN pour authentifier le réseau et la fraîcheur du défi, puis calcule RES. Le réseau visité accepte l’abonné lorsque RES correspond à XRES. Les clés dérivées protègent les communications ultérieures.

Il s’agit d’une authentification mutuelle. L’ancienne 2G GSM authentifiait le téléphone auprès du réseau, mais ne donnait pas au téléphone un moyen équivalent de vérifier le réseau, ce qui permettait les attaques par fausse station de base. L’authentification mutuelle nécessite toujours des algorithmes sûrs et une bonne gestion des clés ; le secret à long terme n’a jamais besoin d’être envoyé au réseau visité.

Dissimule l’identité permanente

En 5G, le réseau nominal prend la décision finale d’authentification. Le téléphone peut aussi dissimuler la partie propre à l’abonné de son identité permanente, le SUPI, en utilisant la clé publique du réseau nominal pour former le SUCI. Les informations de routage restent lisibles afin que la requête puisse atteindre le bon réseau nominal.

La dissimulation nécessite un mécanisme de protection configuré. Le mécanisme nul laisse l’identité sans protection. Un SUCI protégé réduit l’exposition aux appareils qui demandent les identités permanentes ; il ne rend pas anonyme toute l’activité radio. Après l’enregistrement, des identifiants temporaires réduisent l’usage courant de l’identité permanente. La sécurité de l’accès cellulaire ne protège toujours pas l’ensemble du trajet jusqu’à un serveur applicatif : TLS fournit cette protection distincte entre les extrémités applicatives.

Un pare-feu applique une politique entre des réseaux ou des segments de réseau. Il ne fonctionne que si le trafic concerné le traverse, et le pare-feu lui-même doit résister aux compromissions. Un filtre sans état prend une nouvelle décision pour chaque paquet à partir des champs d’en-tête.

Lis une règle avec précision

Une règle peut porter sur les adresses IP source et destination, le protocole de transport, les ports, les drapeaux TCP, le type ICMP, l’interface et le sens du trafic. Les règles sont évaluées dans l’ordre : la première correspondance détermine l’action. Une règle finale de refus par défaut rejette les paquets qui ne correspondent à aucune règle d’autorisation.

Pour le réseau 203.0.113.0/24, considérons un serveur web à l’adresse 203.0.113.10 :

Un SYN de 198.51.100.7:50000 vers le port 443 du serveur web correspond à la règle 1. Un SYN vers son port 22 atteint la règle 3 et est rejeté. Une réponse du port 443 du serveur avec ACK activé correspond à la règle 2. Chaque champ d’une règle compte : un paquet utilisant le port UDP 443 ne correspond pas à une règle autorisant TCP.

Repère les règles masquées

Supposons qu’une règle précédente indique « autoriser TCP entrant vers tout hôte de 203.0.113.0/24 sur tous les ports ». Une règle ultérieure refusant SSH vers 203.0.113.10 n’a aucun effet : l’autorisation générale précédente a déjà déterminé l’action. Vérifie l’ordre des règles ainsi que le contenu de chacune. Place les exceptions voulues avant la règle générale qui leur correspondrait autrement.

Le refus par défaut est utile, car l’ajout d’un nouveau service ne le rend pas accessible à l’insu de l’administrateur. L’autorisation par défaut a l’effet inverse : tout trafic non explicitement bloqué passe. Aucun des deux choix ne corrige une table de règles mal ordonnée.

Reconnais le raccourci fondé sur ACK

Une politique peut bloquer les paquets SYN entrants dont ACK est désactivé pour empêcher les nouvelles connexions TCP initiées de l’extérieur. Pour autoriser les réponses aux clients internes, un filtre sans état pourrait accepter le trafic TCP entrant provenant du port source 443 lorsque ACK est activé. Trudy peut fabriquer à la fois ce port source et ce drapeau. Le filtre ne conserve aucun historique prouvant qu’un hôte interne a réellement ouvert la connexion.

Le drapeau TCP ACK est un champ choisi par l’émetteur, pas un certificat attestant une session établie. Le filtrage avec état améliore cette décision en consultant l’historique des connexions.

Filtre les adresses falsifiées

Le filtrage en entrée peut rejeter les paquets provenant d’Internet qui déclarent une adresse source interne ou une adresse privée qui ne devrait pas arriver par là. Le filtrage en sortie rejette les paquets sortants dont la source se situe hors des plages attribuées à l’organisation. Ces vérifications limitent l’usurpation des plages interdites ; elles n’identifient pas un hôte individuel et n’empêchent pas une machine d’usurper une autre adresse interne autorisée.

Les filtres sans état inspectent les en-têtes, pas le sens des données applicatives. Le port 443 ne prouve pas que le trafic est HTTPS ou inoffensif. Une connexion autorisée peut transporter un contenu malveillant. Le filtrage de paquets fonctionne donc aux côtés des passerelles applicatives, des contrôles sur les hôtes et de la détection d’intrusion.

Un pare-feu avec état ajoute du contexte au filtrage des paquets. Une passerelle applicative ajoute une compréhension des requêtes d’une application. La séparation des réseaux limite les ressources qu’un serveur public compromis peut atteindre.

Suis le flux réel

Un filtre de paquets avec état enregistre les adresses, les ports, le protocole et l’état de la connexion. Lorsqu’un client interne ouvre une connexion autorisée, le pare-feu crée une entrée et autorise les paquets de retour appropriés. Une nouvelle connexion entrante nécessite toujours sa propre autorisation explicite. Les entrées expirent lorsque la connexion se ferme ou devient inactive.

Supposons que la table enregistre un flux TCP établi de 203.0.113.25:51000 vers 198.51.100.80:443. Un segment entrant qui inverse cette paire d’adresses et de ports peut correspondre à son état. Un ACK de 192.0.2.66:443 vers 203.0.113.30:52000 ne correspond pas à l’entrée. Son port source et son drapeau ACK satisferaient une règle de réponse sans état peu restrictive, mais ne prouvent pas son appartenance à la connexion suivie.

UDP ne possède pas d’établissement de connexion comparable à TCP. Les filtres avec état reconstituent approximativement un échange en suivant les paires d’adresses et de ports récemment utilisées avec un délai d’expiration. Une requête DNS vers un serveur choisi ouvre une possibilité limitée pour la réponse correspondante, et non une autorisation pour chaque paquet se présentant comme du DNS.

Inspecte la requête applicative

Une passerelle applicative, ou serveur mandataire, reçoit et traite le trafic applicatif pour le compte des utilisateurs. Un serveur mandataire web peut authentifier un utilisateur et vérifier qu’une adresse ou un contenu demandé respecte la politique. Pour imposer ce passage, le filtre de paquets doit empêcher les clients d’ouvrir des connexions directes qui contournent le serveur mandataire.

Un serveur mandataire comporte une logique propre au protocole, des coûts de traitement et des risques de goulot d’étranglement. Les clients peuvent nécessiter une configuration, ou le réseau peut intercepter le trafic de manière transparente. Le contenu chiffré reste masqué au serveur mandataire, sauf s’il termine la connexion TLS et crée une autre connexion pour la suite du trajet. Cela modifie l’ensemble des extrémités auxquelles on fait confiance pour accéder au texte en clair.

Isole les serveurs publics

Une zone démilitarisée (DMZ) est un segment distinct destiné aux services publics. Le pare-feu autorise certains trafics d’Internet vers la zone démilitarisée tout en limitant l’accès de celle-ci au réseau interne. Si un serveur web est compromis, l’attaquant n’obtient pas automatiquement un accès interne sans restriction. Toute connexion nécessaire de la zone démilitarisée vers le réseau interne devrait faire l’objet d’une politique précise.

C’est la défense en profondeur : plusieurs contrôles réduisent différents risques de défaillance. Un pare-feu installé sur un hôte reste utile lorsqu’un ordinateur portable infecté se trouve déjà à l’intérieur ou qu’une autre liaison contourne le périmètre. Une architecture de confiance zéro n’accorde pas l’accès simplement parce qu’un appareil se trouve sur un sous-réseau interne ; elle authentifie et autorise les requêtes. La position dans le réseau peut éclairer la politique, mais ne peut pas remplacer les vérifications d’identité et d’autorisation.

Un pare-feu peut autoriser une connexion qui transporte une attaque. La détection d’intrusion examine le contenu et les motifs du trafic à la recherche de signes d’usage malveillant ; la prévention d’intrusion peut agir directement à partir de ces observations.

Choisis la détection et son emplacement

Un IDS observe généralement une copie du trafic et émet des alertes. Un IPS est placé sur le trajet et peut rejeter le trafic suspect. Cet emplacement permet un blocage immédiat, mais ajoute un délai de traitement et risque d’interrompre un usage légitime lorsqu’une détection est erronée.

Snort et Suricata sont des exemples de systèmes capables d’utiliser des signatures. Une règle peut reconnaître le chemin de requête ../../etc/passwd, plus de 20 nouvelles connexions au port SSH 22 depuis une source en une minute, ou des SYN vers des centaines de ports. Ces motifs indiquent un comportement suspect ; une correspondance seule ne prouve pas qu’une intrusion a réussi.

Un détecteur d’anomalies peut repérer un grand changement du débit de trafic ou de la répartition entre protocoles. Une nouvelle tâche de sauvegarde légitime peut aussi paraître inhabituelle. Un faux positif est une alerte concernant une activité inoffensive ; un faux négatif est une attaque que le détecteur manque. Modifier un seuil de sensibilité revient généralement à échanger un type d’erreur contre l’autre.

Calcule ce que signifie une alerte

Considérons 1 000 000 de connexions inoffensives et 10 attaques par jour. Un détecteur repère 99 % des attaques et émet une fausse alerte pour 0,1 % des connexions inoffensives.

1. Nombre attendu d’alertes correctes : $10\times \mathrm{0,99}=\mathrm{9,9}$.
2. Nombre attendu de fausses alertes : $1000000\times \mathrm{0,001}=1000$.
3. Proportion attendue d’alertes correctes parmi les alertes : $\mathrm{9,9}\mathrm{/}(\mathrm{9,9}+1000)\approx \mathrm{0,0098}$, soit environ 1 %.

Ce sont des nombres attendus sur plusieurs jours : 9,9 n’a donc pas besoin d’être un résultat quotidien entier. Le taux de détection de 99 % est la proportion d’attaques détectées, pas la probabilité qu’une alerte corresponde à une attaque. La rareté des attaques et le très grand nombre de connexions inoffensives expliquent la différence : c’est le problème du taux de base.

Place les capteurs là où ils peuvent voir

Les capteurs placés juste derrière le pare-feu observent le trafic qui l’a traversé. Les capteurs de la zone démilitarisée observent le trafic des services publics ; les capteurs internes peuvent révéler des attaques qui ne franchissent jamais le périmètre. Un capteur doit pouvoir suivre le trafic qu’il reçoit. Il doit aussi réassembler les fragments et les segments TCP comme le fait la cible ; sinon, une attaque répartie entre plusieurs paquets peut échapper à la recherche d’un motif.

TLS et IPsec masquent les charges utiles chiffrées à un capteur réseau qui n’a pas accès au déchiffrement. Les adresses, les ports, le moment des échanges, les longueurs et les champs de négociation non chiffrés peuvent encore être utiles. L’inspection des charges utiles peut avoir lieu à une extrémité où le déchiffrement est effectué, mais une simple copie du flux chiffré ne fournit pas ce texte en clair.

Un pot de miel est un leurre sans utilisateur ordinaire prévu. Tout contact est donc suspect et peut révéler des techniques de balayage ou d’attaque avec moins de bruit de fond. Des clients mal configurés ou un trafic automatisé inoffensif peuvent toutefois encore le contacter : un leurre ne rend donc pas chaque alerte concluante.