Sécurité des échanges

applicatives
Préparé Par: Dr. Yassine Maleh

IEEE Senior Member

[email protected]
https://sites.google.com/view/maleh
Sécurisation des
échanges applicatifs:

Secure Layer Socket

SSL / Transport
Layer Security TLS
SSL / TLS

SSL (Secure Socket Layer) est un protocole à négociation (on parle

du « HandShake » SSL), développé à l'origine par Netscape.
Il a pour but de sécuriser les transactions Internet, par
authentification du client (Un navigateur la plupart du temps) et
du serveur, et par chiffrement de la session.

TLS (Transport Layer Security Protocol), développé par l'IETF, est

la version 3.1 de SSL.

Les Services fournis sont les suivants :

v Intégrité des données transmises (md5, sha-1) ;

v Confidentialité des données transmises (rsa, des, 3des…) ;
v Authentification de l’identité des correspondants la connexion est
fiable (X509 et MAC)
TCP/IP
v Pour comprendre SSL, il est utile de voir sur quoi il repose.

v IP (Internet Protocol) est le nom donné au protocole qui

déploie le trafic sur l’Internet. Le trafic est transmis par
petits paquets qui contiennent les adresses IP de
l’expéditeur et du destinataire.

v TCP (Transmission Control Protocol) repose au-dessus de

IP. Il est orienté connexion, ce qui signifie que certains
types de paquets sont transmis et acceptés dans le but
d’ouvrir une connexion. Les paquets qui suivent peuvent
alors être reconnus comme appartenant à une connexion
établie précédemment.
IP et TCP
v Le protocole IP est responsable du transport de paquets
d’une adresse internet à une autre. Chacun des petits
paquets sait où il va et d’où il vient (les adresses IP). Deux
paquets envoyés par le protocole IP ne sont pas
nécessairement reçus dans le même ordre.

v Le protocole TCP utilise le protocole IP pour établir des

connexions. Ceci permet de réordonner les paquets dans
l’ordre d’expédition. S’il y a perte d’un paquet, celui-ci sera
demandé à nouveau.

v TCP/IP est responsable de la communication à travers une

connexion entre deux adresses IP.

v L’architecture de TCP/IP est par couches («layers»).

La pile TCP/IP

Ensemble de services réseau faisant

l’interface entre le réseau et le
système d’exploitation. HTTP, FTP,
SMTP.

Permet d’identifier les programmes

sur lesquels les données message entête
transportées roulent. Réalise les
protocoles TCP et UDP.
entête
segment
Responsable de l’intégration des
adresses IP. La transport de datagramm entête
données vers des machines
distantes. Forme des datagrammes e
qui contiennent les données ainsi trame
que les adresses IP...

Première couche de la pile.

Responsable de la transmission des
données via un réseau physique
arbitraire. Achemine les données,
coordonne la transmission, formate,
conversion analogique/numérique,
contrôle d’erreurs. Entre machines
voisines.
Trames-Datagrammes-Segments
2
Fragmentation (en
paquets d’environ 1500
octets)

1
Les protocoles SSL / TLS :
Généralités
v Repose sur un procédé de cryptographie à clef publique
v Indépendant du protocole utilisé
▪ Transactions Web (HTTP), connexions via FTP, POP ou IMAP.
▪ Agit telle une couche supplémentaire, permettant d'assurer
la sécurité des données, située entre la couche application
et la couche transport
HTTP SMTP FTP
SSL/TLS

TCP/UDP

IP
Les protocoles SSL / TLS:
Généralités
Les protocoles SSL / TLS:
Connexion et session
SSL
v Connexion :
▪ Offre certains services de sécurité entre deux entités.
▪ Éphémère mais établie dans le cadre d'une Session SSL
v Session :
▪ Association entre un client et un serveur
▪ Etabli lors du protocole de "Handshake"
▪ Un ensemble de paramètres de sécurité, dans chaque
sens, est négocié une seule fois et partagé par les
connexions
▪ L'état courant défini les paramètres courants, l'état en
attente ("Session pending state") défini les paramètres
suivants (cf. "Change Cipher Spec Protocol") Nota : il peut
y a avoir plusieurs sessions établies entre 2 mêmes
partenaires (rarement)
Les protocoles SSL / TLS:
Paramètres de la session
v "Session identifier"
v "Peer certificate" :
▪ certificat X509 ou rien

v "Compression method"
v "Cipher specification" :
▪ algo. de chiffrement
et algo.
d'authentification et
leurs paramètres
v "Master secret"
▪ 48 octets partagés
entre le client et le
serveur
v "Is resumable":
▪ Les paramètres de la session peuvent être utilisés pour établir une
connexion
Les protocoles SSL / TLS:
Paramètres de la connexion
v "Server and client random" :
▪ Choisie à chaque nouvelle connexion.

v "Server write MAC secret" et "Client write MAC secret "

▪ Un secret utilisé pour vérifier l'intégrité des messages (un pour chaque
sens).
v "Server write key" et "Client write key" :
▪ Pour le chiffrement, dans le sens serveur-client et vice-versa.

v "Initialization vectors" :
▪ Utilisés en mode CBC. Le premier IV est issu du protocole
"Handshake", puis le dernier bloc chiffré sert d'IV pour la prochaine
transmission chiffrée, au sein de la même connexion.
v "Sequence numbers" :
▪ Un numéro de séquence est mémorisé, un pour chaque sens
de transmission.
Les protocoles SSL / TLS: Structure

SSL SSL SSL alert

Handshake cipher Application protocol
change Protocol (eg.
protocol protocol HTTP)
SSL Record Protocol

TCP

IP
Les protocoles SSL / TLS:
Vue globale
SSL est composé des protocoles suivants :

v Record Protocol : Responsable du transport des données brutes. Il

communique avec la couche transport. Il chiffre et authentifie (calcule
un CAM) l’information en utilisant le cipher_spec . Si le cipher_spec
est vide, alors l’information n’est ni chiffrée ni authentifiée.
v Handshake Protocol : Responsable de l’échange de clés
authentifiées. Le but de ce protocole est d’amener le client et le
serveur qui ne partagent pas de clés à s’entendre sur un
cipher_spec , choisi parmi ceux voulus par le client, avant d’exécuter
l’échange de clés authentifiées.
v ChangeCipher Protocol : Un message ou une entité annonce à
l’autre un changement de cipher_spec tel que négocié
précédemment.
v Alert Protocol : Un message indiquant une erreur.
L’anatomie de SSL
Opérations du "SSL Record protocol »
Opérations du "SSL Record
protocol »
Données applicatives
Fragmentation :
n frontières messages clients peuvent être
déplacées
Frag 1 Frag 2
n fragments de 214 octets au plus
Compression (optionnelle) :
ajoute au pire 1024 octets
Compressé
n

n sans pertes
Sceau :
n HMAC(MAC_write_secret,seq_num+type de
protocole TLS+version TLS+taille du
fragment compressé+fragment compressé)
Compressé MAC
+ = concaténation
Chiffrement :
n le fragment peut être paddé (chiffrement
Fragment chiffré
par blocs)
n on chiffre le fragment compressé + MAC
n ajoute au pire 1024 octets
"Change Cipher Spec Protocol"

v Lorsque la "cipher suite" doit être changée :

▪ à la réception de ce message d'un octet, on
substitue à la spécification courante la spécification
en attente ("pending state").
"Alert Protocol "

v Transmission d'un message d'alerte aux entités.

▪ Ces messages peuvent être compressés et
chiffrés comme les autres messages de la
Niveau Description
même session.
v Le champ "Level" :
▪ "warning" = 1
▪ "fatal" = 2 : la connexion est close et il n'y
PDU alerte
aura plus de nouvelles connexions pour
cette Session
v Le champ "Alert" spécifie l'erreur :
▪ "unexpected_message", "bad_record_MAC",
"decompression_failure",
"handshake_failure", "illegal_parameter" //
"close_notify",
"Handshake Protocol
Serveur client hello
serveur Hello
certificat
échange de clé
fin hello
certificat
échange de clé
fini
serveur Hello : client Hello :
-sélection de version SSL fini
-sélection d’algos -la version SSL maximale
échange de clé I : fini : -liste d’algos supportés
-un nonce Message -change cipher_spec -un nonce
certificat : complémentaire pour
certificat
-Transmet certificat l’échange de clé
-certificat éventuel client
X509 fini : -signature de la discussion
-Demande certificat -change cipher_spec
client (rare) échange de clé II :
clé pré-master chiffrée
SSL / TLS: Négociation de session

Déroulement habituel d'un

handshake SSL avec
authentification mutuelle :
en noir, les échanges initiés par
le serveur.
en rouge, les échanges initiés
par le client.
SSL / TLS: Négociation de session
Phase 1 : Etablissement des paramètres de sécurité
v Client Hello
• heure
• tirage nbre aléatoire client.random (28 octets)
• session Id : vide = nouvelle session,
session Id : renseigné = utiliser session déjà
ouverte
• choix d’algorithmes de chiffrement
supportés
• méthode de compression supportés
• n° version du client SSL utilisé
v Server Hello
• le serveur sélectionne la version
• tirage nbre aléatoire : server.random (28 oct)
• session Id : renseigné = numéro nouvelle
session, ou session à réutiliser ,
session Id : vide = session à ne pas
mettre en
cache
• algorithme de chiffrement sélectionné
• méthode de compression à utiliser
v Si session réutilisée, passer en FINISH
SSL / TLS: Négociation de session
Phase 2 : Authentification du serveur et échange des clés
v Server certificate
• envoyé si le serveur doit s’authentifier,
dès que Server Hello a été envoyé
• contient une chaîne de certificats X509
v3 (avec le certificat racine en dernier),
correspond à l’algo utilisé (RSA, DH,
>)
· le client dispose donc de la clé publique
du serveur

v Server key exchange

• envoyé uniquement si le client n’a pas
toutes les données nécessaires (ex: le
serveur n’a pas de certificat)
• paramètres de la clé de chiffrement
(modulo, exposant>)
• hash MD5/SHA (client.random +
server.random+paramètres)
SSL / TLS: Négociation de session
Phase 2 : Authentification du serveur et échange des clés
v Certificate request
• envoyé uniquement si l’authentification
du client est requise
• types de certificats admis
• noms d’autorités de certification
reconnues
v Server hello done
• le serveur attend une réponse
du client
v Client certificate
• envoyé uniquement si le serveur a
réclamé une authentification du client
• certificat
• si le client ne possède pas de certificat,
une alerte est envoyée au serveur.
Suivant les cas, cela peut faire échouer
la négociation
SSL / TLS: Négociation de session
Phase 3 : Authentification du client et échange des clés
Clé publique du
serveur
N° Version (2 bits) Pre Master Secret
RSA Key sécurisé
Pre Master Secret Key (46 bits)
Client Key Exchange
v Client key exchange
• dans le cas de l’algorithme RSA, le client génère un “pre-master
secret” de 46 octets + 2 octets n° version (pour détecter les «
rollback attacks »)
• il chiffre ce pre-master secret avec la clé publique du serveur
v Calcul des clés
• le pre-master secret, client.random et server.random permettent
au client et au serveur de calculer :
• 2 clés de sessions (une pour chaque sens), et
• 2 clés secrètes à utiliser pour les MACs.
SSL / TLS: Négociation de session

v Certificate verify
v envoyé si le client a envoyé un certificat qui permet de signer
v hash MD5 et hash SHA de tous les messages de
négociation envoyés jusqu’ici
v Client Finish et Server Finish
v envoyé après un Change Cipher Spec et donc chiffré avec les
nouveaux algorithmes négociés.
v client et serveur doivent envoyer un “Finish” et vérifier celui qu’il
reçoive de la partie opposée.
v PRF(master_secret,finished_label, Hash MD5 +Hash SHA de
tous les messages de négociations envoyés jusqu’ici) sur 12
octets, finished_label = “client finished” ou “server finished”.
SSL sans authentification du client
v Comme nous venons de le voir, un client SSL n’est pas
obligé de s’authentifier. SSL permet des sessions où
seulement le serveur s’authentifie au client mais pas
l’inverse.
v Dans bien des situations, c’est la meilleure chose
possible, car les clients n’ont pas nécessairement de clés
publiques certifiées.
v Dans cette situation, le client sait qu’il parle au bon
serveur, mais le serveur ne sait rien de l’identité du
client.
v L’identification du client peut alors se faire (comme c’est
le cas dans la pratique) en demandant un mot de passe.
L’authentification du client par
mot de passe
v Supposons qu’un serveur WEB détient une liste d’utilisateurs + mots de
passe mais les utilisateurs n’ont pas de clés publiques certifiées. Seul le
serveur possède une telle clé publique.
v Le serveur veut authentifier un utilisateur qui se connecte.

v Comment faire?

v Ouvrir une session SSL,

v Demander à l’utilisateur de fournir son mot de passe.

le mot de passe
est donc chiffré!

SSL
Limites de l’approche par mot de
passe
v Le client ne peut s’authentifier qu’au serveur qui connaît un mot
de passe pour celui-ci.
v La sécurité d’une telle session est plus difficile à établir, puisque
la gestion des mots de passe n’est pas intégrée au protocole
mais arrive plus tard.
v De tels systèmes sont aussi sûrs que le mot de passe. Donc, il
semble qu’un système qui établirait l’identité d’un client basé sur
un mot de passe dès le départ serait au moins aussi bon :
v Plus précisément, nous pourrions avoir un protocole
d’établissement de liaison qui ne puisse être compromis plus
rapidement que le temps nécessaire pour deviner le mot de
passe en ligne.
v Rien de mieux ne peut être obtenu.
v Un tel échange de clés est dit « échange de clés authentifié
par mots de passe ».
Échange de clés authentifié par mot de
passe
Ceci semble facile. Les deux parties connaissent un secret pw :

v Nous n’avons qu’à dériver une clé secrète directement à partir de pw ou même utiliser
pw directement pour le chiffrement et le calcul de CAM...

v L’utilisation à long terme sur beaucoup de données cause des problèmes desécurité.

v Les mots de passe doivent être assez courts pour être faciles à mémoriser. Le nombre
de mots de passe possibles est donc beaucoup plus petit que le nombre de possibilités
pour la clé secrète d’un chiffrement symétrique.

v L’adversaire, ayant intercepté un cryptogramme, peut donc tenter le déchiffrement en

essayant les mots de passe possibles hors ligne...tandis que deviner le mot de passe en
ligne peut résulter en une désactivation du compte après quelques essais infructueux.

Ce problème difficile a des solutions connues (p.ex. Bellare et al. Eurocrypt’2000) .

Quelques-uns (sans preuve formelle de sécurité) sont considérés pour standardisation par
l’Internet Engineering Task Force et IEEE Ne sont pas utilisés par les produits
commerciaux...
SSL versus TLS
v Le même format de message.
v L'un est propriétaire, l'autre publique
(IETF).
v Les différences mineures résident dans :
n version number
n message authentication code
n pseudorandom function (TLS : fonction PRF)
n alert codes (TLS en ajoute plusieurs)
n cipher suites
n client certificate types
n certificate_verify and finished message
n cryptographic computations
HTTP
S
v HTTPs = HTTP standard sur le port 443 (à
la place de 80) + TLS + TCP/IP
vGénéralement le driver SSL/TLS est intégré
au navigateur
Applications
v Secure HTTP est le nom donné à l’utilisation de SSL ou TLS pour établir une
connexion sûre entre un serveur WEB et son client. Le résultat est un tunnel entre
le client et le serveur, par lequel chaque transmission est chiffrée sans que
l’application ait à s’en soucier :

v https://www.abc.def.com

v VPN (Virtual Private Network) permet d’établir des connexions sûres entre un
client distant et un réseau local. Durant la phase d’initialisation entre le client et la
passerelle VPN, celui-ci se voit attribuer une adresse IP comme s’il était membre du
réseau local.

v Une fois initialisées, toutes les communications sont chiffrées et authentifiées. Pour
ce faire, un échange de clé est nécessaire. Des VPN le réalisent avec leurs
propres méthodes tandis que d’autres utilisent IPSec ou SSL/TLS. VPN permet de
travailler comme si le client faisait partie du réseau local. Des employés peuvent
travailler à la maison avec les mêmes privilèges qu’au bureau.
Applications de haut
niveau
v Les protocoles que nous avons rencontrés sont de bas niveau. Ils ne sont pas
bien adaptés aux humains!

v SSL ne peut être utilisé pour signer des courriels ou documents, car SSL ne
reconnaît pas le concept de document.

v La cryptographie appliquée à des objets de plus haut niveau est offerte par
d’autres solutions.

v MIME : un standard pour la transmission des courriels. S/MIME est un standard avec
des champs supplémentaires pour la signature et le chiffrement de courriels.

v XML : un standard qui propose une extension de HTML qui, en particulier, permet de
chiffrer et de signer des pages Web.

v PGP (Pretty Good Privacy) : permet de signer et de chiffrer des courriels. Au lieu
de baser la sécurité sur des CA, il utilise un concept de toile de confiance («web of
trust»). Votre ami(e) peut vous envoyer une clé publique d’une troisième personne
qui déclare que ceux-ci font confiance à cette clé. Vous pouvez décider de faire
confiance à cette clé si suffisamment de vos amis l’ont recommandée.
SSL / TLS: Attaques
Attaques sur les mise en œuvres des protocoles
• Comme toute appli logicielle, les MeV de SSL/ TLS peuvent présenter
vulnérabilités permettant à un utilisateur mal intentionné d'exécuter du
code arbitraire à distance ou de provoquer un DoS.
Appliquer CORRECTIFS correspondants aux MAJ de ces applis
Attaques rollback (sur anciennes versions)
• l'attaquant cherche à modifier le choix des algos d'échanges de clés de
façon à ce que les 2 entités n'utilisent pas les mêmes (RSA et DH par
exemple).
• cet attaquant pourra déchiffrer le message car les paramètres fournit
par le serveur dans le cas d'un algorithme n'offrent aucune sécurité si
on les applique à un autre...
• Cette attaque peut-être réalisée si une session 3.0 est résumée en
session 2.0 par exemple.
SSL / TLS: Attaques
Attaque de type "man in the Middle "
• intercepter trafic entre deux parties avant qu'elles ne débutent une
session SSL. L'intercepteur négocie alors une session avec chaque
partie et fait suivre le trafic en le déchiffrant et rechiffrant à la
volée.
• E.g., dans le cas de l'utilisation du protocole HTTPS par un client
web pour authentifier un serveur, l'intercepteur crée un
certificat ressemblant au certificat légitime du serveur et
détourne le trafic.
• Si, malgré l'avertissement du navigateur sur le certificat, le
client poursuit sa session, l'intercepteur obtiendra toutes les
infos que le client envoie au serveur sans que ce dernier ne s'en
rende compte.
• ++ outils qui reproduisent cette attaque sont disponibles sur
l'Internet.
SSL / TLS: Solutions
Vérifier correctement le certificat présenté par le serveur. C'est Vérifier
correctement le certificat présenté par le serveur. C'est la seule manière
de s'assurer que la connexion ne sera pas la seule manière de s'assurer
que la connexion ne sera pas interceptée par un éventuel attaquant.
interceptée par un éventuel attaquant.
n Dans les navigateurs, les certificats racine de certaines autorités de
certification sont pré-installés.
n Lorsque le certificat présenté par un serveur n'a pas été signé par l'une de ces
autorités, le navigateur demande confirmation avant d'accepter le certificat. Il
faut alors s'assurer que le certificat présenté par le serveur est le bon
certificat.
n Cette vérification peut se faire à l'aide de deux champs du certificat : le
numéro de série et l'empreinte numérique (empreinte md5 ou sha1). Pour
vérifier la concordance des informations, il faut disposer d'un moyen de
communication de confiance (téléphone, courrier, diffusion de la main à la
main, ...) par lequel pourront être comparés les numéros de série et les
empreintes. De même, il ne faut installer un certificat d'autorité qu'après s'être
assuré que le certificat est correct.
SSL / TLS: Limites
SSL/TLS servent à sécuriser les échanges d'informations entre un client et un serveur et à
obtenir une authentification mutuelle.
Une session SSL/TLS correctement établie va donc protéger les échanges entre les parties,
mais ne sera en protéger les échanges entre les parties, mais ne sera en aucun une garantie
de sécurité pour les systèmes client aucun une garantie de sécurité pour les systèmes client ou
serveur. ou serveur.
Ainsi, si un pirate installe par exemple un enregistreur de frappe (ou keylogger) sur le poste
client, il sera en mesure frappe (ou keylogger) sur le poste client, il sera en mesure de
récupérer les mots de passe ou toute information de récupérer les mots de passe ou toute
information confidentielle, même si celle-ci a été émise lors d'une confidentielle, même si celle-
ci a été émise lors d'une session SSL/TLS. session SSL/TLS.
De même, un serveur qui utilise des sessions SSL/TLS pour récupérer des données sensibles
peut être compromis et récupérer des données sensibles peut être compromis et les données
recueillies pourront être volées. les données recueillies pourront être volées.
ll est donc primordial d'utiliser les protocoles SSL/TLS en prenant certaines précautions, et ne
pas leur prêter une prenant certaines précautions, et ne pas leur prêter une trop grande
garantie de sécurité sur l'ensemble de la trop grande garantie de sécurité sur l'ensemble de la
chaîne d'information chaîne d'information.
Travaux pratiques

SSL/TLS et configuration avancée

Objectifs
• Mettre en place une configuration
SSL/TLS
• Analyse du traffic SSL/TLS
Outils à utiliser

• Serveur/Client
Linux
• GnuTLS
• Wireshark
Sécurisation des
échanges applicatifs:

SSH (Ou Secure Shell)

Le protocole SSH
Le protocole Telnet : simple mais dangereux
Un protocole très simple, très
basique, a été créé dans les
années 80 : c'est Telnet. Il sert
juste à échanger des messages
simples d'une machine à une
autre.
En théorie donc, on peut
communiquer avec un serveur à
l'aide du protocole Telnet. Le
problème de ce protocole… c'est
justement qu'il est trop simple :
les données sont transférées en
clair sur le réseau. Il n'y a aucun
chiffrement
Le protocole SSH: Généralités

SSH (Ou Secure Shell) est un protocole servant à créer une

connexion sécurisée entre deux systèmes.

v Mesures de sécurité offertes :

▪ Assurance du client de la connexion au même serveur lors des
sessions suivantes ;
▪ Transmission de ses données d'authentification au serveur, telles
que son nom d'utilisateur et son mot de passe, en format crypté ;
▪ Transfert de façon chiffrée des données envoyées et reçues à lire ;
▪ Possibilité pour le client d’utiliser des applications X11 lancées à
partir de l'invite Shell. Cette technique fournit une interface
graphique sécurisée (appelée retransmission X11).
Le protocole SSH: Généralités

v Création d’une couche transport sécurisée ;

v Chiffrement de la communication au moyen d'un chiffre symétrique ;
v authentification, une fois la connexion sécurisée établie avec le serveur et
client ;
v Utilisation de nombreux services différents de façon sécurisée, tels
qu'une session Shell interactive, des applications X11 et des ports TCP/IP
Tunnellisés.

L'ensemble du processus de connexion se fait sans que le système local

n'ait à faire de nombreuses opérations supplémentaires.
Le protocole SSH: Mode de
fonctionnement
Lorsqu'un client communique avec un serveur au moyen d'un protocole SSH, de
nombreux éléments importants sont négociés afin que les deux systèmes puissent
créer correctement la couche transport :
v L'échange des clés ;
v L'algorithme de clé publique à utiliser ;
v L'algorithme de chiffrement symétrique à utiliser ;
v L'algorithme d'authentification de message à utiliser ;
v L'algorithme repère (Hash) à utiliser.
Le protocole SSH: Mode de
fonctionnement
Permet de créer un tunnel chiffré vers un réseau ;

Etapes :

Exécution d’un script qui à l ’aide d’une session SSH, lance PPP sur la
passerelle et redirige les entrées/sorties de façon à faire ; passer PPP
dans SSH ;

Routage des données à destination du réseau interne vers l’interface PPP

résultante ;

Passerelle joue le rôle de Proxy-Arp pour le nomade, qui semble ainsi

appartenir au réseau interne.
Le protocole SSH: Démo

v Se connecter via SSH à partir

d'une machine Windows
v Se connecter via SSH à partir
d'une machine Linux
v L'identification automatique par
clé
Sécurisation des
échanges applicatifs:

Virtual Private Network

VPN
VPN: Généralités

UN VPN (Virtual Private Network) est une liaison sécurisée

entre deux parties via un réseau public, en général Internet.
Cette technique assure l’authentification des deux parties,
l’intégrité des données et le chiffrage de celles-ci.

Permet à un hôte distant d ’accéder à l’Intranet de son entreprise ou à

celui d’un client grâce à Internet tout en garantissant la sécurité des
échanges ;

Permet à l’entreprise d’échanger des données en toute sécurité avec ses

sites distants ou ses partenaires ;
VPN: Généralités

v Un VPN est un réseau privé virtuel.

v Il permet de créer un lien entre deux réseaux LAN distants.
v Un VPN host-to-lan se crée entre un PC et un réseau
LAN. v Un VPN lan-to-lan se crée entre deux LAN.
v Pour créer un VPN, on envoie les paquets au travers d'un
tunnel.
v Un tunnel permet, grâce à plusieurs protocoles :
• L'authentification
• l'intégrité des données
• La sécurité des données
VPN: Généralités

Caractère virtuel :
n C’est la technique du tunneling qui permet d’étendre de façon
« virtuelle » le réseau privé à travers un réseau public

Caractère privé :
n C’est le cryptage qui confère son caractère privé aux données
puisqu’elles ne peuvent être décodées que par les interlocuteurs
d’extrémité

Réseau Virtuel : tunneling

Réseau Privé : cryptage

VPN: Généralités

Méthode utiliser pour faire transiter des informations privées sur un

réseau public ;
Garantit la confidentialité et l’intégrité des données ainsi que
l ’authenticité des deux parties ;
Chaque paquet est complètement chiffré et placé à l’intérieur d’un
nouveau paquet.
VPN: Généralités

Exemples de protocoles de tunneling :

n GRE (Generic Routing Encapsulation)
n L2TP (Layer 2 Tunneling Protocol)
n IPSec
VPN: Scénarios
Qui crée des VPN ?
Les administrateurs réseaux des entreprises :
- ils créent des VPN LAN to LAN aussi bien que des VPN d’accès

distant, pour les besoins des personnels et des partenaires de

l’entreprise
Les opérateurs téléphoniques et les fournisseurs d’accès à
Internet :
- ils créent des VPN LAN to LAN « clefs en main » qu’ils proposent aux
entreprises
- ces offres de VPN s’accompagnent souvent de services comme :
• l’accès à Internet
• l’hébergement de serveurs
• le filtrage de paquets
• la fonction FireWall
• l’antivirus
• la détection d’intrusions
VPN: Choix de Technologie

Application
Couches (5-7)

Couche Réseau

Ré se a u / IPSec L2F
L2TP
Transport GRE
Couches PPTP
(3-4)
Ph ysi q u e/
Liaison
Couches
(1-2)
Protocoles VPN Description Standard
L2TP Layer 2 tunneling Protocol RFC 2 6 6 1
GRE Generic Routing RFC 1 7 0 1 et 2 7 8 4
Encapsulation
IPSec Unternet Protocol RFC 2 4 0 1
Security
IPSec
v IPSec est un ensemble de protocoles qui accomplit des
fonctions semblables à SSL mais situé à un autre endroit de
la pile TCP/IP.

SSL

IPSec

v IPSec est de plus bas niveau que SSL/TLS. Le résultat est ce qui
est appelé une association de sécurité entre deux adresses IP.
v Étant de plus bas niveau implique que même les informations de
contrôle, les numéros de séquences utilisés pour gérer la
connexion TCP, sont chiffrés.
IPsec: Principe de fonctionnement
Créez un tunnel avec IPsec
Différents cas d’usage d’IPsec

Interconnexion de deux sites PC à Routeur/Concentrateur VPN

Interconnexion de plusieurs sites avec PC à Firewall / Routeur à Firewall

routage
IPsec: Principe de fonctionnement

IPSec

ESP

AH
Encryption Integrity Integrity

DES, 3DES, AES MD5, SHA1, SHA2, SHA3

Sécurité et IP

v Mécanismes cryptographiques :
▪ Authenticité = Code d’authentification de message (MAC)
authentification de message (MAC)
▪ Confidentialité = Chiffrement
▪ Protection contre le Protection contre le rejeu = Numéro
de séquence
v Deux en-tête d’extension :
▪ En-tête d'extension d'authentification (Authentification
Header, AH)
▪ En-tête d'extension de confidentialité (Encapsulating
Security Playload Header, ESP)
v Mécanismes ci-dessus font appel à la cryptographie et utilisent donc
un certain nombre de paramètres (algorithmes utilisés, clefs,
mécanismes sélectionnés …).
IPsec: Modes Transport et Mode
tunnel
v Deux modes

IPSec en mode transport

En-tête En-tête En-tête Données

IP TCP
IPSec
IPSec en mode tunnel
Nouvel En-tête En-tête En-tête Données
En-Tête IP IP D’origine TCP
IPSec
IPsec: Mode Transport

v En mode transport, on chiffre/authentifie la partie data d'un

paquet IP excepté les champs
variables de l’en-tête (TTL,
….)
v En mode tunnel, on protège le paquet complet (y
compris
l’en-tête IP) et on l'encapsule dans un nouveau paquet, avec
un nouvel en-tête IP qui sert à transporter le paquet jusqu'à
la fin du tunnel, où l’en-tête d’origine est rétablie.

▪ Offre une protection plus importante contre l’analyse du trafic, car il

analyse du trafic, car il masque les adresses de la source et de la
destination finale. masque les adresses de la source et de la
destination finale.
Comparaison avec SSL
v IPSec demande qu’un client soit installé sur chaque unité pour permettre le
chiffrement. Sa configuration est plus difficile que pour SSL (transparent).
v SSL est inclus dans les navigateurs, ce qui ne nécessite pas l’installation de
clients.
v SSL fonctionne plutôt pour des applications Web, ce qui n’est pas le cas
d’IPSec.
v IPSec est utilisé pour les communications site à site qui ne sont pas de
type client-serveur.
v Certains routeurs NAT (Network Adress Translation) ont de la difficulté avec
IPSec. SSL n’a pas ce problème.
v Certains fournisseurs d’accès Internet demandent d’être payés pour des
communications IPSec. C’est impossible à faire avec SSL.
v Si IPSecv6 devenait supporté par les applications, alors SSL pourrait
devenir
inutile.
IPSec : protocoles
• Authentication Header (AH)
• Encapsulation Payload (ESP)
• Security Association (SA)
• Security Association Database
(SAD)
• Security Policy Database (SPD)
• Internet Key Exchange (IKE)
• Internet Security Association Key
• Management Protocol (ISAKMP)
Ipsec: Mode de fonctionnement

v ESP : Encapsulating Security Payload ; Assure au choix un ou

plusieurs des services suivants :
▪ Confidentialité des données et protection partielle contre l’analyse
du trafic si l ’on utilise le mode tunnel ;
▪ Intégrité Des Données en mode connecté et authentification de
l’origine des données, protection partielle contre le Rejeu.

v AH : Authentification Header.
▪ Assure l’intégrité en mode non connecté et l’authentification de
l’origine des datagrammes IP sans chiffrement des données
▪ contient tout les paramètres relatifs à chaque SA ;
▪ La confidentialité assure que ce standard pourra être le plus
répandu
sur Internet.
Ipsec: Mode de fonctionnement

v SAD : Security Association Database.

▪ Gère les associations de sécurité actives ;
▪ Contient tout les paramètres relatifs à chaque SA ;
▪ Consultée pour savoir comment traiter chaque paquet reçu ou à
émettre.
v SPD : Security Policy Database.
▪ Etablie et maintenue en place par un utilisateur, un administrateur ou
une application mise en place par ceux-ci.
v IKE : Internet Key Exchange ;
▪ Authentifie chaque correspondant ;
▪ Négocie la stratégie de sécurité ;
▪ Gère l’échange des clés de session ;
▪ Protocole hybride combinant différentes parties des protocoles
suivants : ISAKMP, OAKLEY, SKEME.
 IPSec : Authentification Header
E n- E n-tête Charge utile IP
tête IPSec sécurisé Internet
IP ou Réseau Privé

Sy t è m e
avec
IPsec
Payload
Next Header Length RESERVED
Security Parameters Index (SPI)
Sequence Number

Données authentifiées
(Variable)

E n-
Charge utile IP
tête
IP

E n-
Charge utile IP
tête
IP

AH (Authentication Header) - Protocole de sécurité qui

fournit l'authentification, l'intégrité des données
AH est dans la charge utile du paquet
IPSec : Authentification Header
IPSec : Authentification Header
IPSec : Encapsulated Security
Payload
IPv4 En- tête
TCP Donnée s
IP original
(a) Paquet IP original

Authentifié

Crypté

IPv4 En- tête En- tête Que ue Auth

TCP Donnée s
IP original ESP ESP ESP

(b) Mode Transport

Authentifié

Crypté

IPv4 Nouveau En- tête En- tête Que ue Auth

TCP Donnée s
En- tête IP ESP IP original ESP
ESP
(c) Mode Tunne l

v ESP (Encapsulation Security payload) - Protocole de sécurité qui

fournit la confidentialité (entre autres)
v ESP encapsule les données à protéger
IPSec : Encapsulated Security
Payload
IPsec, AH et ESP en
mode transport
v Indépendamment du choix entre AH et ESP, il est possible d’utiliser IPsec
dans deux modes distincts : le mode tunnel et le mode transport. Le
mode tunnel rend le service attendu dans la majorité des cas
v En mode transport, les en-tête IP d’origine sont conservés
v Il est utilisé pour sécuriser la communication entre deux postes ayant des
adresses publiques
v Ce n’est donc pas ce mode qui sera utilisé pour réaliser un VPN, puisque
nous souhaitons adresser des machines privées
v On peut utiliser cette technique pour sécuriser la communication entre
une machine publique sur Internet (l’administrateur depuis son domicile
par exemple) et un serveur publique (pour du paramétrage à distance
par exemple), mais pour ce cas, il existe d’autres techniques comme SSH
(Secure Shell)
AH et ESP en mode transport

IP En-tête IP DATA

IPsec En-tête IP AH ESP DATA ESP

crypté (ESP)
authentifié (AH)

Utilisation de AH et de ESP
en mode transport

v AH et ESP peuvent, dans ce mode, être vus comme un protocole

intermédiaire entre TCP et IP
v L’en-tête IP doit porter des adresses publiques pour voyager à travers
Internet
AH et ESP en mode tunnel

v En mode tunnel, les en-tête d’origine sont cryptés, et un

autre en-tête IP sera ajouté (on encapsule de l’IP dans de
l’IP)
v Il est utilisé pour sécuriser la communication entre deux
équipements d’interconnexion (entre des routeurs ou des
firewalls)
v C’est le mode qui sera utilisé pour réaliser un VPN,
puisque nous souhaitons adresser des machines privées
v C’est la technique la plus répandue pour faire du LAN to
LAN VPN
AH et ESP en mode tunnel
En-tête IP(ancienne) DATA
IP
IPsec En-tête IP(nouvelle) AH ESP En-tête IP (ancienne) DATA ESP

crypté (ESP)
authentifié (AH)

Utilisation de AH et de ESP en mode tunnel

v ESP crypte le paquet d’origine, en-tête IP compris
v AH assure l’authentification et l’intégrité de l’ensemble
v L’en-tête IP initiale peut contenir des adresses privées puisqu’elle n’est pas
utilisée par les routeurs d’Internet
v L’en-tête IP ajouté portera les @ IP des routeurs (ou firewalls)
d’interconnexion, qui sont forcément publiques
IPSec : Security Policy
v Le terme « Security Policy » désigne, dans le contexte
IPsec, le choix pour un lien unidirectionnel donné :
▪ de l’utilisation obligatoire ou facultative ou de la non-
utilisation d’IPsec ;
▪ de l’utilisation du mode tunnel ou transport ;
▪ de l’utilisation d’AH ou d’ESP.

v L’ensemble des SP est regroupé dans une SPD : « Security

Policy Database ». À l’image des règles de flux d’un pare-
feu, les SP ont pour but de spécifier les flux que l’on veut
autoriser et ceux que l’on veut interdire.
Etablissement d’un lien IPsec
v Les mécanismes cryptographiques utilisés pour la protection
en intégrité ou en confidentialité sont paramétrés par une
ou plusieurs clés.
v Ces éléments doivent être partagés par les différents hôtes
employant IPsec.
v Deux approches sont possibles :
▪ mettre en place manuellement des clés sur chaque
hôte
▪ ou utiliser le mécanisme d’échange de clés IKE pour que
les hôtes puissent négocier ces clés.
IPSec : Security Association SA

v SA (Security Association) : c’est l’ensemble de principes

(politiques) et de clés utilisés pour protéger l'information
v Plusieurs SA sont utiles pour « monter » un tunnel
IPSec
v Il faut une SA pour IKE (tunnel de service, on dit aussi SA
ISAKMP)
v Il faut une SA pour IPSec (tunnel de données)

v Les SAs ISAKMP sont bidirectionnelles

v Les SAs IPSec sont unidirectionnelles
v Les équipements VPN stockent leurs SAs dans une base
de données locale appelée la SA Database (SAD)
IPSec : Security Association SA
v Les informations Les informations
échangées sont :
▪ index de la SA appelé (pour Security Parameter
Parameter Index)
▪ un numéro de séquence, indicateur utilisé pour
le service d'anti-rejeu
▪ une fenêtre d'anti-rejeu : compteur 32 bits
▪ dépassement de séquence
▪ paramètres d'authentification (algorithmes et
clés)
▪ paramètres de chiffrement (idem)
▪ temps de vie de la
▪ mode du protocole mode du protocole IPsec
(tunnel ou transport)

Attention : un SA est Attention : un SA est

Unidirectionnelle: protéger les deux sens d'une ger
les deux sens d'une communication classique
requiert communication classique requiert deux
associations.
IPSec : Security Association SA
IPSec : Security Association SA
1. IPSec reçoit les données à envoyer ;

2. Consulte la base de données des politiques de sécurité (SPD) ;

3. Si indication d’application des mécanismes de sécurité, elle récupère les

caractéristiques requises pour la SA correspondante et va consulter la base

des SA (SAD) ;

4. Si la SA existe déjà, elle est utilisé pour traiter le trafic ;

5. Dans le cas contraire, IPSec fait appel à IKE pour etablir une
nouvelle

SA.
IPSec : Security Association SA
1. IPSEC reçoit les données en provenance du réseau ;

2.Examine l’en-tête pour savoir si ce paquet s’est vu appliquer un ou

plusieurs services IPSEC et si oui, quelles sont les références de la SA ;

3.Consulte alors la SAD pour connaître les paramètres à utiliser pour la

vérification et/ou le déchiffrement du paquet ;

4.Consultation de la SPD pour savoir si l’association de sécurité appliquée

au paquet correspondait bien à celle requise ;

5. Dans le cas où le paquet reçu serait un paquet IP classique, la SPD

permet de savoir s ’il a néanmoins le droit de passer.

IPSec : SA
IKE
Host Host
A Router Router B
A B

10.0.1. Negotiate IKE

10.0.2.
3 Proposals
3
Transform 10 Transform
DES 15 DES
MD5 MD5
pre-share IKE Policy Sets pre-share
DH1 DH1
lifetime lifetime

Transform 20
3DES
SHA
pre-share
DH1
lifetime

v Exemple de SA IKE (on dit aussi SA

ISAKMP)
IPSec :
IKE
IPSec IPSec

Routeur A Routeur B

IKE IKE
Tunnel IKE

v IKE est un protocole utile pour négocier une partie de la politique de

