diff --git a/content/secu_reseaux/5_securite-echanges/images/ipsec_transport.svg b/content/secu_reseaux/5_securite-echanges/images/ipsec_transport.svg index 6a75e14..c243fe9 100644 --- a/content/secu_reseaux/5_securite-echanges/images/ipsec_transport.svg +++ b/content/secu_reseaux/5_securite-echanges/images/ipsec_transport.svg @@ -2,37 +2,44 @@ propagation de Mirail + id="title3115">IPSec AH en mode transport + - - - - + id="defs154" /> @@ -50,7 +57,7 @@ - propagation de Mirail + IPSec AH en mode transport @@ -77,9 +84,10 @@ x="-7" y="-7" /> + style="fill:none;fill-opacity:0.996078;stroke:#874ee0;stroke-width:0.460351px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:" + d="M 18.005652,1.4155964 C 18.257675,8.972584 4.6315672,11.50971 4.6315672,16.725634" + id="path7829" + sodipodi:nodetypes="cc" /> @@ -105,9 +113,10 @@ + style="fill:none;fill-opacity:0.996078;stroke:#874ee0;stroke-width:0.460351px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:" + d="M 35.415183,2.4476782 C 35.16316,10.004666 48.646768,12.332314 48.646768,17.548238" + id="path9050" + sodipodi:nodetypes="cc" /> @@ -137,9 +146,10 @@ + style="fill:none;fill-opacity:0.996078;stroke:#874ee0;stroke-width:0.460351px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:" + d="M 59.663798,2.4476782 C 59.411775,10.004666 73.579557,12.280619 73.579557,17.496543" + id="path9072" + sodipodi:nodetypes="cc" /> @@ -153,21 +163,25 @@ + d="M 58.624997,17.870721 H 28.305677 V 9.3289804 h 30.31932" + sodipodi:nodetypes="cccc" /> + d="m 70.887804,17.87072 h 4.539648 V 9.3289804 h -4.539648" + sodipodi:nodetypes="cccc" /> + d="M 70.530266,17.870721 H 58.624997 m 0,-8.5417406 h 11.905269" + sodipodi:nodetypes="cccc" /> + d="M 58.624997,17.870721 H 28.305677 V 9.3289804 h 30.31932" + sodipodi:nodetypes="cccc" /> + d="m 70.887804,17.87072 h 4.539648 V 9.3289804 h -4.539648" + sodipodi:nodetypes="cccc" /> + d="M 70.530266,17.870721 H 58.624997 m 0,-8.5417406 h 11.905269" + sodipodi:nodetypes="cccc" /> + style="fill:#69ebba;fill-opacity:1;stroke:#41e6a8;stroke-width:0.460351;stroke-opacity:1" /> + + + + IPsec ESP en mode tunnel + + + + + + + + Yorick Barbanneau ^ ephase + + + + + CC BY-SA + + + + IPsec ESP en mode tunnel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + payload + + + ESP + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/secu_reseaux/5_securite-echanges/images/ipsec_tunnel.svg b/content/secu_reseaux/5_securite-echanges/images/ipsec_tunnel.svg index e2a1d83..33b2758 100644 --- a/content/secu_reseaux/5_securite-echanges/images/ipsec_tunnel.svg +++ b/content/secu_reseaux/5_securite-echanges/images/ipsec_tunnel.svg @@ -2,18 +2,42 @@ propagation de Mirail + id="title3330">IPSec AH en mode tunnel + - propagation de Mirail + IPSec AH en mode tunnel diff --git a/content/secu_reseaux/5_securite-echanges/images/ipsec_tunnel_esp.svg b/content/secu_reseaux/5_securite-echanges/images/ipsec_tunnel_esp.svg new file mode 100644 index 0000000..c8c1ac8 --- /dev/null +++ b/content/secu_reseaux/5_securite-echanges/images/ipsec_tunnel_esp.svg @@ -0,0 +1,506 @@ + + + + + IPsec ESP en mode tunnel + + + + + + + + Yorick Barbanneau ^ ephase + + + + + CC BY-SA + + + + IPsec ESP en mode tunnel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + payload + + + + ESP + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/secu_reseaux/5_securite-echanges/index.md b/content/secu_reseaux/5_securite-echanges/index.md index 10f30e5..fbc9a7e 100644 --- a/content/secu_reseaux/5_securite-echanges/index.md +++ b/content/secu_reseaux/5_securite-echanges/index.md @@ -3,20 +3,21 @@ title: "Sécurité des réseaux : sécurité des échanges" date: 2022-10-04 tags: ["TLS", "IPSEC"] categories: ["Sécurité des réseaux", "Cours"] +mathjax: true --- Dans cette partie nous aborderons *TLS* (*Transport Layer Security*), *IPSec* (*IP Security*) et les *PKI* (*Public Key Infrastructure*) -## Propriétéà assurer +## Propriété à assurer Pour sécuriser un échange, il faut assurer 4 points: 1. la confidentialité: seul mon interlocuteur peut lire le message; 2. l'authenticité: le message est authentique; 3. l'intégrité: le message vient bien de mon interlocuteur, il n'a pas été - modifié par un tiers; - 4. la non-répudiabilité: mon interlocuteur ne peut pas réfuter ses messages; + modifié par un tiers; + 4. la non répudiabilité: mon interlocuteur ne peut pas réfuter ses messages; ## IPSec @@ -56,22 +57,22 @@ Le déroulé: * Si la *MAC* est invalide ou que le numéro d'ordre est à gauche de la fenêtre, **il est détruit**; -### Les modes d'utilisation +### Authentication Header -Il existe deux modes de fonctionnement : le mode tunnel et le mode transport. +L'entête d'authentification assure l'intégrité des données et authentifie +les paquets IP. Elle est basée sur MAC (*Message Authentication Code*) +([Wikipedia](https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message)). -#### Le mode tunnel +L'entête permet aussi la détection du rejeu (cf chapitre au dessus) -Deux réseaux se "parlent" via l'établissement d'un tunnel sécurisé. +### Encapsulated Security Payload -![Encapsulation de la trame IP en mode tunnel](./images/ipsec_tunnel.svg) +Ce protocole assure la confidentialité des échange, l'authentification et +l'intégrité des messages. En opposition avec le protocole *AH*, *ESP* chiffre +les données et les encapsules et y ajoute su besoin du bourrage (*padding*) +(voir schémas ci-dessous) -Ce mode assure la protection du paquet IP dans sa totalité. - - -En mode ESP, le message doit être **chiffré**. - -#### Le mode transport +### Le mode transport Deux hôtes se "parlent" via un tunnel sécurisé. Dans ce mode, le paquet d'origine est inclus dans un autre. Le paquet d'origine est alors chiffré et / @@ -82,15 +83,177 @@ ou authentifié. Un champ AH est ajouté pour authentifier la trame. Cette authentification est assurée par une signature qui prend la forme: -``` +\\[ hash(K || hash(K || M)) -``` +\\] -Ou `hash` est une foncion de hashage, `K` la clé. +Ou `hash` est une fonction de hashage, `K` la clé et `M` le message. -En mode transport, **ESP** chiffre l'information utile du paquet, l'entête reste -inchangée. **AH** authentifie l'information utile et certaines parties de -l'entête IP. +En mode transport, **ESP** chiffre la charge utile du paquet d'origine, l'entête +reste inchangée. *ESP* authentifie l'information utile et certaines parties de +l'entête IP comme montré sur le schéma ci-dessous: -Pour passer au travers d'un *NAT*, il est nécessaire d'encapsuler le tout dans -une trame UDP. +![Utilisation d'ESP en mode transport](./images/ipsec_transport_esp.svg) + +Lors de l'utilisation du mode transport, il n'est pas possible de faire du *NAT* +sans compromettre l'intégrité du paquet. Il est tout de même possible de faire +du [NAT-Traversal](https://fr.wikipedia.org/wiki/NAT-T) qui en capsule les +paquets IPsec dans des paquets *UDP* + +### Le mode tunnel + +Deux réseaux se "parlent" via l'établissement d'un tunnel sécurisé. + +![Encapsulation de la trame IP en mode tunnel](./images/ipsec_tunnel.svg) + +Ce mode assure la protection du paquet IP dans sa totalité. + +En mode ESP, le message doit être **chiffré**. + +![Utilisation d'ESP en mode transport](./images/ipsec_tunnel_esp.svg) + +Le mode *ESP* supporte le *NAT*. + +### IKE -- Gestion des clés + +IKE sert à gérer et distribuer les clés, il est aussi chargé de négocier la +connexion. 4 clés sont nécessaire pour sécuriser le tunnel: une paire pour la +transmission et une autre pour le réception. + +Deux type d'authentification sont possible : + + * *Pre-Shared Key* ou *PSK*, en somme un secret partagé + * à l'aide de certificats, dans ce cas l'utilisation d'une autorité de + certification assure la **non répudiation** des messages envoyés + +IPsec propose deux mode de gestion des clés: manuelle -- chaque poste est +configuré manuellement -- ou automatique via *Internet Security Association and +Key Management* (ISAKPM). + +**ISAKPM** fournit un cadre pour la création et la gestion des clés, pour +authentifier les communications et la gestion des *Security Associations*. Il +utilise *IKE* pour l'échange de clés. + +### Diffie-Hellman + +#### Principe de fonctionnement + +Alice et Bob choisissent un nombre premier \\(q\\) et une racine primaire de +\\(q\\) notée \\(a\\). Ils tirent chacun un nombre aléatoire, respectivement +\\(X_{A}\\) et \\(X_{B}\\), ces nombres correspondent aux **clés privées** de +nos deux protagonistes. + + 1. Alice transmet \\(Y_{A}\\) qui vaut \\(a^{X_{A}}mod(q) \\) + 2. Bob transmet \\(Y_{B}\\) qui vaut \\(a^{Y_{B}}mod(q) \\) + 3. Chacun des protagoniste calcule la clé de session : + \\(K = (Y_{B})^{X_{A}}mod(q) = \(Y_{A})^{X_{B}}mod(q) = a^{X_{A}X_{B}}mod(q)\\) + +#### Faiblesses + +Cette algorithme permet d'assurer la *Perfect Forward Secrecy* : la +compromission de la clé n'entraine pas la compromission des échanges passés. +Mais DH est sensible aux **attaque par l'homme du milieu (MitM)**. + +Il est alors nécessaire de signer les messages \\(Y_{A}\\) et \\(Y_{B}\\). Alice +et Bob ont alors besoin **d'échanger des informations avant leurs échanges**. + +De plus la réception des premiers message est coûteuse en temps de calcul: +**risque de déni de service**. + +### Oakley + +Il intervient à plusieurs endroits pour sécuriser les échanges: + + * Utilisation des cookies pour éviter les attaques par déni de service; + * Négociation d'un groupe de paramètres pour DH; + * Authentification des échanges de clés DH; + * Utilisation de **nonce** pour contrer les attaques par rejeu. + +Un nonce est un nombre aléatoire (ou pseudo aléatoire) à usage unique utilisé +dans une communication afin de garantir qu'un ancien message ne puisse pas être +réutilisé. + +### ISAKMP + +C'est le plus populaire des IKE: + + * il négocie d'abords les associations de sécurité (*SA*) + * Il utilise le protocole d'*Oackley* + * Il nécessite deux phases : la première pour créer un canal sécurisé + permettant à la phase deux d'échanger les véritables paramètre de sécurité + +## SSL / TLS + +Ici aussi il est question de respecter les 4 paramètres vu en introduction. Dans +TLS pour *Transport Layer Security*, il est toujours question de Client / +Serveur. + +Avec la version 1.3 de *TLS*, il y a rupture dans la rétro-compatibilité afin de +se débarrasser des éléments problématiques. + +### Poignée de main + +#### Version simplifiée (RSA) + + 1. Le client envoi un `hello` en clair. Ce message comprend: + * la version du protocole qu'il souhaite utiliser + * les suite de chiffrement prise en charge + * un *client random*, courte chaine de donnée aléatoire + 2. Le serveur répond en clair : + * son certificat x509 + * ses suites de chiffrement préférées + * un *serveur random*, courte chaine de donnée aléatoire + 3. Le client créé un autre ensemble de données aléatoire : le *premaster + secret*, la chiffre avec le certificat donné par le serveur. + 4. le serveur déchiffre le secret + 5. Les deux partie dispose maintenant du *client random*, *serveur random* et + le *premaster secrets*. Ces trois éléments permettent de générer une clé de + session. + +#### Version avancée (DHE) + + 1. le client envoi un `hello` avec les même éléments de la poignée de main RSA + 2. le serveur répond avec les même éléments, il y ajoute son paramètre + *Diffie-Hellman*. Il chiffre le *client random*, le *server random* et les + paramètres DH avec sa clé privée. + 3. le client déchiffre et authentifie le message du serveur avec la clé + publique (certificat) + 4. en utilisant les paramètres DH du serveur et du client, les deux parties + calculent la *premaster key* + 5. comme pour la poignée de main RSA, les deux parties créent les clé de + session + +### Les attaques sur TLS + +#### CRIME + +*Compression Ratio Info-leak Made Easy* porte sur la compression et touche les +protocoles *HTTP* et *SPDY*. Elle permet le vol du cookie d'authentification. + +L'attaquant observe la taille du cyphertext envoyé par le navigateur pendant +qu'il force ce même navigateur à envoyer des requête spécialement forgée vers +des sites déterminés. + +#### HEIST + +*HTTP Encrypted Information Can Be Stolen Through TCP-Windows* est une attaque +qui n'utilise pas de MitM. Comme CRIME, l'attaque se joue dans le navigateur de +la victime et utilise pour partie la compression combinée à l'utilisation du +timing en side-channel (via *Javascript*). + +#### FREAKS + +*Factoring RSA Export Keys* est une attaque qui découle de faiblesses +délibérément introduites dans les implémentation des protocoles SSL/TLS. CEs +faiblesses sont dues aux législations des États-Unis d'Amériques sur +l'exportation des solution de chiffrement. + +Ces faiblesses sont combinées à la possibilité de renégocier la suite de +protocole utilisée dans TLS permet donc l'attaquant à forcer la victime à +choisir les protocoles affaiblis. + +#### Alpaca + +TLS ne s'occupe pas de chiffrer les données annexes comme les adresses IP, les +ports (source et destination) etc. Un attaquant peut alors rediriger le traffic +vers un serveur qu'il contrôle.