Finish IPsec and TLS course
This commit is contained in:
parent
5d803fdcb9
commit
5dbf36087c
5 changed files with 1244 additions and 66 deletions
|
|
@ -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
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue