VPN SSL

Ollier Jean - Charles
Pantel Marc
Vallière Romain
Sommaire
1 - Les réseaux privés virtuels (VPN)
2 - Présentation et architecture du SSL
3 - Sous protocoles
SSL et les certificats
4 - Analyse du niveau de sécurité
5 - Conclusions
1 - Les réseaux privés virtuels (VPN)
Les réseaux locaux d'entreprise (LAN ou RLE) sont des réseaux internes à une
organisation, c'est-à-dire que les liaisons entre machines appartiennent à
l'organisation. Ces réseaux sont de plus en plus souvent reliés à Internet par
l'intermédiaire d'équipements d'interconnexion. Il arrive ainsi souvent que des
entreprises éprouvent le besoin de communiquer avec des filiales, des clients ou
même du personnel géographiquement éloigné via internet.
Pour autant, les données transmises sur Internet sont beaucoup plus vulnérables
que lorsqu'elles circulent sur un réseau interne à une organisation car le chemin
emprunté n'est pas défini à l'avance, ce qui signifie que les données empruntent une
infrastructure réseau publique appartenant à différents opérateurs. Ainsi il n'est pas
impossible que sur le chemin parcouru, le réseau soit écouté par un utilisateur
indiscret ou même détourné. Il n'est donc pas concevable de transmettre dans de
telles conditions des informations sensibles pour l'organisation ou l'entreprise.
La première solution pour répondre à ce besoin de communication sécurisé consiste
à relier les réseaux distants à l'aide de liaisons spécialisées. Toutefois la plupart des
entreprises ne peuvent pas se permettre de relier deux réseaux locaux distants par
une ligne spécialisée, il est parfois nécessaire d'utiliser Internet comme support de
transmission.
Un bon compromis consiste à utiliser Internet comme support de transmission en
utilisant un protocole d'"encapsulation" (en anglais tunneling, d'où l'utilisation
impropre parfois du terme "tunnelisation"), c'est-à-dire encapsulant les données à
transmettre de façon chiffrée. On parle alors de réseau privé virtuel (noté RPV ou
VPN, acronyme de Virtual Private Network) pour désigner le réseau ainsi
artificiellement créé.
Ce réseau est dit virtuel car il relie deux réseaux "physiques" (réseaux locaux) par
une liaison non fiable (Internet), et privé car seuls les ordinateurs des réseaux locaux
de part et d'autre du VPN peuvent "voir" les données.
Le système de VPN permet donc d'obtenir une liaison sécurisée à moindre coût, si
ce n'est la mise en oeuvre des équipements terminaux. En contrepartie il ne permet
pas d'assurer une qualité de service comparable à une ligne louée dans la mesure
où le réseau physique est public et donc non garanti.
Fonctionnement d'un VPN
Un réseau privé virtuel repose sur un protocole, appelé protocole de tunnelisation
(tunneling), c'est-à-dire un protocole permettant aux données passant d'une
extrémité du VPN à l'autre d'être sécurisées par des algorithmes de cryptographie.
Le terme de "tunnel" est utilisé pour symboliser le fait qu'entre l'entrée et la sortie du
VPN les données sont chiffrées (cryptées) et donc incompréhensible pour toute
personne située entre les deux extrémités du VPN, comme si les données passaient
dans un tunnel. Dans le cas d'un VPN établi entre deux machines, on appelle client
VPN l'élément permettant de chiffrer et de déchiffrer les données du côté utilisateur
(client) et serveur VPN (ou plus généralement serveur d'accès distant) l'élément
chiffrant et déchiffrant les données du côté de l'organisation.
De cette façon, lorsqu'un utilisateur nécessite d'accéder au réseau privé virtuel, sa
requête va être transmise en clair au système passerelle, qui va se connecter au
réseau distant par l'intermédiaire d'une infrastructure de réseau public, puis va
transmettre la requête de façon chiffrée. L'ordinateur distant va alors fournir les
données au serveur VPN de son réseau local qui va transmettre la réponse de façon
chiffrée. A réception sur le client VPN de l'utilisateur, les données seront déchiffrées,
puis transmises à l'utilisateur ...
2 - Présentation et architecture du SSL
2 - 1 Présentation
a) Historique :
Le SSL a été développé par Netscape.
ƒ Première version testée en interne
ƒ Version 2.0 publiée en 1994
ƒ Version actuelle 3.0
o Draft IETF publié en 1996
o En cours de standardisation à l’IETF au sein du groupe
Transport Layer Security
b) Objectifs de SSL v.3 :
ƒ Fournir des services de sécurité basés sur des moyens
cryptographiques :
o Authentification (unidirectionnelle ou bidirectionnelle)
o Confidentialité des données
o Intégrité des données
ƒ Interopérabilité
ƒ Extensibilité et efficacité
2 - 2 Architecture
ƒ
Pile TCP/IP : SSL est une couche qui se situe entre les services
applicatifs (niveau 7) et la couche transport (TCP, niveau 4).
3 - Sous protocoles
3 - 1 Présentation :
SSL est composé de deux niveaux :
ƒ
1er niveau : protocole au-dessus de TCP/IP
o Record Layer Protocol
ƒ
Niveau supérieur : 3 sous-protocoles
o Handshake Protocol
o Change Cipher Spec Protocol
o Alert Protocol
3 - 2 les sous protocoles :
- Sous protocole RECORD
ƒ
Fonction du sous protocole RECORD
o Réception des données des couches supérieures
o Traitement des paquets de données :
- Fragmentation en blocs de taille maximum 214 octets et
compression
- Calcul d’intégrité par génération d’un condensât
- Chiffrement des données
o Transmission des données au protocole TCP
- Sous protocole HANDSHAKE
ƒ
Objectifs
o Authentification du serveur
o Authentification optionnelle du client
o Négociation des algorithmes utilisés (chiffrement et
MAC (message authentication code))
o Génération de la clé symétrique de session pour le
chiffrement des données
ƒ
Notions
o Connexion
ƒ Lien logique entre un client et un serveur. Une
connexion est toujours associée à une session
o Session
ƒ Association entre un client et un serveur, créée
par le protocole Handshake. Une session définit
les paramètres de sécurité qui peuvent être
partagés entre des connexions multiples (évite
de négocier des nouveaux paramètres de
sécurité pour chaque connexion).
Principaux échanges
ƒ
Cinématique de l’ouverture d’une session SSL v.3
ƒ
ƒ
ƒ
ƒ
ƒ
Version de SSL
Nombre aléatoire : client_random
Numéro de session : session_ID
Liste des suites de chiffrement choisies par le client
Liste des méthodes de compression choisies par le client
ƒ
ƒ
ƒ
ƒ
ƒ
Version de SSL
Nombre aléatoire : client_random
Numéro de session : session_ID
Liste des suites de chiffrement choisies par le client
Liste des méthodes de compression choisies par le client
Hello client
Hello serveur
Algorithmes négociés par le protocole HANDSHAKE
ƒ Échange de clés
o RSA, Diffie -Hellman, Fortezza
ƒ Chiffrement symétrique à la volée
o RC4 (40 ou 128 bits)
ƒ Chiffrement symétrique en bloc
o DES, 3DES, RC2, IDEA, Fortezza
ƒ Fonction de hachage
o MD5, SHA-1
ƒ Variables d’état d’une session SSL
o Identificateur de session (session_ID)
o Certificat du pair (peer certificate)
o Méthode de compression (compression method)
o Suite de chiffrement (cipher spec)
o MasterSecret de 48 octets partagés entre le client et le
serveur
o Drapeau (is resumable)
o Suite de chiffrement contenant les cinq éléments suivants :
ƒ Mode de chiffrement utilisé
ƒ Algorithme de chiffrement utilisé
ƒ Algorithme de hachage utilisé
ƒ Taille du condensât
ƒ Permission d’exporter l’algorithme de chiffrement
ƒ Variables d’état d’une connexion SSL
o Deux nombres aléatoires de 32 octets
o server random
o client random
ƒ Deux clés secrètes pour le calcul des codes d’authentification
o server write MAC secret (pour les données chiffrées par le
serveur)
o client write MAC secret (pour les données chiffrées par le
client)
ƒ Deux clés pour le chiffrement symétrique
o server write key
o client write key
ƒ Vecteurs d’initialisation pour le chiffrement symétrique en mode CBC
ƒ Numéros de séquence l’un pour le serveur et l’autre pour le client
- Autres sous protocoles
ƒ
ƒ
Change Cipher Spec
o Objectifs
ƒ Signale au protocole RECORD toute modification des
paramètres de sécurité
o Moyens
ƒ Message bi-directionnel signale la transition de la
stratégie cryptographique en cours (« pending state »
devient « current state »)
Alert
o Objectifs
ƒ Signale les alertes
ƒ Alert peut être invoqué par :
– Une application, pour signaler par exemple la fin
d’une connexion.
– Le protocole Handshake suite à un problème
survenu au cours de son déroulement.
– Le protocole Record si, par exemple, l’intégrité
d’un message est mise en doute.
o Moyens
ƒ 2 octets contiennent le niveau de sévérité et la
description de l’alerte
- SSL et les certificats
ƒ
ƒ
ƒ
SSL v.3 permet l’authentification mutuelle (client et serveur).
Optionnellement, l’échange de certificat client serveur peut être réalisé.
Normes supportées : X.509 v.3, PKCS#
4 - Analyse du niveau de sécurité
Niveau de sécurité
ƒ
Niveau de sécurité décroissant en fonction des algorithmes
cryptographiques élus, lors de l’utilisation de l’algorithme RSA (source :
Netscape)
o 3-DES 168 bits / SHA-1
• Moins rapide que RC4 mais chiffrement plus puissant (3 clés)
• 3.7*1050 clés possibles
o RC4 128 bits / MD5
• Le plus rapide de tous les algorithmes de chiffrement (sauf null)
• 3.4*1038 clés possibles
o RC2 128 bits / MD5
• Plus lent que RC4
o DES 56 bits / SHA-1
• Moins résistant que les algorithmes à clés de 128 bits
• 7.2*1016 clés possibles
• SSL v.2 utilise MD5 à la place de SHA-1 pour l’authenticité des
messages
o RC4 40 bits / MD5
• 1.1*1012 clés possibles
o RC2 40 bits / MD5
o Aucun chiffrement / MD5
• Supporté uniquement par SSL v.3
ƒ
Quelques attaques sur SSL
o Craquage des secrets (cracking ciphers)
o Attaque à clair connu (clear text attack)
o Re-jeu (replay)
o Attaque de l’homme du milieu (man in the middle)
o Attaque Bleichenbancher
o Analyse du protocole SSL (D. Wagner et B. Schneiner, avril 97)
Craquage des secrets (cracking ciphers)
Cryptanalyse pour factoriser la clé publique d’un serveur et en découvrir la clé privée.
Écoute des échanges complets d’une session pour obtenir la clé de session.
Attaque à clair connu (clear text attack)
Attaques par dictionnaire sur un clair connu ou pressenti (connaissance des
messages échangés).
Attaque largement réalisable sur SSL. Ex. l’un des clairs les plus connus :
commande http « GET ».
Solution : utiliser des clés de session de taille suffisante et de bonne qualité !
Re-jeu (replay)
Réémission d’un échange autorisé et enregistrée par un pirate.
Parade SSL : mise en oeuvre de numéros de séquence (« nonce » : connection_id
du message SERVER_HELLO) calculés sur la base d’évènements aléatoires non
prédictibles, de taille 128 bits.
Attaque dite de l’homme du milieu (man in the middle)
Un pirate s’interpose entre le client et le serveur et tente d’usurper l’identité du
serveur vis-à-vis du client (cas de Dsniff).
Solutions :
-Toujours utiliser des certificats serveur signés par des autorités de certification de
confiance.
-Éduquer les utilisateurs à toujours vérifier le contenu d’un certificat (mapping entre le
nom du serveur et le certificat).
Attaque Bleichenbancher
Une session SSL peut être déchiffrée par une analyse mathématique complexe et
des envois de message d’essais en erreur :
- L’attaque nécessite environ un million de messages et n’est valable que pour une
transaction.
Elle ne peut pas être divisée en plusieurs machines pour réduire le temps. L’attaque
doit être concentrée au niveau d’un seul serveur.
La parade à cette attaque doit se faire au niveau du serveur. Par exemple Microsoft a
modifié une DLL d’IIS pour répondre à cette vulnérabilité.
Attention : permettre la compatibilité avec SSL v.2 peut être dangereux ! (Failles de
sécurité importantes)
Analyse du protocole SSL (D. Wagner et B. Schneiner, avril 97)
Record protocol
SSL dispose d’une protection correcte contre les attaques sur la confidentialité
(écoute, analyse du traffic), l’authentification (MAC) et le re-jeu.
Handshake protocol
Présente des vulnérabilités graves liées à la négociation des clés :
Effacement du message change cipher spec : le message peut être enlevé et si
l’implémentation ne l’interdit pas, la sécurité négociée n’est pas activée. Réduction
du niveau de sécurité de l’algorithme d’échange de clés : peut aboutir à la
découverte de la clé maître (peut être corrigé par implémentation).
5 - Conclusions
ƒ
ƒ
ƒ
SSL v.3 est le moyen d’implémenter des VPN le plus utilisé au monde
(VPN de niveau applicatif).
SSL v.3 bénéficie de longues expériences et d’une maturité certaine.
Les problématiques actuelles de PKI intègrent majoritairement SSL, mais
des évolutions sont nécessaires pour fournir tous les services de
sécurité.