Skip to main content

Protocoles Sécurisés

Introduction​

Lorsque vous naviguez sur le web, envoyez un email, ou accédez à un service en ligne, vos données transitent par de nombreux réseaux et systèmes intermédiaires. Sans protection, ces données pourraient être interceptées, lues ou modifiées par des personnes malveillantes.

C'est là qu'interviennent les protocoles sécurisés. Ces protocoles utilisent des techniques cryptographiques (chiffrement, authentification, intégrité) pour protéger les communications sur les réseaux.

note

Un protocole sécurisé est un ensemble de règles et de procédures qui définissent comment établir une communication sécurisée entre deux parties (par exemple, un navigateur web et un serveur, un client email et un serveur de messagerie, etc.).

Dans cette section, nous allons découvrir les protocoles sécurisés les plus courants :

  • SSL/TLS et HTTPS : Le standard pour la sécurisation des communications web.
  • SSH : Le protocole pour l'accès sécurisé à des machines distantes.
  • IPSec et VPN : Les technologies pour créer des réseaux privés virtuels sécurisés.

Commençons par le duo incontournable SSL/TLS et HTTPS.

SSL/TLS et HTTPS​

SSL (Secure Sockets Layer) et TLS (Transport Layer Security) sont des protocoles cryptographiques qui permettent de sécuriser les échanges de données sur Internet. TLS est le successeur de SSL, et c'est aujourd'hui le terme le plus couramment utilisé (bien que l'on parle encore souvent de "certificats SSL").

HTTPS (HTTP Secure) est la version sécurisée du protocole HTTP (Hypertext Transfer Protocol), le protocole utilisé pour naviguer sur le web. HTTPS utilise SSL/TLS pour chiffrer les communications entre le navigateur web de l'utilisateur et le serveur web.

note

Lorsque vous voyez un cadenas dans la barre d'adresse de votre navigateur et que l'URL commence par https://, cela signifie que la connexion est sécurisée avec SSL/TLS.

Objectifs de SSL/TLS​

  • Confidentialité : Chiffrer les données échangées entre le client et le serveur, pour empêcher qu'elles ne soient lues par des tiers.
  • Intégrité : Garantir que les données n'ont pas été modifiées pendant la transmission.
  • Authentification : Permettre au client de vérifier l'identité du serveur (et, optionnellement, permettre au serveur de vérifier l'identité du client).

Fonctionnement de SSL/TLS (simplifié)​

SSL/TLS utilise une combinaison de cryptographie asymétrique et symétrique (chiffrement hybride) pour établir une connexion sécurisée. Voici les étapes principales, simplifiées :

  1. "Client Hello" : Le client (par exemple, un navigateur web) envoie un message "Client Hello" au serveur. Ce message contient :

    • Les versions de SSL/TLS supportées par le client.
    • Les suites cryptographiques supportées par le client (c'est-à-dire les combinaisons d'algorithmes de chiffrement, de hachage, etc., que le client sait utiliser).
    • Un nombre aléatoire ("Client Random").

  2. "Server Hello" : Le serveur répond avec un message "Server Hello", qui contient :

    • La version de SSL/TLS choisie.
    • La suite cryptographique choisie.
    • Un nombre aléatoire ("Server Random").
    • Le certificat numérique du serveur (contenant sa clé publique).

  3. Vérification du certificat : Le client vérifie la validité du certificat du serveur :

    • Est-ce que le certificat a été signé par une autorité de certification (AC) de confiance ?
    • Est-ce que le certificat est encore valide (date d'expiration) ?
    • Est-ce que le nom de domaine dans le certificat correspond au nom de domaine du site web auquel le client se connecte ?

  4. Échange de clés (clé de session) :

    • Il existe différentes méthodes, mais le principe général est le suivant:
    • Avec RSA :
      • Le client génère un "pre-master secret" (un nombre aléatoire).
      • Le client chiffre le pre-master secret avec la clé publique du serveur (extraite du certificat).
      • Le client envoie le pre-master secret chiffré au serveur.
      • Le serveur déchiffre le pre-master secret avec sa clé privée.
    • Avec Diffie-Hellman (ou ECDH) :
      • Le client et le serveur utilisent le protocole Diffie-Hellman (ou sa variante sur les courbes elliptiques) pour se mettre d'accord sur un secret partagé sans jamais l'échanger directement.

  5. Dérivation des clés de session :

    • Le client et le serveur utilisent le pre-master secret (ou le secret partagé, dans le cas de Diffie-Hellman), le "Client Random" et le "Server Random" pour dériver les clés de session (des clés symétriques qui seront utilisées pour chiffrer les données). On utilise une fonction de dérivation de clé (KDF) pour cela.

  6. "Change Cipher Spec" et "Finished" :

    • Le client et le serveur s'envoient des messages "Change Cipher Spec" pour indiquer qu'ils vont commencer à utiliser les clés de session.
    • Ils s'envoient également des messages "Finished" (chiffrés et authentifiés avec les clés de session) pour vérifier que tout s'est bien passé.

  7. Communication chiffrée :

    • À partir de ce moment, toutes les données échangées entre le client et le serveur sont chiffrées et authentifiées avec les clés de session (en utilisant un algorithme de chiffrement symétrique, comme AES, et un code d'authentification de message, comme HMAC).

Schéma (très simplifié)​

Suites cryptographiques​

Une suite cryptographique (cipher suite) est une combinaison d'algorithmes utilisés pour une connexion SSL/TLS :

  • Algorithme d'échange de clés : RSA, Diffie-Hellman (DH), Elliptic Curve Diffie-Hellman (ECDH), etc.
  • Algorithme de chiffrement symétrique : AES, ChaCha20, 3DES (obsolète), etc.
  • Fonction de hachage (pour l'intégrité et l'authentification) : SHA-256, SHA-384, etc.
  • Code d'authentification de message (MAC) : HMAC-SHA256, etc. (ou un mode de chiffrement authentifié comme GCM, qui combine chiffrement et authentification).

Exemple de suite cryptographique : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS : Indique le protocole (TLS).
  • ECDHE : Indique l'utilisation d'Elliptic Curve Diffie-Hellman Ephemeral pour l'échange de clés.
  • RSA : Indique que la clé publique du serveur est une clé RSA (utilisée pour authentifier le serveur).
  • AES_128_GCM : Indique l'utilisation d'AES avec une clé de 128 bits et le mode GCM (Galois/Counter Mode) pour le chiffrement symétrique (et l'authentification).
  • SHA256 : Indique l'utilisation de SHA-256 comme fonction de hachage.

Évolution de SSL/TLS​

  • SSL 1.0, 2.0, 3.0 : Obsolètes et non sécurisés. Ne doivent plus être utilisés.
  • TLS 1.0, 1.1 : Dépréciés. De nombreuses failles de sécurité ont été découvertes. Il est recommandé de ne plus les utiliser.
  • TLS 1.2 : La version la plus couramment utilisée aujourd'hui. Considérée comme sûre si elle est correctement configurée (utilisation de suites cryptographiques fortes).
  • TLS 1.3 : La dernière version de TLS (2018). Elle apporte des améliorations en termes de sécurité et de performance :
    • Suppression des suites cryptographiques obsolètes ou faibles.
    • Chiffrement plus précoce dans le handshake (la négociation initiale).
    • Handshake plus rapide (moins d'allers-retours entre le client et le serveur).
    • Meilleure protection de la vie privée (chiffrement de certaines informations qui étaient auparavant transmises en clair, comme le nom du serveur).
tip

Il est fortement recommandé d'utiliser TLS 1.2 (avec une configuration sécurisée) ou, mieux encore, TLS 1.3.

Outils pour tester la configuration SSL/TLS d'un serveur​

  • SSL Labs (Qualys) : https://www.ssllabs.com/ssltest/
    • Un outil en ligne gratuit et très complet pour analyser la configuration SSL/TLS d'un site web. Il donne une note (de A+ à F) et des informations détaillées sur les certificats, les protocoles supportés, les suites cryptographiques, les vulnérabilités connues, etc.
  • testssl.sh : Un outil en ligne de commande (disponible sur Linux, macOS, et avec WSL sous Windows) pour tester la configuration SSL/TLS d'un serveur.
./testssl.sh https://www.example.com/

Vulnérabilité de Diffie-Hellman à l'attaque de l'homme du milieu (et comment TLS la contourne)​

L'échange de clés Diffie-Hellman, tel que décrit précédemment, est vulnérable à une attaque de l'homme du milieu (MitM) s'il n'y a pas d'authentification des parties.

Attaque MitM sur Diffie-Hellman (sans authentification) :

  1. Mallory (l'attaquant) se place entre Alice (le client) et Bob (le serveur).
  2. Alice envoie sa valeur publique Diffie-Hellman (A) à Bob. Mallory intercepte A et envoie sa propre valeur publique M à Bob.
  3. Bob reçoit M (pensant que c'est A) et envoie sa valeur publique B à Alice. Mallory intercepte B et envoie sa propre valeur publique M' à Alice.
  4. Alice et Mallory calculent un secret partagé s1.
  5. Bob et Mallory calculent un secret partagé s2.
  6. Alice et Bob croient communiquer de manière sécurisée, mais en réalité, Mallory peut déchiffrer, lire et modifier tous les messages échangés.

Comment TLS contourne cette vulnérabilité :

TLS utilise des certificats numériques et des signatures numériques pour authentifier le serveur (et, optionnellement, le client).

  1. Certificat du serveur : Le serveur possède un certificat numérique, délivré par une autorité de certification (AC) de confiance. Ce certificat contient :

    • La clé publique du serveur.
    • L'identité du serveur (nom de domaine, etc.).
    • La signature numérique de l'AC (qui garantit l'authenticité du certificat).

  2. Signature de la clé publique Diffie-Hellman (dans le cas d'un échange de clés Diffie-Hellman) :

  • Si Diffie-Hellman est utilisé directement pour l'échange de clés, la valeur publique Diffie-Hellman envoyée par le serveur (B dans l'exemple ci-dessus) n'est pas envoyée telle quelle. Elle est signée numériquement par le serveur, avec sa clé privée.
    • Le serveur calcule un haché de sa valeur publique Diffie-Hellman (et d'autres paramètres de la négociation).
    • Le serveur chiffre ce haché avec sa clé privée (celle qui correspond à la clé publique présente dans son certificat).
    • Le serveur envoie sa valeur publique Diffie-Hellman et la signature au client.
  • Le client, après avoir vérifié le certificat du serveur (et donc validé sa clé publique), peut :
    • Déchiffrer la signature avec la clé publique du serveur (extraite du certificat).
    • Calculer le haché de la valeur publique Diffie-Hellman reçue.
    • Comparer les deux hachés. Si les hachés correspondent, le client a la garantie que la valeur publique Diffie-Hellman provient bien du serveur légitime (et non d'un attaquant MitM).
  1. Authentification Mutuel TLS peut également prendre en charge l'authentification mutuelle, où le serveur demande au client de présenter son propre certificat, offrant ainsi une couche de sécurité supplémentaire.

En résumé :

  • Diffie-Hellman seul est vulnérable à l'attaque MitM.
  • TLS utilise le certificat numérique du serveur (et sa clé publique) pour authentifier les paramètres de l'échange de clés Diffie-Hellman (ou pour chiffrer un secret partagé dans le cas d'un échange de clé RSA).
  • Cette authentification empêche l'attaque MitM, car l'attaquant ne peut pas falsifier la signature du serveur (s'il ne possède pas la clé privée du serveur).
tip

L'utilisation de certificats numériques et de signatures numériques est essentielle pour sécuriser les protocoles comme TLS et SSH. Sans authentification, ces protocoles seraient vulnérables à l'attaque de l'homme du milieu.

SSH (Secure Shell)​

SSH (Secure Shell) est un protocole réseau qui permet d'établir une connexion sécurisée entre un client et un serveur, généralement pour accéder à un shell (interpréteur de commandes) distant, mais aussi pour transférer des fichiers ou exécuter des commandes à distance.

note

SSH est l'un des protocoles les plus utilisés pour l'administration à distance de serveurs, le transfert sécurisé de fichiers, et la création de tunnels sécurisés. Il remplace avantageusement les anciens protocoles non sécurisés comme Telnet et FTP.

Objectifs de SSH​

  • Confidentialité : Chiffrer les données échangées entre le client et le serveur, pour empêcher qu'elles ne soient lues par des tiers.
  • Intégrité : Garantir que les données n'ont pas été modifiées pendant la transmission.
  • Authentification : Permettre au client de vérifier l'identité du serveur, et au serveur de vérifier l'identité du client.

Fonctionnement de SSH (simplifié)​

Comme SSL/TLS, SSH utilise une combinaison de cryptographie asymétrique et symétrique pour établir une connexion sécurisée. Voici les étapes principales :

  1. Connexion TCP : Le client SSH établit une connexion TCP avec le serveur SSH (généralement sur le port 22).

  2. Négociation de version et d'algorithmes :

    • Le client et le serveur s'échangent des informations sur les versions de SSH qu'ils supportent.
    • Ils négocient les algorithmes cryptographiques à utiliser (algorithmes d'échange de clés, de chiffrement symétrique, de hachage, etc.).

  3. Échange de clés (Key Exchange) :

    • Le client et le serveur utilisent un algorithme d'échange de clés (généralement Diffie-Hellman ou une variante sur les courbes elliptiques, ECDH) pour se mettre d'accord sur une clé secrète partagée, sans jamais échanger cette clé directement.

  4. Authentification du serveur :

    • Le serveur SSH possède une clé publique et une clé privée.
    • Le serveur envoie sa clé publique au client.
    • Le client vérifie si cette clé publique est connue (par exemple, si elle est présente dans le fichier ~/.ssh/known_hosts du client).
      • Si la clé est connue et correspond à celle attendue, l'authentification du serveur est réussie.
      • Si la clé n'est pas connue (première connexion) ou si elle ne correspond pas, le client affiche généralement un avertissement et demande à l'utilisateur s'il veut accepter la clé (attention au risque d'attaque de l'homme du milieu !).

  5. Authentification du client :

    • Le serveur peut authentifier le client de différentes manières :
      • Par mot de passe : Le serveur demande le mot de passe de l'utilisateur (le mot de passe est chiffré avant d'être transmis). C'est la méthode la moins sûre.
      • Par clé publique : Le client prouve qu'il possède la clé privée correspondant à une clé publique préalablement autorisée par le serveur (stockée dans le fichier ~/.ssh/authorized_keys sur le serveur). C'est la méthode recommandée.
      • Par GSSAPI (Generic Security Services Application Program Interface) : Permet d'utiliser des mécanismes d'authentification comme Kerberos.

  6. Établissement des canaux chiffrés :

    • Une fois l'authentification réussie, le client et le serveur utilisent la clé secrète partagée (issue de l'échange de clés) pour chiffrer et authentifier toutes les communications ultérieures.

  7. Session interactive (ou exécution de commandes, transfert de fichiers, etc.) :

    • Le client peut maintenant ouvrir un shell distant, exécuter des commandes, transférer des fichiers, etc., de manière sécurisée.
Schéma (très simplifié)

Authentification par clé publique (recommandé)​

L'authentification par clé publique est la méthode la plus sûre pour se connecter à un serveur SSH. Voici comment elle fonctionne :

  1. Génération de la paire de clés (côté client) :

    • L'utilisateur génère une paire de clés SSH (clé publique et clé privée) sur son ordinateur, en utilisant la commande ssh-keygen (sous Linux/macOS/WSL) ou un outil comme PuTTYgen (sous Windows).
    • Il est recommandé d'utiliser l'algorithme Ed25519 (plus récent et plus sûr) ou, à défaut, RSA avec une clé d'au moins 2048 bits (4096 bits est préférable).
    • L'utilisateur peut (et devrait) protéger sa clé privée avec un mot de passe (passphrase).

  2. Copie de la clé publique sur le serveur :

    • L'utilisateur copie sa clé publique (pas sa clé privée !) sur le serveur SSH, dans le fichier ~/.ssh/authorized_keys du compte utilisateur auquel il souhaite se connecter.

  3. Connexion SSH :

    • Lorsque l'utilisateur se connecte au serveur SSH, le serveur vérifie si la clé publique du client est présente dans le fichier authorized_keys.
    • Si c'est le cas, le serveur envoie un défi au client (un nombre aléatoire chiffré avec la clé publique du client).
    • Le client déchiffre le défi avec sa clé privée et renvoie le résultat au serveur.
    • Si le résultat est correct, le serveur authentifie le client et ouvre la session.

Procédure détaillée :​

1. Génération de la paire de clés (côté client)​

Vous allez générer une paire de clés SSH sur votre propre ordinateur (le client) : une clé privée (que vous garderez secrète) et une clé publique (que vous copierez sur le serveur).

  • Sous Linux/macOS/WSL (Windows Subsystem for Linux) :

    1. Ouvrez un terminal.
    2. Tapez la commande suivante : 
      ssh-keygen -t ed25519 -C "votre_commentaire"
      • -t ed25519 : Spécifie l'algorithme de clé à utiliser. Ed25519 est recommandé pour sa sécurité et sa rapidité. Si vous ne pouvez pas utiliser Ed25519, utilisez RSA avec une taille de clé d'au moins 4096 bits (-t rsa -b 4096).
      • -C "votre_commentaire" : Ajoute un commentaire à la clé (facultatif, mais utile pour identifier la clé). Vous pouvez mettre votre adresse email, par exemple.
    3. L'utilitaire vous demandera où enregistrer les clés. Appuyez sur Entrée pour accepter l'emplacement par défaut (~/.ssh/id_ed25519 pour la clé privée et ~/.ssh/id_ed25519.pub pour la clé publique).
    4. L'utilitaire vous demandera un mot de passe (passphrase) pour protéger votre clé privée. Il est fortement recommandé de choisir un mot de passe fort. Ce mot de passe vous sera demandé à chaque fois que vous utiliserez la clé privée.
    5. ssh-keygen génère les deux fichiers : la clé privée (id_ed25519) et la clé publique (id_ed25519.pub).

  • Sous Windows (avec PuTTYgen) :

    1. Téléchargez et installez PuTTYgen (il fait partie de la suite PuTTY).
    2. Ouvrez PuTTYgen.
    3. Choisissez le type de clé : "Ed25519" (ou "RSA" si Ed25519 n'est pas disponible, et dans ce cas, choisissez une taille de clé d'au moins 4096 bits).
    4. Cliquez sur "Generate".
    5. Bougez la souris de manière aléatoire dans la fenêtre de PuTTYgen pour générer de l'entropie (nécessaire pour la création de clés sécurisées).
    6. (Optionnel, mais recommandé) Entrez un mot de passe fort dans les champs "Key passphrase" et "Confirm passphrase".
    7. Cliquez sur "Save private key" pour enregistrer votre clé privée (par exemple, id_ed25519.ppk). Gardez ce fichier précieusement et ne le partagez avec personne !
    8. Copiez le contenu de la zone de texte "Public key for pasting into OpenSSH authorized_keys file" (c'est votre clé publique au format OpenSSH).
2. Copie de la clé publique sur le serveur​

Vous allez maintenant copier votre clé publique (et uniquement la clé publique !) sur le serveur SSH, dans le fichier ~/.ssh/authorized_keys du compte utilisateur auquel vous souhaitez vous connecter.

  • Méthode automatique (recommandée, si ssh-copy-id est disponible) :

    Sous Linux/macOS/WSL, vous pouvez utiliser la commande ssh-copy-id :

    ssh-copy-id user@serveur.com

    (Remplacez user par votre nom d'utilisateur sur le serveur et serveur.com par l'adresse du serveur.)

    Cette commande copie automatiquement votre clé publique dans le fichier ~/.ssh/authorized_keys du serveur, en créant le répertoire et le fichier si nécessaire, et en définissant les bonnes permissions.

  • Méthode manuelle :

    1. Copiez votre clé publique :

      • Sous Linux/macOS/WSL : 
        cat ~/.ssh/id_ed25519.pub
        Copiez la sortie de cette commande (qui commence par ssh-ed25519 ou ssh-rsa).
      • Sous Windows (avec PuTTYgen) :
        • Ouvrez PuTTYgen.
        • Cliquez sur "Load".
        • Sélectionnez votre fichier de clé privée (.ppk).
        • Entrez votre mot de passe si nécessaire.
        • Copiez le contenu de la zone de texte "Public key for pasting into OpenSSH authorized_keys file".

    2. Connectez-vous au serveur (avec votre mot de passe, pour la dernière fois !) :

      ssh user@serveur.com

    3. Créez le répertoire .ssh (si nécessaire) :

      mkdir -p ~/.ssh

    4. Créez le fichier authorized_keys (si nécessaire) et ajoutez-y votre clé publique :

      • Vous pouvez utiliser un éditeur de texte comme nano ou vim : 
        nano ~/.ssh/authorized_keys
        Collez votre clé publique dans l'éditeur, enregistrez le fichier et quittez.
      • Ou, en une seule ligne (attention à ne pas écraser le contenu existant du fichier !) : 
        echo "votre_clé_publique" >> ~/.ssh/authorized_keys
        (Remplacez "votre_clé_publique" par votre clé publique, en faisant attention à ce qu'elle soit sur une seule ligne.)

    5. Définissez les bonnes permissions :

      chmod 700 ~/.ssh
      chmod 600 ~/.ssh/authorized_keys
3. Connexion SSH (avec la clé)​

Maintenant que votre clé publique est sur le serveur, vous pouvez vous connecter sans mot de passe (ou plutôt, en utilisant le mot de passe de votre clé privée, si vous en avez défini un) :

ssh user@serveur.com

Si vous avez configuré un mot de passe pour votre clé privée, il vous sera demandé. Sinon, la connexion s'établira directement.

warning
  • Ne partagez jamais votre clé privée ! Gardez-la précieusement et en sécurité sur votre ordinateur.
  • Si vous perdez votre clé privée, ou si elle est compromise, supprimez immédiatement la clé publique correspondante du fichier authorized_keys sur tous les serveurs où vous l'avez copiée.
  • Si vous utilisez un mot de passe pour votre clé privée, choisissez un mot de passe fort et différent de vos autres mots de passe.

Utilisations courantes de SSH​

  • Accès à un shell distant :

    ssh user@serveur.com

  • Exécution d'une commande à distance :

    ssh user@serveur.com "ls -l /tmp"

  • Transfert de fichiers sécurisé (SCP) :

    scp fichier_local user@serveur.com:/chemin/distant/
    scp user@serveur.com:/chemin/distant/fichier_distant fichier_local

  • Transfert de fichiers sécurisé (SFTP) :

    • SFTP (SSH File Transfer Protocol) est un protocole de transfert de fichiers sécurisé qui fonctionne sur SSH. Il remplace avantageusement FTP (qui n'est pas sécurisé).
    • De nombreux clients graphiques supportent SFTP (FileZilla, WinSCP, Cyberduck, etc.).

  • Tunneling (port forwarding) :

    • SSH permet de créer des tunnels sécurisés pour faire passer d'autres protocoles à travers une connexion SSH chiffrée.
    • Exemple : Rediriger le port local 8080 vers le port 80 du serveur distant : 
      ssh -L 8080:localhost:80 user@serveur.com

  • SOCKS proxy :

    • SSH peut être utilisé comme un proxy SOCKS, permettant de faire passer tout le trafic réseau à travers une connexion SSH chiffrée.

Bonnes pratiques pour la sécurité SSH​

  • Utiliser l'authentification par clé publique plutôt que par mot de passe.
  • Désactiver l'authentification par mot de passe sur le serveur (si possible).
  • Utiliser des clés SSH avec un algorithme et une taille de clé robustes (Ed25519 ou RSA 4096 bits).
  • Protéger la clé privée avec un mot de passe fort.
  • Changer le port SSH par défaut (22) pour un autre port (moins ciblé par les scans automatisés).
  • Restreindre l'accès SSH à certains utilisateurs ou à certaines adresses IP (avec le fichier de configuration sshd_config ou avec un pare-feu).
  • Utiliser un outil comme Fail2ban pour bloquer automatiquement les adresses IP qui tentent de se connecter avec des mots de passe erronés de manière répétée.
  • Mettre à jour régulièrement le logiciel SSH (client et serveur).
tip

SSH est un outil puissant et flexible pour l'administration à distance et le transfert sécurisé de données. Il est essentiel de bien le configurer et de suivre les bonnes pratiques de sécurité pour protéger vos systèmes.

IPSec et VPN​

IPSec (Internet Protocol Security) et VPN (Virtual Private Network) sont des technologies étroitement liées qui permettent de créer des connexions sécurisées sur des réseaux non sécurisés (comme Internet).

IPSec​

IPSec est un ensemble de protocoles qui permettent de sécuriser les communications au niveau de la couche réseau (couche 3 du modèle OSI). Il fournit :

  • Confidentialité : Chiffrement des données.
  • Intégrité : Protection contre la modification des données.
  • Authentification : Vérification de l'origine des données.
  • Protection contre le rejeu : Protection contre la réutilisation de paquets capturés.
note

Contrairement à SSL/TLS qui sécurise les communications au niveau de la couche application (pour des applications spécifiques comme le web ou l'email), IPSec sécurise les communications au niveau de la couche réseau. Cela signifie qu'il peut protéger tout le trafic IP, quel que soit le protocole de couche supérieure (TCP, UDP, etc.).

Modes de fonctionnement d'IPSec :

  • Mode transport : Seule la charge utile (payload) du paquet IP est chiffrée et/ou authentifiée. L'en-tête IP original est conservé. Ce mode est utilisé pour les communications de bout en bout entre deux hôtes.

    [En-tête IP original] | [Charge utile chiffrée/authentifiée]

  • Mode tunnel : Le paquet IP original (en-tête + charge utile) est encapsulé dans un nouveau paquet IP, avec un en-tête IPSec. Ce mode est utilisé pour créer des VPN (voir plus loin).

    [Nouvel en-tête IP] | [En-tête IPSec] | [En-tête IP original] | [Charge utile originale]

VPN (Virtual Private Network)​

Un VPN est un réseau privé virtuel qui permet de créer une connexion sécurisée (un "tunnel") sur un réseau non sécurisé (comme Internet).

info

Imaginez un tunnel qui passe sous une autoroute très fréquentée. Le tunnel, c'est le VPN. L'autoroute, c'est Internet. Les voitures qui passent dans le tunnel sont vos données, protégées des regards indiscrets.

Types de VPN :

  • VPN d'accès distant (Remote Access VPN) : Permet à un utilisateur distant (par exemple, un employé en télétravail) de se connecter de manière sécurisée au réseau privé d'une entreprise.
  • VPN site à site (Site-to-Site VPN) : Permet de connecter de manière sécurisée deux réseaux privés (par exemple, le réseau du siège social d'une entreprise et le réseau d'une filiale).

VPN et IPSec :

IPSec est souvent utilisé pour implémenter des VPN, en particulier des VPN site à site. Le mode tunnel d'IPSec est particulièrement adapté à la création de VPN.

Autres technologies VPN :

  • SSL/TLS VPN : Des VPN qui utilisent SSL/TLS (au lieu d'IPSec) pour sécuriser les communications. OpenVPN est un exemple populaire de VPN SSL/TLS.
  • WireGuard : Un protocole VPN moderne, conçu pour être plus simple, plus rapide et plus sûr qu'IPSec ou OpenVPN.

Avantages des VPN :

  • Sécurité : Les VPN chiffrent les données et protègent contre l'écoute et la modification des communications.
  • Confidentialité : Les VPN masquent l'adresse IP de l'utilisateur et peuvent permettre de contourner la censure ou les restrictions géographiques.
  • Accès à distance : Les VPN permettent aux utilisateurs d'accéder aux ressources d'un réseau privé (fichiers, applications, etc.) comme s'ils y étaient physiquement connectés.

Inconvénients des VPN :

  • Performance : Le chiffrement et le tunneling peuvent ralentir la connexion.
  • Complexité : La configuration d'un VPN (en particulier avec IPSec) peut être complexe.
  • Confiance envers le fournisseur VPN : Si vous utilisez un service VPN commercial, vous devez faire confiance à ce fournisseur pour ne pas espionner vos données.
  • Mauvaise configuration
  • Faux sentiment de sécurité
tip

IPSec et les VPN sont des outils puissants pour sécuriser les communications sur les réseaux. Ils sont largement utilisés dans les entreprises, mais aussi par les particuliers pour protéger leur vie privée en ligne.

Testez vos connaissances !​

Qu'est-ce qu'un protocole sécurisé ?
Quels protocoles sont couramment utilisés pour sécuriser les communications sur le web ?
Quels sont les objectifs de SSL/TLS ? (Plusieurs réponses possibles)
Comment SSL/TLS établit-il une connexion sécurisée ?
Qu'est ce qu'une suite cryptographique ?
Quelle version de TLS est recommandée aujourd'hui ?
Vrai ou faux: L'échange de clé Diffie-Hellman utilisé seul est vulnérable à une attaque de l'homme du milieu
Comment TLS contre l'attaque de l'homme du milieu ?
Qu'est-ce que SSH (Secure Shell) ?
Quels sont les objectifs de SSH ? (Plusieurs réponses possibles)
Quelle est la méthode d'authentification la plus sûre pour SSH ?
Qu'est-ce qu'IPSec ?
Qu'est-ce qu'un VPN (Virtual Private Network) ?
Quel protocole est souvent utilisé pour implémenter des VPN ?
Quels sont les avantages des VPN ? (Plusieurs réponses possibles)