sécurité (Security Association : SA) qui servira pour l’échange des
données
v IKE est orienté gestion des clés
v IKE est issu des anciens protocoles de gestion de clés SKEME et
Oakley
v IKE fonctionne dans le cadre de ISAKMP
v IKE n’est pas le seul protocole de gestion de clés disponible, mais il est
le seul utilisé en pratique pour IPSec
IPSec : ISAKMP
A B

Accès Accès
Backbone
c li e nt Opérateur c li e nt
SADB SADB

A vers B A vers B
ESP/ DES/ SHA- ESP/ DES/ SHA-
1 Keys K1,K2,... 1 Keys K1,K2,...
lif e t ime = 3600 s lifetime= 3600 s

B vers A B vers A
ESP/ DES/ SHA- ESP/ DES/ SHA-
1 1
ke ys K6,K7,... ke ys K6,K7,...
lif e t ime = 3600 lifetime= 3600
s s
v La négociation des SAs ne concerne pas que la gestion des clés
v ISAKMP est le protocole « cadre » qui va permettre à IKE de fonctionner, mais il
sert aussi à négocier les autres paramètres des SAs
v ISAKMP sert à négocier les SAs, mais n’impose rien quant aux paramètres qui
composent ces SAs
v ISAKMP définit les procédures et les formats de paquets pour créer, gérer,
détruire des SAs
18
v ISAKMP permet aussi d’authentifier les partenaires d’une SA 6
IPSec : les 5
étapes
Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A et B n égocien t une se ssion IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3. Les routeurs n égocien t une se ssion IKE Phase 2

IKE SA IKE Phase 2 IKE SA

4. Les information so nt éch an gées via le Tunne l IPSec

5. Le tunnel IPSec es t libéré.

v On distingue 5 étapes lors de l’utilisation d’un tunnel

VPN
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A et B n égocien t une se ssion IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3. Les routeurs n égocien t une se ssion IKE Phase 2

IKE SA IKE Phase 2 IKE SA

4. Les information so nt éch an gées via le Tunne l IPSec

5. Le tunnel IPSec est libéré.

v Etape 1 : A reconnaît des informations à transmettre vers le B par le VPN

n le trafic est dit "intéressant" quand l'équipement VPN reconnaît que les données doivent
être protégées : définition d’une ACL
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A et B n égocien t une se ssion IKE Phase 1

IKE SA IKE Phase 1 IKE

SA

3. Les routeurs n égocien t une se ssion IKE Phase 2

IKE SA IKE Phase 2 IKE SA

4. Les information so nt éch an gées via le Tunne l IPSec

5. Le tunnel IPSec est libéré.

v Etape 2 :
n IKE Phase 1 authentifie les extrémités IPSec et négocie la SA IKE
(ou SA ISAKMP)
n Ceci crée un canal sécurisé pour négocier les SAs IPSec en
Phase 2
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A et B n égocien t une se ssion IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3. Les routeurs n égocien t une se ssion IKE Phase 2

IKE SA IKE Phase 2 IKE SA

4. Les information so nt éch an gées via le Tunne l IPSec

5. Le tunnel IPSec est libéré.

v Etape 3 :
n IKE phase 2 négocie les SAs IPSec en cherchant une
correspondance entre les SAs IPSec des extrémités
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A et B n égocien t une se ssion IKE Phase 1

IKE SA IKE P h a s e 1 IKE SA

3. Les routeurs n égocien t une se ssion IKE Phase 2

IKE SA IKE Phase 2 IKE SA

4. Les information so nt éch an gées via le Tunne l IPSec

5. Le tunnel IPSec est libéré.

v Etape
4: n Le transfert de données est effectué entre les extrémités IPSec
sur la base des paramètres IPSec et des clés stockées dans les
SAs négociées en étape 3
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A et B n égocien t une se ssion IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3. Les routeurs n égocien t une se ssion IKE Phase 2

IKE SA IKE Phase 2 IKE SA

4. Les information so nt éch an gées via le Tunne l IPSec

5. Le tunnel IPSec est libéré.

v Etape 5 :
n La libération du tunnel IPSec survient quand la session qui a motivé
le montage du VPN se termine ou sur « time out »
Critique d’IPSec
v Les performances sur le lien IPSec sont réduites à cause du chiffrement
v IPSec ne supporte pas le multicast : AH et ESP l’autorisent, mais IKE ne
prévoit pas de négocier des SAs entre plus de deux firewalls
v La complexité de IKE conduit à des incompatibilités entre les différents
constructeurs
v Le trafic est suspendu pendant le renouvellement des SAs
v La gestion des messages ICMP n’est pas triviale : si un message ICMP
vient d’un équipement par lequel transite le tunnel, il ne peut
remonter que jusqu’au firewall d’origine. Il faut alors que ce firewall
sache prévenir la vraie source des données pour lui faire comprendre
que le VPN est indisponible
v Il ne doit pas y avoir de NAT au dessus de VPN (le NAT en dessous de
VPN est courant, voire obligatoire sur un firewall)
OpenVPN

v OpenVPN cumule de nombreux avantages car il est :

v open source et fiable ;
v gratuit au niveau logiciel ;
v multi-plates-formes (c'est-à-dire compatible Windows, Linux,
Mac OS X...) ;
v très répandu ;
v capable de tourner sur n'importe quel port en écoute côté
serveur (y compris 80 ou 443).
OpenVPN

v OpenVPN cumule de nombreux avantages car il est :

v open source et fiable ;
v gratuit au niveau logiciel ;
v multi-plates-formes (c'est-à-dire compatible Windows, Linux,
Mac OS X...) ;
v très répandu ;
v capable de tourner sur n'importe quel port en écoute côté
serveur (y compris 80 ou 443).
Travaux pratiques

v Mise en place d’un tunnel sécurisé

entre deux réseaux (VPN avec Pfsense)
Objectifs
v Sécurisez votre infrastructure grâce à
pfSense
v Mettre en place un VPN sécurisé avec
OpenVPN
Outils à utiliser

v Pfsense
v OpenVPN
v Client Linux
v Client Windows