CHAPITRE5

HTTPS

132
 HTTPS

 C’est la contraction des protocoles HTTP et

SSL
 Le protocole HTTPS permet de sécuriser le
paiement en ligne.

133
 SSL : Services

 Authentification
 Serveur (obligatoire), client (optionnel)
 Utilisation de certificat X509 V3
 A l’établissement de la session.
 Confidentialité
 Algorithme de chiffrement symétrique négocié, clé
générée à l’établissement de la session.
 Intégrité
 Fonction de hachage avec clé secrète
 Non Rejeu
 Numéro de séquence
134
SSL : Protocoles

Application

SSL
Handshake

Alert CCS

Record

TCP

135
 Handshake (1/5)

 Authentification du serveur et éventuellement

du client,
 Négociation des algorithmes de chiffrement
et de hachage, échange d’un secret,
 Génération des clés.

136
Handshake (2/5)

Message Type de Sens de Signification

message transmission
HelloRequest optionnel serveur → client Ce message demande au client d'entamer
le Handshake.
ClientHello obligatoire client → serveur Ce message contient :
le numéro de version du protocole SSL ;
le nombre aléatoire : client_random ;
l'identificateur de session : session_ID ;
la liste des suites de chiffrement choisies
par le client ;
la liste des méthodes de compression
choisies par le client.
ServerHello obligatoire serveur → client Ce message contient :
le numéro de version du protocole SSL ;
un nombre aléatoire : serveur_random ;
l'identificateur de session : session_ID ;
une suite de chiffrement ;
une méthode de compression.
 Handshake (3/5)

Certificate Optionnel serveur → client Ce message contient le certificat du

client → serveur serveur ou celui du client si le serveur le lui
réclame et que le client en possède un.
ServerKeyExchange Optionnel serveur → client Ce message n’est envoyé par le serveur
que s’il ne possède aucun certificat, ou
seulement un certificat de signature.
CertificateRequest Optionnel serveur → client Par ce message, le serveur réclame un
certificat au client.
ServerHelloDone Obligatoire serveur → client Ce message signale la fin de l’envoi des
messages ServerHello et subséquents.
 Handshake (4/5)

ClientKeyExchange Obligatoire client → serveur Ce message contient le PreMasterSecret

crypté à l’aide de la clé publique du
serveur.
CertificateVerify Optionnel client → serveur Ce message permet une vérification
explicite du certificat du client.
Finished obligatoire serveur → client Ce message signale la fin du protocole
client → serveur Handshake et le début de l’émission des
données protégées avec les nouveaux
paramètres négociés.
Handshake (5/5)

Ouverture d'une
session SSLv3
Client Serveur

Client Hello

Serveur Hello
Certificate
(Serveur Key Exchange)
(Certificate Request)
Server Hello Done

(Certificate)
Client Key Exchange
(Certificate Verify)
ChangeCipherSpec
Finished

ChangeCipherSpec
Finished
Application Data

Application Data

140
 ChangeCipherSpec (CCS)

 ChangeCipherSpec signale au Record toute

modification des paramètres de sécurité,

 Constitué d’un message (1 octet)

141
 Le protocole Record
 Reçoit les données des couches supérieures : (Handshake, Alert, CCS,
HTTP, FTP ...), et les transmet au protocole TCP.

 Après application de :
 la fragmentation des données en blocs de taille maximum de
214 octets
 la compression des données, fonction prévue mais non
supportée actuellement.
 La génération d’un condensât pour assurer le service
d’intégrité.
 le chiffrement des données pour assurer le service de
confidentialité.

142
 Le protocole Alert

 Le protocole Alert peut être invoqué :

 par l’application,
 par exemple pour signaler la fin d’une connexion
 par le protocole Handshake suite à un problème
survenu au cours de son déroulement
 par la couche Record directement,
 par exemple si l'intégrité d'un message est mise en
doute

143
Le protocole Alert (2)

Message Contexte Type

bad_certificate échec de vérification d’un certificat fatal
bad_record_mac réception d’un MAC erroné fatal
certificate_expired certificat périmé fatal
certificate_revoked certificat mis en opposition (révoqué) fatal
certificate_unknown certificat invalide pour d’autres motifs que ceux fatal
précisés précédemment
close_notify interruption volontaire de session fatal
decompression_failure les données appliquées à la fonction de fatal
décompression sont invalides (par exemple, trop
longues)
handshake_ failure impossibilité de négocier des paramètres satisfaisants fatal
illegal_parameter un paramètre échangé au cours du protocole fatal
Handshake dépasse les bornes admises ou ne
concorde pas avec les autres paramètres
no_certificate réponse négative à une requête de certificat avertissement
ou fatal
unexpected_message arrivée inopportune d’un message fatal
unsupported_certificate le certificat reçu n’est pas reconnu par le destinataire avertissement
ou fatal
 SSL : charges

 Les choix pour les calculs de la charge

cryptographique de SSL:
 algorithme de chiffrement du protocole record : DES 64 bits;
 algorithme de chiffrement asymétrique : RSA 1024 bits ;
 fonction de hachage : MD5 ;
 certificat du serveur : autorité de certification unique, déjà connue du
client (un seul certificat dans le message Certificate) ;
 taille des informations contenues, du message Certificate : 500
Koctets (notons que la taille des informations du certificat est dans la
plupart des cas inférieure) ;
 seul le serveur est certifié.

145
 Exercice 1
On s’intéresse à HTTPS
 Lors de l’authentification, le protocole utilise une clé publique contenue
dans un certificat que le serveur détient et diffuse au client à
l’établissement de la connexion. Quelles sont les services offerts par
l’utilisation d’un certificat serveur ?
 Comment l'utilisateur du navigateur peut-
il être assuré que cette clé publique
correspond bien à l'organisme auquel il souhaite accéder ?
 Pourquoi tolère-t-on l’absence d’authentification du client ?
 Décrire les faiblesses de l’authentification dans SSL.

146
 Exercice 2

On s’intéresse au protocole FTPS.

1. Quels sont les services de sécurité offerts par ce protocole ?
2. Rappeler le principe du handchake SSL .
3. L’attaque par rejeu est elle possible dans ce cas ?
pourquoi ?
SSL utilise les certificats. La vérification d’un certificat comporte
différentes étapes.
4. Quels sont les traitements à réaliser pour vérifier un
certificat ?

147
 CHAPITRE6
SÉCURISATION DES
SERVEURS DNS

148
 Gestion des noms sur arpanet

 L’ARPANET des années 80 est constitué d’une centaines

d'ordinateurs reliés en réseaux. Un unique fichier
hosts.txt rassemble les correspondances entre nom
d'hôte et adresse IP.

 Le fichier est stocké sur le SRI-NIC . Après chaque

modification, des copies sont transférées par ftp vers les
ordinateurs du réseau.

(1) Advanced Research Program Agency Network

(2) Stanford Research Institutes Network Information Center

hosts.txt file (extrait)
HOSTS.TXT
Examples of Host Table Format
NET : 10.0.0.0 : ARPANET :
NET : 128.10.0.0 : PURDUE-CS-NET :
GATEWAY : 10.0.0.77, 18.10.04 :
MIT-GW.ARPA,
MIT-GATEWAY : PDP-11 :
MOS : IP/GW, EGP :
HOST : 26.0.0.73, 10.0.0.51
SRI-NIC.ARPA, SRI-NIC, NIC :
DEC-2060 : TOPS-20 :
TCP/TELNET, TCP/SMTP
TCP/TIME, TCP/FTP
TCP/ECHO, ICMP :
HOST : 10.2.0.11 : SU-TAC.ARPA,
SU-TAC : C/30 : TAC : TCP :m
 Les inconvénients

 La taille du fichier hosts.txt augmente avec le

nombre d’hôtes

 En 1983, le réseau amorce son expansion

exponentielle.

 La fréquence des mises-à-jours des tables

devient proportionnelle au nombre de machines

 La consommation de bande passante est

proportionnelle au carré du nombre d’hôtes
 J. Postel P. Mockapetris

1983-84 Paul Mockapetris et Jon Postel

proposent et développent une solution à
base de BD distribuée Domain Name
System
152
 DNS

 Domain Name System (système de noms de domaine) est

un service permettant d'établir une correspondance entre
une adresse IP et un nom de domaine.
 Principaux composants:
 Base de données: arbre DNS and enregistrements des
ressources (Resource Records ou RR).
 Serveurs de nom: répondent aux requêtes.
 Clients: librairie logicielle, appelée resolveur, envoie des
requêtes aux serveurs de nom.

153
 L’espace des noms de domaine
• La racine s’appelle « root »
• Chaque nœud porte un
. ou root nom, c’est une zone (domaine
ou sous-domaine)

ma de tn com info net

TLD « top-level » domaines

ac
domaines ac-tunis bnf
ipeti ump domaines

Univ-oujda
crdp
sous-domaines sous-domaines
www esto mail
hôtes 154
 Résoudre un nom

Application : DNS du client

Quelle est l’adresse IP Resolver ou du FAI
de est.ump.ma ?

DNS
DNS root ou . DNS .ma
ump.ma

155
 DNS: RR (Ressource Record)

 Les nœuds de l’espace sont décrits par des

RR (record ressource) maintenus à jour sur
des serveurs autorisés : opération manuelle.

 Le rôle des serveurs de noms est de

propager ces informations en répondant aux
questions des résolveurs.

156
 DNS: RR (Ressource Record)
 La base de données DNS
 Format d’un enregistrement (RR):
 {nom} {TTL} Classe Type Valeurs
 Classe: IN (INternet) , CH (CHaosnet,)

 Types dans la classe IN

 A : Address record, @IPv4
 A6 ou AAAA : @IPv6
 NS: Name server record, serveur DNS du domaine
 CNAME: Canonical Name, (nom officiel vs alias)
 SOA: Start Of Authority record, indique le début d’une zone
 PTR: PoinTeR record, pour les resolution inverse
 MX: Mail eXchanger record, indique les machines ayant en charge la réception du mail
dans le domaine
 RR SOA: désigne le début obligé et unique d’une zone.

isetcom.tn. IN SOA isetcom.tn. admin.isetcom.tn. (

2003110301 ; Serial
10800 ; Refresh (3h)
3600 ; Retry (1H)
3600000 ; Expire (5w6d16h)
6400 ) ; Minimum ttl (1D)

Contact
Zone [email protected]

Pour la cohérence
des bases
Pour la m.à.j

 RR NS: permet de déclarer les serveurs DNS du domaine (primaire et secondaires)

{name} {ttl} addr−class NS Name servers name

IN NS master.isetcom.tn.
IN NS slave1.isetcom.tn.
IN NS slave2.isetcom.tn.

158
  RR A: Associe un nom à une ou plusieurs @IP, c’est le RR le plus fréquent

Serv-ftp IN A 172.172.17.3
IN A 172.172.17.12
IN A 172.172.17.26

 RR PTR: associe une @IP à un nom, pour la résolution inverse

3 IN PTR serv-ftp.isetcom.tn
12 IN PTR serv-ftp.isetcom.tn
26 IN PTR serv-ftp.isetcom.tn

 RR CNAME: permet d’associer le nom officiel avec des alias

www.isetcom.news.tn IN CNAME serv-web2.isetcom.tn

 RR MX: Donne la liste des machines ayant en charge la réception des mails dans le domaine

isetcom.tn IN MX 10 smtp.isetcom.tn
isetcom.tn IN MX 20 mailhost.isetcom.tn

159
Vulnérabilités du serveur DNS
 Attaques du DNS

 Empoisonnement de la cache
 DNS A reçoit une requête pour laquelle il n’a pas
de réponse, alors il demande à DNS B.
 DNS B répond avec des informations erronées.
 DNS A accepte la réponse de DNS B sans aucune
autre vérification et enregistre des données
erronées dans sa cache.
Attaques du DNS
 Attaques du DNS

 Empoisonnement de la cache du DNS Cache

 Provoque des DoS:
 Un serveur DNS récursif se termine avec une auto
référence de sa cache. Exemple:
foobar.xyz.org. IN CNAME foobar.xyz.org.
 Un attaquant peut planter le DNS après injection de la
RR suivante dans sa cache en demandant un transfert
de zone à foobar.xyz.org
 Attaques du DNS

 Flooding du Client :
 Le client envoie une requête DNS.
 L’attaquant envoie des milliers de réponses
apparaissant comme venant du serveur DNS..
 Le client accepte ces réponses car il n’a pas de
moyen pour vérifier leur origine.
 Attaques du DNS

 Vulnérabilités du DNS Dynamic Update :

 C’est une forme de contrôle d’accès.
 Des protocoles tels que DHCP utilisent le DNS
Dynamic Update protocol pour ajouter et
supprimer des RRs.
 Un attaquant (utilisant l’IP spoofing d’un serveur
de confiance) peut lancer une attaque de DoS en
supprimant RRs, ou effectuer des redirections
malicieuses en changeant l’IP d’un RR lors de la
mise à jour.
 Attaques du DNS

 Information Leakage: (fuite d’informations)

 Les transferts entre zones peuvent entrainer une fuite
d’informations sur les réseaux internes..
 Ou un attaquant peut tester chaque adresse IP afin de
connaitre les adresses qui ne sont pas assignées.
 Si le sytème a confiance dans le réseau IP entier, au lieu
de spécifier chaque hôte auquel il a confiance, alors le
système peut être vulnérable à une attaque utilisant des
adresses IP non assignées.
 spoofing

 ID Spoofing du DNS
 La machine X a besoin de connaitre l’IP d’une machine Y
 X assigne un identificateur aléatoire (16 bits) à la requête
qu’il envoie au DNS et attend que ce nombre soit présent
dans la réponse du DNS.
 Un attaquant utilisant un sniffer intercepte la requête du
DNS et envoie une réponse à X contenant l’identificateur
correct mais avec un IP de son choix.
spoofing
 Solution: DNSSEC

 DNSSEC: Domain Name System SECurity

Extensions
 Services:
 Distribution de clés.
 Authentification de l’origine des données
 Authentification des transactions et des requêtes.

169
 RRs et RRsets

 Resource Record:
 name TTL class type rdata
www.ripe.net. 7200 IN A 192.168.10.3

 RRset: RRs avec le même nom, classe et type:

www.ripe.net. 7200 IN A 192.168.10.3
A 10.0.0.3
A 172.25.215.2

 RRsets sont signés pas les RRs individuellement.

 DNSSEC

 Introduit deux nouveaux types de RR :

 KEY: utilisé pour stoker une clé publique associée à un
nom de DNS. Elle peut être une clé d’une zone, d’un
utilisateur, d’un hôte,…
 SIG: lie le RRSet qui va être signé au signataire et à un
intervalle de validité.
 NXT: Répond à la non-existence d’un nom d’une manière
sûre.
 DNSSEC
 Fonctionnement:
 RRSets contient zéro ou plus RRs ayant le même nom de
DNS, classe et type mais de données différentes.
 Chaque RRSet possède un SIG RR associé qui est une
signature numérique du RRset utilisant la clé privée de la
zone.
 Si un résolveur apprend de manière fiable une clé publiqe
d’une zone, il peut authentifier des données signées lues
à partir de cette zone.
 Un serveur va tenter de renvoyer, avec des RRs
retrouvés, les SIGs correpondants.
 DNSSEC

 Obtenir la clé publique d’une zone:

 En la lisant à partir du DNS ou en la configurant
de manière statique.
 Pour la récupérer de manière sécurisée à partir
du DNS, la clé elle même doit être signée avec
une clé dans laquelle le résolveur a confiance.
 Le résolveur doit être configuré avec au moins
une clé publique authentifiant une zone (comme
départ). À partir de là, il pourra lire les clés
publiques d’autres zones.
 DNSSEC

Authentification des transactions et des

requêtes:
Ceci est accompli en ajoutant un enregistrement
spécial de ressource SIG à la fin de la réponse ce qui
signe de manière numérique la concaténation de la
réponse du serveur et la requête du résolveur.
 Vérification de l’arbre

Question: www.cnn.com

www.cnn.com A ? . (root)
dns.cs.umass.edu
lab.cs.umass.edu
Demander au serveur .com
www.cnn.com A ?
SIG(l’adresse IP et PK du serveur .com )
résolveur Serveur par sa clé privée
xxx.xxx.xxx.xxx récursif www.cnn.com A ?
.com
Signatures Demander au serveur cnn.com
des
SIG(l’adresse IP et PK du serveur .com )
transactions
par sa clé privée

add to cache
www.cnn.com A ?
slave servers
SIG(xxx.xxx.xxx.xxx)
Par sa clé privée Signatures de
la transaction

www.cnn.com cnn.com
 Chaine de confiance DNSSEC
La clé publique du domaine
racine est source de confiance
Serveur de nom racine de
pour tous les serveurs de noms
l’arbre DNS
!

it. com.
Serveur de nom

Serveur de nom local host.foo.com. ? foo.com.

Serveur de nom
polito.it.

Il reçoit RRs: A, SIG, KEY host.foo.com.

131.195.21.25
176
 Transaction de sécurité DNS

 Transaction Signature (TSIG) est une autre extension de

sécurité utilisant les clés symétriques
 Sécurise la communication entre le serveur des noms et le
résolveur.
 TSIG authentifie les requêtes et les réponses DNS
 TKEY est une meta RR contenant une clé secrète
 TSIG, TKEY – n’est pas stokée ni dans les fichiers ni
dans la cahce.
 PROBLEME: stockage d’une clé secrète!

177
 DNS comme PKI

 Un DNS avec ces extensions de sécurité peut devenir une

première implémentation d’une PKI mondiale.
 La “chaine de confiance” de DNSSEC “chain of trust” est
un modèle de certification.

178
 Exercice (1/2)
Vous souhaitez vous connecter à votre compte bancaire en passant par le
site Internet de votre banque.
1. Schématiser les différentes étapes vous permettant de vous connecter
au site de votre banque.
2. Donner la principale vulnérabilité du DNS.
3. Expliquer le RRset suivant :
www.mabanque.tn 7200 IN A 192.168.10.3
A 182.123.10.3
A 172.25.215.2
4. Proposez une attaque de type « DNS cache poisoning » dans ce
scénario.

179
 Exercice (2/2)
5. Proposez une solution à l’attaque « DNS cache poisoning ».
6. Une des solutions proposées afin de sécuriser DNS est DNSSEC.
Expliquer son principe.
7. Changer le RRset de la question 3 afin d’appliquer les solutions de
sécurité offertes par DNSSEC.
8. Transaction Signature (TSIG) est une autre extension de sécurité
utilisant les clés symétriques.
 Expliquer son fonctionnement.
 Donner les principales attaques qui peuvent être résolues par TSIG.
 Donner deux inconvénients de cette extension.

180