259 lines
10 KiB
Markdown
259 lines
10 KiB
Markdown
---
|
|
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
|
|
|
|
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;
|
|
|
|
## IPSec
|
|
|
|
C'est un protocole ancien (~1994) créé pour répondre aux 4 propriétés vu
|
|
précédemment. Il se positionne dans la couche IP, il est donc totalement
|
|
transparent pour les couches supérieures.
|
|
|
|
IPSec est composé de plusieurs parties:
|
|
|
|
* **ESP (*Encapsulating Security Payload*)**: chiffrement;
|
|
* **AH** (*Authentication Header*): authentification de l'origine des paquets,
|
|
contrôle des accès, rejet des paquets rejoués;
|
|
* **Négociation**: établissement des paramètres de la communication
|
|
avec**IKE** (*Internet Key Exchange*).
|
|
|
|
### Les défi des attaques par rejeu
|
|
|
|
Ces types d'attaques permettent de mettre à mal des protocoles réputés fiables
|
|
comme *WPA2*. Quelle solution est implémentée dans IPSec?
|
|
|
|
Au niveau du récepteur, un identifiant de paquet et une fenêtre de réception
|
|
sont utilisés. Une **fenêtre** est une intervalle de temps bornée pendant
|
|
laquelle les identifiants sont acceptés.
|
|
|
|
Le déroulé:
|
|
|
|
* Une fenêtre de taille `W` est créée sur le récepteur;
|
|
* Le numéro d'ordre le plus élevé, noté `N`, est placé à l'extrémité droite de
|
|
la fenêtre;
|
|
* Pour tout paquet reçu avec un numéro d'ordre compris entre `N - W +1` et `N`,
|
|
la position correspondante est marquée;
|
|
* Lors de la réception d'un nouveau paquet;
|
|
* Si la position et la *MAC* sont corrects, la position est marquée
|
|
* Si la *MAC* est correct et que le numéro d'ordre est à droite de la
|
|
fenêtre, alors cette dernière est avancée de sorte que `N` prenne la
|
|
valeur du numéro d'ordre de ce paquet;
|
|
* Si la *MAC* est invalide ou que le numéro d'ordre est à gauche de la
|
|
fenêtre, **il est détruit**;
|
|
|
|
### Authentication Header
|
|
|
|
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)).
|
|
|
|
L'entête permet aussi la détection du rejeu (cf chapitre au dessus)
|
|
|
|
### Encapsulated Security Payload
|
|
|
|
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)
|
|
|
|
### 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 /
|
|
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 fonction de hashage, `K` la clé et `M` le message.
|
|
|
|
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:
|
|
|
|
|
|
|
|
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é.
|
|
|
|
|
|
|
|
Ce mode assure la protection du paquet IP dans sa totalité.
|
|
|
|
En mode ESP, le message doit être **chiffré**.
|
|
|
|
|
|
|
|
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.
|