Table des matières

1 Contexte du projet 11
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Travail à faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 Critères d’acceptabilité . . . . . . . . . . . . . . . . . . . 12
1.4.2 Acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.3 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . 13
1.4.4 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . 13
1.4.5 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Organisation du rapport . . . . . . . . . . . . . . . . . . . . . . . 13

2 Etat de l’art 14
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Protocoles SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Historique SSL/TLS . . . . . . . . . . . . . . . . . . . . . 15
2.2.2.1 Historique du protocole SSL . . . . . . . . . . . 15
2.2.2.2 Historique du protocole TLS . . . . . . . . . . . 15
2.2.3 SSL/TLS Handshake . . . . . . . . . . . . . . . . . . . . 16
2.3 Configuration du HTTPS sous Apache 2 . . . . . . . . . . . . . . 19
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Audit SSL/TLS 20
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Audit SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Étude des outils similaires . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Étude des outils scan client . . . . . . . . . . . . . . . . . 21
3.3.2 Étude des outils scan serveur . . . . . . . . . . . . . . . . 22
3.3.3 Étude des outils scan client/seveur . . . . . . . . . . . . . 23
3.4 Choix de la solution . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1
4 Solution proposée 25
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Présentation de la solution proposée . . . . . . . . . . . . . . . . 25
4.2.1 Scan côté Serveur . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1.1 SSLyze . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1.2 Amélioration du Projet SSLyze . . . . . . . . . . 26
4.2.2 Scan côté client . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2.1 Configuration du module SSLhaf . . . . . . . . . 28
4.2.2.2 Le contenu log par défaut . . . . . . . . . . . . . 29
4.3 Solution Complète AliveSSL . . . . . . . . . . . . . . . . . . . . . 29
4.3.1 AliveSSL scan Client . . . . . . . . . . . . . . . . . . . . 30
4.3.2 AliveSSL scan Server . . . . . . . . . . . . . . . . . . . . 31
4.3.3 Choix du type de serveur . . . . . . . . . . . . . . . . . . 31
4.3.3.1 Serveur web . . . . . . . . . . . . . . . . . . . . 31
4.3.3.2 Serveur FTP . . . . . . . . . . . . . . . . . . . . 32
4.3.3.3 Serveur SMTP . . . . . . . . . . . . . . . . . . . 32
4.3.3.4 Serveur POP3 . . . . . . . . . . . . . . . . . . . 32
4.3.3.5 Serveur LDAP . . . . . . . . . . . . . . . . . . . 33
4.3.3.6 Choix du type du scan . . . . . . . . . . . . . . 33
4.3.3.7 Résultat du scan . . . . . . . . . . . . . . . . . . 35
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5 Bonnes pratiques 36
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.1 Utilisation des clés privées de 2048-bit . . . . . . . . . . . 36
5.2.2 Protection des clés privées . . . . . . . . . . . . . . . . . . 37
5.2.3 Assurance d’ une couverture suffisante du nom d’hôte . . 37
5.2.4 Obtension des certificats d’une autorité de certification
fiable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.5 Utilisation des algorithmes de signature de certificat solide 39
5.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 Utilisation des chaînes de certificats complètes . . . . . . 39
5.3.2 Utilisation des protocoles sécurisés . . . . . . . . . . . . . 39
5.3.3 Utilisation des suites de chiffrements sécurisées . . . . . . 40
5.3.4 Sélection des meilleures suites de chiffrement . . . . . . . 42
5.3.5 Confidentialité persistante . . . . . . . . . . . . . . . . . . 42
5.3.6 Utilisation d’échange des clés fortes . . . . . . . . . . . . . 42
5.3.7 Atténuation des problèmes connus . . . . . . . . . . . . . 43
5.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.1 Évitement de trop de sécurité . . . . . . . . . . . . . . . . 43
5.4.2 Reprise de session d’utilisation . . . . . . . . . . . . . . . 43
5.4.3 Utilisation de l’optimisation WAN et HTTP/2 . . . . . . 44
5.4.4 Cache du contenu public . . . . . . . . . . . . . . . . . . . 44
5.4.5 Utilisation d’agglomération OCSP . . . . . . . . . . . . . 44
5.4.6 Utilisation des primitives cryptographiques rapides . . . 44

2
5.5 Protocole HTTP et la sécurité des applications . . . . . . . . . . 45
5.5.1 Chiffrement de tout . . . . . . . . . . . . . . . . . . . . . 45
5.5.2 Élimination de contenu mixte . . . . . . . . . . . . . . . . 45
5.5.3 Confiance des tiers . . . . . . . . . . . . . . . . . . . . . 45
5.5.4 Sécurisation des cookies . . . . . . . . . . . . . . . . . . . 46
5.5.5 Compression de HTTP sécurisée . . . . . . . . . . . . . . 46
5.5.6 Déploiement de HTTP Strict Transport Security . . . . . 46
5.5.7 Déploiement de la politique de sécurité du contenu . . . . 47
5.5.8 Mise en cache du contenu sensible . . . . . . . . . . . . . 47
5.5.9 Considération d’autres menaces . . . . . . . . . . . . . . . 47
5.6 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3
Table des figures

1 Répartition du traffic chiffré par service . . . . . . . . . . . . . . 9

2 Illustration HTTP vs HTTPS . . . . . . . . . . . . . . . . . . . . 10

2.1 Évolution du protocole SSL/TLS à travers le temps . . . . . . . 16

2.2 Séquence simplifiée du handshake SSL/TLS entre le client et le
serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Capture avec l’outil Wireshark du message Client Hello envoyé
par Firefox présentant les 20 suites cryptographiques présentés
par le navigateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Exemple d’alerte qu’un client SSL/TLS peur retourner en cas de
problème dans la négociation. . . . . . . . . . . . . . . . . . . . . 18

3.1 Test How’s MySSL . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Test DCsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Test Wormly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Test SSLabs Server . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Test SSLabs Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Les autorités de certification ajoutées . . . . . . . . . . . . . . . . 27

4.2 Scan client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Page d’accueil du service AliveSSL . . . . . . . . . . . . . . . . . 29
4.4 AliveSSL scan client . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Les protocoles supportés du log . . . . . . . . . . . . . . . . . . . 30
4.6 Les protocoles utilisés . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7 Choix du type de serveur . . . . . . . . . . . . . . . . . . . . . . 31
4.8 Description de FTP . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.9 Fonctionnement de SMTP . . . . . . . . . . . . . . . . . . . . . . 32
4.10 Fontionnement de POP3 . . . . . . . . . . . . . . . . . . . . . . . 33
4.11 Fonctionnement de LDAP . . . . . . . . . . . . . . . . . . . . . . 33
4.12 Scan régulier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.13 Scan spécifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.14 Résultat du scan . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4
Remerciements

C’est parce que nous avons beaucoup estimé tous ceux qui nous ont écou-
tés, conseillés, critiqués et encadrés qu’on tient à leur faire part de toute notre
gratitude et on tient à les remercier à travers ces lignes.
Nous adressons tout d’abord nos plus sincères remerciements à Monsieur
Nizar Ben Neji notre encadrant pédagogique, pour les encouragements, pour le
temps qu’il nous a consacré et pour ses riches conseils.
Nos remerciements s’adressent aussi à Monsieur Hamdi Mohamed pour nous
avoir accueilli au sein du centre d’incubation du Pôle El Ghazala ainsi que pour
son soutien et ses conseils qui ont toujours constitué une aide précieuse.
On tient à remercier de tout coeur nos parents qui nous ont toujours soutenu
et encourager dans cette aventure et dans tout notre parcours universitaire.
J’adresse mes sincères remerciements à tous les professeurs de notre dépar-
tement informatique et toutes les personnes qui ont contribué de près ou de loin
par leurs paroles, leurs écrits, leurs conseils et leurs critiques tout au long du
stage. Enfin, on tient à témoigner toute notre gratitude à Monsieur Mohamed
Oueld El Hassan, notre coordinateur pour ses visites fréquentes à l’organisme
de stage et pour son support inestimable.
Un grand merci aussi à tous nos ami(e)s pour leur sincère amitié et confiance.
Finalement merci aux collègues de bureau pour les discussions constructives
que nous avons eu et pour leur bonne humeur.

5
6
Acronymes et abréviations

ADH Anonymous Diffie-Hellman

AEAD Authenticated Encryption with Associated Data
AES Advanced Encryption Standard
BEAST Browser Exploit Against SSL/TLS
CA Certification Authority
CBC Cipher Block Chaining
CPU Central Processing Unit
CRL Certificate Revocation List
CSP Content Security Policy
DROWN Decrypting RSA with Obsolete and Weakened eNcryption
ECDHE Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
EV Extended Validation
FTP File Transfer Protocol
HSM Hardware Security Modules
HSTS HTTP Strict Transport Security
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IETF Internet Engineering Task Force
LDAP Lightweight Directory Access Protocol
MITM Man In The Middle
OCSP Online Certificate Status Protocol
PCI DSS Payment Card Industry Data Security Standard
PODDLE Padding Oracle On Downgraded Legacy Encryption
POP3 Post Office ProtocolSHA1
RC4 Rivest Cipher 4
RFC Request For Comments
SHA1 Secure Hash Algorithm
SMTP Simple Mail Transfer Protocol
SSL Secure Sockets Layer
SRI Subresource Integrity
TCP Transmission Control Protocol
TIC Technologies de l’information et de la communication
TLS Transport Layer Security
UDP User Datagram Protocol
VPN Virtual Private Network
WAN Wide Area Network 7
XSS Cross-site Scripting
Avant-propos

Notre projet rentre dans le cadre de l’obtention du diplôme de fin d’études

de la licence appliquée en Réseaux Informatique, spécialité Technologies de l’In-
formation et de la Télécommunication au sein de la Faculté des Sciences de
Bizerte (FSB). À la recherche d’un sujet, Monsieur Nizar Ben Neji nous a pro-
posé l’idée de réaliser un outil d’audit et d’évaluation des serveurs SSL/TLS
Web, Messagerie et Annuaire LDAP. L’outil va permettre aux auditeur de la
sécurité d’évaluer les solutions Client et Serveur SSL/TLS pour l’élaboration
d’un rapport détaillé sur les suites de chiffrement utilisées et les vulnérabilités
de chaque protocole supporté.
Ce projet nous a permis d’appliquer nos connaissances théoriques et pra-
tiques dans un cadre de projet professionnel. Il était aussi une opportunité pour
découvrir le monde professionnel, ses exigences et ses besoins en termes de com-
pétences.

8
Introduction générale

La sécurité informatique continue de progresser, évoluant d’une approche

passive, ponctuelle et basée sur produit à une approche active de bout en bout
envers la reconnaissance et la relation contenant-contenu. De nos jours, les four-
nisseurs de services lutent ardement afin de garantir la sécurité de leurs clients
et intégrent des mécanismes variés de sécurité dans le cadre de leurs offres de
service. Mais les menaces de sécurité sont en constante évolution, c’est pour
cette raison que les entreprises doivent se doter des moyens adéquats pour sé-
curiser leurs services en ligne et protéger en continue leur clientéle. L’utilisation
du cryptage, notamment le protocole SSL/TLS, améliorera considérablement la
sécurité des services en ligne dans son ensemble. La mise en place du SSL/TLS
garantira aux internautes :
— La confidentialité des données envoyées en ligne par le chiffrement (qui
peuvent inclure des numéros de carte de crédit et d’autres informations
financières et personelles comme les noms et les adresses.
— L’identité des sites au niveau desquels ces données vont être déposées par
l’usage des certificats électroniques

Figure 1 – Répartition du traffic chiffré par service

9
SSL/TLS est un protocole qui opére à l’interface des sockets TCP. En consé-
quence, tous les protocoles de la couche application comme HTTP, FTP, TEL-
NET, LDAP, SMTP et autres peuvent être protégés par un canal de transmission
sécurisé. Pour le cas du HTTP ou du Web, le nombre des sites web sécurisés
par SSL/TLS a augmenté au cours des dernières années. Des données récentes
venant de Google montre que plus de 10% du trafic web est désormais chiffré par
SSL/TLS et 50% du traffic chiffé est généré par les services de Google (Figure
1). En Tunisie, la plus part des sites sont soit non sécurisés par SSL/TLS soit
présentants des problèmes de configuration.
Dans le cadre de notre projet, on va ainsi réaliser un outil pour scanner les
serveurs et les clients TLS. Il permet d’élaborer un rapport détaillé sur les pro-
tocoles supportés, les suites de chiffrement utilisées, les éventuels vulnérabilités
ainsi que les insufisances de sécurité relatifs à SSL/TLS.
Dans ce manuscrit, le chapitre 1 présente le contexte du projet, la probléma-
tique, l’organisme d’accueil ainsi que la spécification détaillée. Dans le chapitre
2, on va présenter les protocoles SSL et TLS et leurs versions. Le chapitre 3
détaille et explique l’opération audit SSL/TLS ainsi que les outils actuellement
utilisés. Dans le chapitre 4, on présente lle choix technologique ainsi que la solu-
tion proposée. Finalement, le chapitre 5 inclut une liste de recommandations et
bonnes pratiques qui va aider administrateurs des sites et experts de la sécurité
à mieux configurer leurs serveurs.

(a) Fonctionnement de HTTP

(b) Fonctionnement de HTTPS

Figure 2 – Illustration HTTP vs HTTPS

10
Chapitre 1

Contexte du projet

1.1 Introduction
Dans ce chapitre, nous exposons le contexte général du projet. On présente
premièrement l’organisme d’accueil, la problématique, le travail demandé et la
méthodologie adoptée.

1.2 Organisme d’accueil

Notre projet a été réalisé au Centre d’Innovation du Pôle Technologique El
Ghazela, qui est un incubateur d’entreprises et une structure d’accompagnement
de projets de création de start-ups. Le centre d’innovation est situé au pôle
technologique El Ghazela faisant partie des 10 technopôles spécialisés dans des
secteurs d’activités différents.
Le centre d’innovation a démarré en Janvier 2016 avec une dizaine de pro-
jets qui ont été sélectionnés en adéquation avec la politique du centre et les
thématiques prioritaires. Plusieurs équipes travaillent actuellement au niveau
du centre d’innovation et parmi eux des étudiants en stage de PFE venant de
divers établissements. Ces équipes travaillent actuellement sur la mise en place
de prototypes. Elles ont bénéficié d’un encadrement dans divers aspects tel que
la gestion de projet, l’élaboration d’un business plan, le processus d’innovation,
le marketing, le commercial, la propriété industrielle et la veille technologique.
Ce centre a pour objectifs de :
— Identifier les bons projets pour aider à la création d’entreprises innova-
trices
— Favoriser l’émergence d’une nouvelle génération de créateurs et former
des entrepreneurs afin de transformer des techniciens porteurs de projet
en chefs d’entreprise
— Contribuer à la consolidation du tissu industriel dans le cadre des TIC
et minimiser les facteurs d’échec de la création d’entreprises

11
1.3 Problématique
De nos jours, les entreprises offrent la possibilité à leurs clients de réaliser
des opérations financières et économiques à distance sans devoir se présenter
en personne. Si l’expérience a montré que cela était avantageux et même très
actractif, cela présente aussi un danger hyper réel lorsque la sécurité n’est pas
au rendez-vous. Pour s’assurer de la sécurité des services en ligne, un ensemble
d’outils d’audit peuvent être utilsé pour identifier les éventuels vulnérabilités.
La plupart des outils existants sont des scanners de vulnérabilités applicatifs
qui ne font pas l’inspection des configurations côté serveur et plus précisement
la configuration SSL/TLS. Même les outils existants ne font pas toutes les tests
nécessaires pour décrotiquer les problèmes liés à ce protocole. Ils focalisent uni-
quement sur la partie serveur ignorant les vulnérabilités relatives à la partie
cliente et ils traitent uniquement le cas du Web et négligent les autres appli-
cations du SSL/TLS comme la messagerie, les annuaires LDAP, le transfert de
fichier et les autres services.

1.4 Travail à faire

Pour résoudre les problèmes suscités, nous allons développer un service web
pour l’audit SSL/TLS des solutions serveur et cliente de déterminer les éventuels
vulnérabilités relatives aux protocoles et aux suites de chiffrement utilisées et
de générer un rapport détaillé sur les problèmes rencontrés. Au niveau de ce
projet, nous présentons aussi les recommendations et les bonnes relatives à la
configuration du SSL/TLS côté client et serveur. Le service qui va être développé
est destiné aux auditeurs et aux administrateurs de la sécurité et aux utilisateurs
voulant évaluer leurs client SSL/TLS.

1.4.1 Critères d’acceptabilité

Le travail qui sera effectué au niveau de ce projet sera validé sur la base des
besoins exprimés au niveau du cahier des charges. Notre travail ne sera validé
que s’il :
— Permet de faire une bonne vérification sur la configuration SSL/TLS côté
serveur et côté client (la chaine de certification, les protocoles supportés,
l’efficacité du chiffrement et l’échange des clés)
— Fournit un ensemble de recommandations et de bonnes pratiques pour
les auditeurs de sécurité

1.4.2 Acteurs
Les auditeurs, les administrateurs de la sécurité et les utilisateurs du Web
seront les acteurs du service d’audit SSL/TLS.

12
1.4.3 Besoins fonctionnels
Les besoins fonctionnels de la solution sont :
— Scanner les configurations SSL/TLS des serveurs SMTP, FTP, POP,
IMAP, LDAP et les autres
— Scannet les solutions SSL/TLS clientes comme les navigateurs (IE, Chrome,
Firefox, Opera, ...), les clients de messageries (MS Outlook, Mozzila
Thunderbird, ...), les clients LDAP et les autres
— Elaborer un rapport sur les eventuels vulnérabilités et insufisance de
sécurité
— Présenter un ensemble de recommandations et de bonnes pratiques concer-
nant la sécurité par le protocole SSL/TLS

1.4.4 Besoins non fonctionnels

La solution développé assure les besoins non fonctionnels suivant :
— La performance et la fiabilité : le service Web doit fonctionner dans les
meilleures conditions. Pour ce but, il faut bien gérer les erreurs et les
exceptions et gérer la montée en charge en cas de plusieurs connexions
simultanées.
— L’ergonomie : l’application web doit disposer d’une certaine clarté et
d’une simplicité d’utilisation.
— La portabilité : l’application Web doit fonctionner sur divers environne-
ments et faire l’inspection de divers solutions clientes et serveur.
— L’extensibilité : l’application doit être extensible et facile à maintenir
pour répondre à des futurs besoins

1.4.5 Contraintes
La solution doit être à faible coût et développé avec des solutions opensource.
Le produit final doit être remis à la société au plutard le 31 Mai 2017.

1.5 Organisation du rapport

Notre rapport est formé de cinq chapitres. Le chapitre 2 détaille le protocole
SSL/TLS et la démarche détaillée pour sa mise en place côté serveur. Dans le
chapitre 3, nous présentons l’importance de l’audit SSL/TLS ainsi que l’étude
comparative des outils existants. Le chapitre 4 présente en détails la solution
proposée. Nous fournissons dans le chapitre 5 un ensemble de recommandations
et de bonnes pratiques pour aider les acteurs à accomplir convenablement la
tâche de sécurisation SSL/TLS. Nous concluons le rapport par les objectifs
atteints et les possibles améliorations futures.

13
Chapitre 2

Etat de l’art

2.1 Introduction
De nos jours, la sécurité présente un rôle très important dans le domaine
des réseaux et des télécommunications. Les clients de la commerce électronique
n’ont pas la confiance suffisante pour payer par carte bancaire. Pour sécuriser
ce paiement, il faut utiliser des protocoles d’authentification et de chiffrement
comme SSL/TLS. Avec ces protocoles, les données personnelles des clients (nu-
méro de carte bancaire, mot de passe, etc) seront protégées et personne ne peut
les intercepter.
Dans ce chapitre, on va présenter en détail le protocole SSL/TLS, ses dif-
férents versions, les failles et les vulnérabilités reconnues pour chaque version
ainsi que la mise en oeuvre de ce dernier du côté serveur.

2.2 Protocoles SSL/TLS

2.2.1 Définition
Les protocoles SSL (Secure Sockets Layer) et TLS (Transport Layer Secu-
rity) sont deux protocoles cryptographiques de sécurité permettant l’authenti-
fication et le chiffrement des données entre deux entités client et serveur. Le
TLS est le successeur de SSL, ces deux derniers fonctionnent suivant un mode
client/serveur satisfaisant les objectis suivants :
— l’authentication du serveur ainsi que des clients : authentification SSL/TLS
simple et mutuelle
— la confidentialité des données échangées par le chiffrement hybride des
communications
— l’intégrité des données échangées
SSL/TLS a été initialement conçu par Netscape et actuellement il est une norme
officielle standardisé par l’IETF. Le protocole SSL/TLS est un protocole de sécu-
rité qui crée un canal sécurisé entre deux machines communicantes sur Internet.

14
Il est utilisé pour sécuriser l’authentification et les transactions électroniques.
Les deux protocoles SSL et TLS fonctionnent entre la couche transport (TCP
ou UDP) et la couche applicative pour sécuriser les protocoles nativement peu
sûrs. Il est le protocole de sécurité le plus utilisé aujourd’hui sur le Internet. Il
permet de sécuriser plusieurs applications et services réseau tels que le transfert
de fichiers par FTP, les connexions VPN, la messagerie instantanée et la voix
sur IP.
Le protocole SSL/TLS est constitué de deux composants : le TLS Record et
le TLS Handshake. Le TLS Record a pour but de chiffrer des connexions avec
un algorithme symétrique et le TLS Handshake a pour but d’authenfier les deux
parties communicantes, de leur permettre de négocier les algorithmes ainsi que
le protocole. Le protocole inclut la vérification des certificats électroniques du
client et du serveur pour s’assurer des identités des entités communicantes.

2.2.2 Historique SSL/TLS

Le protocole SSL/TLS est né 1994 et a été créé par Netscape. Il a évolué
avec le temps vu les nouvelles exigences technologiques et vu les vulnérabilités
detectées comme BEAST, PODDLE et DROWN (Voir Figure 2.1).

2.2.2.1 Historique du protocole SSL

Au début, Netscape a développé la version SSL 1.0 qui est restée théorique et
n’a été jamais mise en oeuvre. Les versions qui ont été implémentées et largement
utilisées sont :
— SSL 2.0 est la version intiale qui a été développée en 1995. Elle pré-
sente des problèmes au niveau de la sécurité et a été déconseillée depuis
longtemps.
— Netscape a développé l’année suivante SSL 3.0 pour remplacer SSL 2.0
qui présentait plusieurs vulnérabilités comme DROWN et autres. Cette
version est restée active et très utilisée pendant une bonne période. Une
équipe de recherche de Google a identifié une faille nommée PODDLE
dans la conception de cette version qui permet de déchiffrer le contenu
des informations échangées entre le navigateur Web de la victime et le
serveur sécurisé avec l’attaque Man in the Middle. A cause de POODLE,
la majorité des navigateurs ont définitivement désactivé SSL 3.0 vers la
fin de 2014.

2.2.2.2 Historique du protocole TLS

— TLS 1.0 a été développée en 1999. L’évolution de SSL a donné le proto-
cole TLS qui a été confié par l’IETF. TLS 1.0 n’était qu’une légère évo-
lution de SSL 3.0 qui présente une partie de l’établissement de la liaison
(handshake) et apporte de la flexibilité avec l’introduction d’extensions
optionnelles qui permettent de faire évoluer le protocole sans revoir ses

15
 bases. Sa majeure faiblesse c’est l’attaque BEAST qui est basée sur Ja-
vaScript, elle permet à un attaquant sur un même réseau d’intercepter
et de déchiffrer des cookies SSL via une attaque sur des paquets cryptés.
Cette version est également incapable d’utiliser des suites de chiffrement
modernes qui offrent une plus grande sécurité et efficacité. Suite à ces
faiblesses, cette version a été échangée par une nouvelle plus sûr.
— TLS 1.1 a été développée en 2006, est la deuxième version la plus récente
de TLS, c’est une version de transition qui consolide certaines RFC in-
termédiaires et inclut une modification de l’initialisation des blocs CBC
(suite à un signalement fait en 2011). Cependant, l’environnement de
sécurité moderne a poussé vers TLS 1.2.
— TLS 1.2 est la dernière version de TLS. Cette version permet d’accéder
à des suites de chiffrement avancées qui prennent en charge la crypto-
graphie de courbe elliptique (efficacité pour un échange d’informations
sur un canal non sécurisé). Il apporte une évolution importante qui se
présente dans les modes de chiffrement authentifié de bloc AEAD.

Figure 2.1 – Évolution du protocole SSL/TLS à travers le temps

2.2.3 SSL/TLS Handshake

La partie Handshake du TLS est responsable de l’authentification et de
l’échange des clés nécessaires pour établir une session sécurisée (Voir Figure
2.2). Lors de l’établissement d’une session sécurisée, le protocole Handshake
gère ce qui suit :
— Négociation de la suite de chiffrement : Le client et le serveur entrent en
contact et choisissent la suite de chiffrement qui sera utilisée tout au long
de leur échange de messages.
— Authentification du serveur : le serveur prouve son identité au client
grâce à son certificat électronique. Le client peut également avoir besoin
de prouver son identité pour le serveur si nécessaire. L’utilisation de
paires de clés publiques/privées, est la base de cette authentification. La
méthode exacte utilisée pour l’authentification est déterminée selon la

16
 suite de chiffrement négociée.
— Elaboration et échange d’une clé de session entre le client et le serveur : En
premier, les parties communicantes se mettent d’accord sur l’algorithme
de chiffrement symétrique qui sera utilisé et en second lieu, le client
SSL/TLS générent la clé de session symétrique en se basant sur le choix
effectué.
Ce protocol a pour objectif de permettre au serveur et au client de s’authen-
tifier l’un à l’autre puis de négocier un algorithme de chiffrement et une clé
cryptographique avant que l’application ne transmette.
Comme montre la Figure 2.2, un premier message ClientHello est envoyé par
le client au serveur pour initier la communication. Dans ce message, le client
propose un ensemble de suites cryptographiques qu’il est capable de mettre en
oeuvre (Voir Figure 2.3). Chacune de ces suites cryptographiques décrivent les
mécanismes cryptographiques qui seront utilisés pour les fonctions suivantes :
— l’échange de clés
— l’authentification du serveur .
— la protection des données applicatives, en confidentialité et en intégrité.
Ce message contient d’autres paramètres qui doivent être négociés : la ver-
sion du standard utilisée (SSLv2, SSLv3, TLS 1.0, TLS 1.1 ou TLS 1.2) et
le mécanisme de compression éventuellement qui sera appliqué sur les données
applicatives. En réponse le serveur va refuser la négociation si aucune des propo-
sitions du client n’est jugée acceptable. Le serveur met alors fin à la connexion.
Dans le cas contraire, le serveur choisit une suite de chiffrement parmi celles
proposées par le client et émet le message ServerHello qui fait état de son choix
dans lequel il présente son certificat électronique et envoie un message Serve-
rHelloDone pour indiquer qu’il attend maintenant une réponse du client.

Figure 2.2 – Séquence simplifiée du handshake SSL/TLS entre le client et le

serveur

17
 À la fin de la négociation, une fois la suite de chiffrement choisie et le cer-
tificat reçu, le client vérifie la chaîne de certification et l’état du certificat du
serveur. Si le certificat n’est pas validé, le client émet une alerte qui met fin à
la connexion (Voir Figure 2.4). Sinon, il poursuit et envoie un message, Client-
KeyExchange, contenant le pre-master secret chiffré. À partir de là, le client et
le serveur disposent tous les deux d’une clé secrète partagée et de plusieurs élé-
ments aléatoires publics échangés lors des messages ClientHello et ServerHello.
Ces éléments partagés seront utiles pour fournir les clés symétriques qui seront
utilisées pour protéger toutes les sessions : pour assurer la confidentialité et
l’intégrité des échanges. Des messages ChangeCipherSpec sont échangés pour
indiquer l’activation des paramètres (algorithmes et clés) négociés. Les mes-
sages Finished sont donc les premiers à être protégés cryptographiquement, et
contiennent un haché de l’ensemble des messages échangés pendant la négocia-
tion, afin de garantir a posteriori l’intégrité de la négociation.

Figure 2.3 – Capture avec l’outil Wireshark du message Client Hello envoyé
par Firefox présentant les 20 suites cryptographiques présentés par le navigateur

Figure 2.4 – Exemple d’alerte qu’un client SSL/TLS peur retourner en cas de
problème dans la négociation.

18
2.3 Configuration du HTTPS sous Apache 2
Dans cette partie, on va parler de la configuration du protocole HTTPS avec
Apache 2 sous Ubuntu 14.04.
1. Installation du module SSL de Apache pour que le protocole SSL puisse
fonctionner avec le serveur Apache 2 :
sudo apt-get install mod_ssl
2. Activation du module SSL de Apache 2 :
sudo a2enmod ssl
3. Après avoir activé le SSL, il faut redémarrer le serveur web pour que la
modification soit prise en compte :
sudo service apache2 restart
4. Création du certificat éléctronique en utilisant l’outil OpenSSL[https://www.openssl.org/].
Au niveau de cette étape on doit préciser le nom de domaine du site qui va
apparaitre au niveau de certificat. L’emplacement du certificat SSL et de
la clé privée du serveur seront placés dans le répertoire /etc/apache2/ssl.
sudo openssl req -x509 -nodes -days 365 -newkey rsa :2048 -keyout
/etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
5. Configuration du VirtualHost au niveau de Apache :

6. Activation de la configuration du VirtualHost :

sudo a2ensite default-ssl.conf
7. Démarrage du serveur Apache :
sudo service apache2 start
8. Test du serveur Web avec le navigateur Firefox :

2.4 Conclusion
Dans ce chapitre, on a présenté les protocoles SSL et TLS ainsi que leur
historique et les failles connues. On a mis aussi la configuration de SSL/TLS
sous Apache. La configuration du SSL/TLS seule n’est pas suffisante. C’est
pourquoi il faut se doter d’un outil pour l’évaluation de la configuration faite.
Au niveau de la partie suivante, on va expliquer et présenter l’audit SSL/TLS.

19
Chapitre 3

Audit SSL/TLS

3.1 Introduction
La sécurité informatique est liée à l’Internet impliquant souvent la sécurité du
navigateur web et aussi la sécurité du réseau. Le protocole SSL/TLS intervient
pour assurer que les communications entre deux systèmes ne tombent pas dans
de mauvaises mains et qu’elles ne puissent ni être lues, ni être manipulées.
Dans ce chapitre, on met l’accent sur l’importance de l’audit SSL/TLS suivi
par une étude sur les outils similaires existants.Et enfin, on termine ce chapitre
par une justification du choix de notre solution.

3.2 Audit SSL/TLS

Dans le domaine de la sécurité informatique, l’audit intervient pour faire des
opérations d’évaluations, de vérifications ou de contrôle. Il permet de reccueillir
des informations objectives pour déterminer dans quelles mesures les éléments
d’un système observé doivent satisfaire aux exigences d’un domaine concerné.
Dans ce cadre, on peut parler du protocole SSL/TLS qui permet l’établisse-
ment d’une connexion sécurisée, c’est lors de sa négociation que le client et
le serveur choisissent des systèmes connues(protocoles, suites de chiffrements).
Lors de cette négociation, il faut s’assurer de l’identité de l’entité avec laquelle
une machine communique. Il faut être sûr que le client communique avec le
serveur qu’il prétend être. Dans ce cas, le certificat SSL intervient, c’est une
sorte de preuve d’identité d’un site web, est aussi un fichier de données qui lie
une clé cryptographique aux informations d’un individu. Ce dernier est installé
sur un serveur afin d’assurer une connexion sécurisée entre le serveur web et le
navigateur.
L’utilisation des certificats SSL/TLS se généralise pour :
— L’accès à des sites sécurisés.
— Les applications bancaires.
— Les réponses aux appels d’offres du marché publique.

20
Les certificats SSL sont délivrés et signés par un tiers de confiance (autorité
de certification) pour assurer le lien entre deux entités communicantes. Pour
un site Web, il faut adopter un certificat SSL pour la sécurité des visiteurs du
site web (exemple le cas d’un site e-commerce). La configuration de ce type de
certificat n’était pas toujours acceptable, c’est pour cette raison il faut utiliser
des outils qui la permettent.

3.3 Étude des outils similaires

Étant donné que l’utilisation du protocole SSL/TLS permet d’avoir des com-
munications cryptées ce qui permet d’éviter que les données soient interceptées.
Nombreux sont les outils d’évaluation sur la configuration SSL/TLS, mais cha-
cun a son avantage par rapport aux autres, il y a ceux qui scannent le serveur
et d’autres qui scannent le client et aussi des outils qui permettent de scanner
tous les deux.

3.3.1 Étude des outils scan client

On présente dans cette section des outils similaires à notre solution proposée
qui permettent le scan au niveau du client, telque que l’outil How’s MySSL et
DCsec.
— How’s MySSL est un outil qui scanne le client (navigateur) permetant
de faire des vérifications sur les protocoles supportés et leur versions
et sur les suites de chiffrements supportés .Il est conçu pour aider un
développeur d’un serveur web à mieux apprendre les clients TLS. Cet
outil a été élargi pour donner aux développeurs un moyen rapide et facile
pour mieux comprendre les outils utilisés.Son inconvénient majeur est
qu’il ne présente pas tous les suites de chiffements.

Figure 3.1 – Test How’s MySSL

21
 — DCsec est un outil réalisé par un groupe de chercheurs qui permet d’éva-
luer le navigateur tout en donnant les suites de chiffrements et les proto-
coles supportés .Cet outil ne donne pas le niveau de sécurité de chaque
suite de chiffrement.

Figure 3.2 – Test DCsec

3.3.2 Étude des outils scan serveur

On présente dans cette partie quelques outils similaires à notre solution
proposée qui permettent le scan au niveau du serveur, telque que l’outil SSLyze
et Wormly.
— SSLyze est un projet open source qui analyse la configuration d’un ser-
veur, il est rapide et compréhensible et il aide les auditeurs à identifier les
mauvaises configurations affectant leur serveur. Cet outil est caractérisé
par un test de sécurité pour les suites de chiffrement, de validation et de
vérification de la révocation du certificat d’un serveur.
— Wormly est un outil qui effectue une analyse approfondie sur la configura-
tion et la performance du serveur web y compris les protocoles supportés
et les faiblesses de sécurité connues. Cet outil en ligne permet aussi de
tester un serveur de messagerie SMTP. Son majeur inconvénient est qu’il
ne présente pas les suites de chiffrement supportés par le serveur.

22
 Figure 3.3 – Test Wormly

3.3.3 Étude des outils scan client/seveur

SSLLabs est un outil qui fournit un test SSL permettant de vérifier la bonne
installation des certificats ainsi que la sécurité SSL/TLS de votre serveur et de
détecter les faiblesses de configuration SSL et des problèmes de performance.
Cet outil est l’un des outils de test SSL les plus populaires pour vérifier toutes
les vulnérabilirés et la mauvaise configuration du protocole SSL/TLS. Cet outil
permet de scanner que des serveurs web.

Figure 3.4 – Test SSLabs Server

23
 Figure 3.5 – Test SSLabs Client

3.4 Choix de la solution

Suite à notre étude préalable qui nous a permis de comprendre profondément
le concept de notre sujet, on a trouvé le projet open source SSLyze qui se com-
porte comme une bibliothèque Python permettant d’analyser la configuration
SSL/TLS d’un serveur, cependant cette solution peut être encore améliorée. On
a aussi trouvé le module d’Apache SSLhaf qui permet d’analyser des paquets
ClientHello. Suite à cette étude, on a pris l’initiative de concevoir une solution
complète qui permet de lancer un scan au niveau du client et du serveur en
exploitant ces deux soutions. On note qu’on a choisi SSLyze grâce à sa rapidité
des scans et leurs envoi automatique. Cet outil est caractérisé par un test de
performance et un test de sécurité, en ce qui concerne le choix de SSLhaf est
justifié grâce à sa capacité d’analyser les paquets ClientHello venant du client.

3.5 Conclusion
Dans ce chapitre, on a effectué une étude sur les différents outils similaires à
notre solution proposée. Bien que ces outils comportent des différents services,
il reste encore de trouver une solution complète est un objectif majeur. En effet
nous avons présenté brièvement le choix de notre solution proposée qui sera
décrite détaillée dans le chapitre suivant.

24
Chapitre 4

Solution proposée

4.1 Introduction
Une mauvaise configuration du protocle SSL/TLS peut le rendre peu sécurisé
et même vulnérable à des attaques et puisqu’il y a de nombreux paramètres de
configuration disponibles, il est difficile de savoir à l’avance quel impact certains
changements auront, ces changements peuvent êtres effectués accidentellement.
Donc dans ce cas, il faut utiliser un outil d’évaluation SSL/TLS complet pour
la vérification de la configuration et pour savoir si le système est vulnérable. On
va présenter dans ce chapitre notre solution proposée d’une manière détaillée.

4.2 Présentation de la solution proposée

Au niveau de notre projet, on a adapté et intégré l’outil opensource SS-
Lyze et le module d’Apache SSLhaf. Les composants mises en place vont per-
mettre d’évaluer la configuration SSL/TLS et de faire un scan complet sur le
serveur/client. Pour cette raison, notre outil AliveSSL fournit :
— Un Scan côté client qui donne la configuration SSL/TLS du navigateur,
les suites de chiffremment et le protocoles actives.
— Un Scan côté serveur qui donne la configuration SSL/TLS du serveur,
les suites de chiffrement, les protocoles supportés et s’il est vulnérable à
quelques types attaques.

4.2.1 Scan côté Serveur

Un grand nombre de suites de chiffrement disponible et des progrès rapides
dans la cryptanalyse rendent l’évaluation d’un serveur SSL une tâche évidente,
d’où il faut bien choisir l’outil de scan SSL/TLS à utiliser. Pour ces raisons,
notre outil doit permettre de faire un scan complet sur les certificats installés
sur un serveur, les suites de chiffremment, et pour atteindre ce besoin nous avons
utilisé et integré l’outil SSLyze.

25
4.2.1.1 SSLyze
SSLyze est un projet open source Python qui analyse la configuration SSL/TLS
d’un serveur. Il est conçu pour être rapide et complet, et devrait aider les orga-
nisations et les testeurs à identifier les mauvaises configurations affectant leurs
serveurs SSL. Pour faire un scan sur un serveur on lance cette commande :

4.2.1.2 Amélioration du Projet SSLyze

On a ajouté quelques améliorations sur le projet SSlyze pour le rendre plus
fiable et plus performant qui sont identifiées dans cette section.

L’Ajout des autorités de certification Les autorités de certification sont

un tiers de confiance permettant d’authentifier l’indentité des correspondants.
Chaque entité intégre nativement une liste de certificats provenant de différentes
autorités de certification choisies selon des règles internes définies par les déve-
loppeurs de l’entité (exemple : Adobe ), cette liste est sous la format .pem, on
a donc ajouté des listes au projet SSLyze pour rendre le scan plus fiable.

26
 Les listes ajoutés sont :
— Google CA store
— Adobe CA store
— Microsoft CA store
— Java CA store

Figure 4.1 – Les autorités de certification ajoutées

L’ajout du test d’attaque Le protocole SSL/TLS comporte en effet un

certain nombre de failles qu’un utilisateur mal intentionné peut les exploiter
pour provoquer un dénis de service ou introduire un code malveillant ou encore
intercepter le trafic entre les deux parties communicantes.
Il existe plusieurs vulnérabilités dans les versions du protocole SSL/TLS
telque l’attaque DROWN. Cependant, on a ajouté un test sur cette attaque.
-Test de l’attaque Drown sur SSLv2 : cette faille permet à un pirate de réc-
cupérer des informations sur un serveur et de compromettre une communication
utilisant le protocole SSLv2 :

27
4.2.2 Scan côté client
Le scan côté client consiste à faire une analyse sur les protocles supportés et
les suites de chiffremment configurés sur un navigateur. Au début de la commu-
nication SSL/TLS, le client envoie un paquet ClientHello au serveur qui contient
toutes les informations du navigateur .

Figure 4.2 – Scan client

D’où nous avons trouvé le module SSLhaf qui permet de capturer le paquet
ClientHello et d’enregister ces données dans un fichier log.

4.2.2.1 Configuration du module SSLhaf

Dans cette section, on va présenter les étapes de configuration du module
SSLhaf sous Ubuntu 14.04 :
— Copie des fichiers à partir du GitHub :
git clone https ://github.com/ssllabs/sslhaf.git
— Compilation du module
sudo apxs -cia mod_sslhaf.c
Ce script ajoute le LoadModule dans les fichier de configuration d’Apache.
— Ajout du module manuellement dans le fichier default-ssl.conf
Ce fichier se trouve dans /etc/apache2/sites-enabled/ ; on lui ajoute les lignes
suivantes :
LoadModule sslhaf_module /usr/lib/apache2/modules/mod_sslhaf.so
CustomLog logs/sslhaf.log "%t %{X-Forwarded-For}i \"%{SSL-
HAF_HANDSHAKE}e\" \
\"%{SSLHAF_PROTOCOL}e\" \"%{SSLHAF_SUITES}e\"
\"%{SSLHAF_COMPRESSION}e\" \
\"%{SSLHAF_EXTENSIONS_LEN}e\" \"%{SSL-
HAF_EXTENSIONS}e\" \"%{User-Agent}i\""\
env=SSLHAF_LOG
— Ouverture du serveur local
Https ://127.0.0.1 :443
— Contenu du fichier sslhaf.log
Le fichier sslhaf.log qui se trouve dans /etc/apache2/logs/sslhaf.log contient
maintenant la configuration SSL du navigateur qui visite le https ://127.0.0.1 :443
.

28
4.2.2.2 Le contenu log par défaut
Le contenu du fichier log est incompréhensible :
— Le premier champ contient la version du protocole SSL utilisé : 2 et 3
pour SSLv2 et SSLv3+ par exemple google bot utilise SSLv2 handshake
donc il est prêt à utiliser SSLv2 ou mieux.
— Le deuxième champ contient la meilleure version utilisée , par exemple
SSLv3 est "3.0",TLSv1.0 est "3.1",TLSv1.1 correspond à "3.2" et TLSv1.2
correspond à "3.3".
— Le troisième champ contient la liste des suites de chiffremment supportées
par le client.
Chaque suite associée a un code hexadecimal. Par exemple :
0x04 représente la suite SSL_RSA_WITH_RC4_128_MD5,
0x010080 représente SSL_CK_RC4_128_WITH_MD5
et 0x05 représente la suite SSL_RSA_WITH_RC4_128_SHA.
— Le quatrième champ contient la liste des méthodes de compression of-
fertes par le client (00 = NULL , 01 = DEFLATE).
D’où, on était obligés de convertir ce contenu en utilisant PHP pour qu’on puisse
afficher aux utilisateurs un résultat compréhensible.

4.3 Solution Complète AliveSSL

Notre application web AliveSSL permet d’utiliser les deux outils SSLyze et
SSLhaf pour faire une évaluation complète sur la configuration SSL/TLS côté
serveur/client.

Figure 4.3 – Page d’accueil du service AliveSSL

29
4.3.1 AliveSSL scan Client
Cette partie de notre application web utilise le fichier log généré par le mo-
dule sslhaf en changeant le contenu pour le rendre compréhensible par l’audi-
teur : on extracte le contenu du log champ par champ et le troisième champ sera
comparé avec une base de données pour déterminer les suites de chiffremment
reliés à chaque code hexadecimal.

Figure 4.4 – AliveSSL scan client

Puis on peut déterminer les protocoles supportés par le navigateur grâce au

premier champ du fichier log.

Figure 4.5 – Les protocoles supportés du log

On peut aussi déterminer le protocole utilisé grâce au deuxième champ .

Figure 4.6 – Les protocoles utilisés

30
4.3.2 AliveSSL scan Server
Cette partie de l’application web permet de tester la configuration du serveur
grâce à SSLyze où on va analyser son contenu et l’afficher à l’auditeur. Avec
sslyze on peut faire des scans sur plusieurs types de serveur comme LDAP,
FTP, SMTP, POP3. D’où notre application web sera capable de faire du scan
sur ces types de serveur .
Notre application fournit aux auditeurs une interface où il peuvent choisir
le type de serveur à analyser qui peuvent être un serveur web, SMTP, LDAP,
FTP et POP3.

4.3.3 Choix du type de serveur

Figure 4.7 – Choix du type de serveur

4.3.3.1 Serveur web

Le serveur web est spécifiquement un serveur multi-service utilisé pour pu-
blier des sites sur Internet , ce type de serveur est un ordinateur qui stocke les
fichiers composant un site web ( par exemple les documents HTML, les images,
les fichier javascript) et permet de les envoyer à l’appareil d’un utilisateur qui
visite le site.Cet ordinateur est connecté à Internet et il est généralement acces-
sible via un nom de domaine tel que exemple.net.

31
4.3.3.2 Serveur FTP
Serveur FTP (File Transfert Protocle) permet l’échange des fichiers sur In-
ternet . Tout utilisateur autorisé peut télécharger ou envoyer des fichiers sur
un ordianteur distant faisant fonctionner un tel serveur . Le port par défaut et
souvent utilisé est le port 21.

Figure 4.8 – Description de FTP

4.3.3.3 Serveur SMTP

Le serveur SMTP est un protocole de communication utilisé pour le trans-
ferts des courriers électroniques vers les derveurs de messagerie électronique .Le
transfert se fait sur le port 25 .On doit commencer par la spécification de l’ex-
péditeur du message puis la ou les destinataires d’un message .Il est possible
de tester un serveur SMTP en utilisant la commande telnet sur le port 25 d’un
serveur distant.

Figure 4.9 – Fonctionnement de SMTP

4.3.3.4 Serveur POP3

Le serveur POP3 est un protocole permettant de récupérer des courriers
électroniques situés sur un serveur de messagerie électronique distant quand
vous n’êtes pas connecté en permanence à Internet. Il permet de télécharger les
messages et les retirer du serveur .

32
 Figure 4.10 – Fontionnement de POP3

4.3.3.5 Serveur LDAP

Le serveur LDAP (Lightweight Directory Access Protocol) est un protocole
d’accès aux annuaires léger permettant de gérer des annuaires ; d’accéder à des
bases d’informations sur les utilisateurs d’un réseau par l’intermédiaire de pro-
tocoles TCP/IP . Ce protocole définit la méthode d’accès aux données sur le
serveur au niveau du client, et non la manière de laquelle les informations sont
stockées. . Un annuaire est conçu pour recevoir beaucoup plus de requêtes en
lecture qu’en écriture.

Figure 4.11 – Fonctionnement de LDAP

4.3.3.6 Choix du type du scan

Après le choix de type du serveur , l’auditeur choisit le type de scan à faire
sur ce serveur . Il choisit soit un scan régulier ou bien un scan spécifique.

33
 Figure 4.12 – Scan régulier

Dans le cas du scan régulier, notre application fournit aux auditeurs des
informations sur les protocles supportés par le serveur, les suites de chiffremment
de chaque protocle et des informations sur le ou les certificats électroniques du
serveur. Ainsi si le serveur est vulnérable sur quelques attaques comme suit :
screen
Dans ce cas ,l’auditeur doit choisir un scan spécifique ou aussi sur quel point
faire le scan , soit sur un protocole sépcifique ou sur une attaque bien déterminée
ou même sur le certificat électronique seulement .

Figure 4.13 – Scan spécifique

34
4.3.3.7 Résultat du scan
Après le choix du type de scan, AliveSSL affiche le résultat selon le type de
scan choisi en présentant un rapport sur les points spécifiques que l’auditeur a
choisi .

Figure 4.14 – Résultat du scan

4.4 Conclusion
Dans ce chapitre, on a mis en valeur notre solution proposée dont nous avons
détaillé ses différebts étapes et les améliorations que nous avons ajouté. Suite à
cette phase, nous tenons en compte la mal configuration qui peut générer des
attaques critiques à cause d’une mal connaissance de la configuration SSL/TLS.
C’est pourquoi on a fournit une partie consacrée aux bonnes pratiques dans le
chapitre 5 .

35
Chapitre 5

Bonnes pratiques

5.1 Introduction
SSL/TLS est une technologie trompeusement simple, facile à déployer, mais
son problème principal est que le cryptage est souvent n’est pas facile à dépolyer
correctement. Pour s’assurer que TLS fournit la sécurité nécessaire, les adminis-
trateurs du système et les développeurs doivent émettre un effort supplémentaire
à la configuration de leurs serveurs et le développement des applications.Dans
ce chapitre,on va présenter des recommandations et des bonnes pratiques.

5.2 Recommandations
En TLS, la sécurité commence par l’identité cryptographique du serveur,
une clé privée forte est nécessaire pour empêcher les attaquants de mener des
attaques d’empreinte d’identité. Il est aussi important d’avoir un certificat valide
et , solide qui fournit à la clé privée le droit de représenter un nom d’hôte
particulier .Sans ces deux éléments fondamentaux , rien d’autre ne peut être
sécurisé.

5.2.1 Utilisation des clés privées de 2048-bit

Pour la plupart des sites Web, la sécurité fournie par les clés RSA de 2048
bits est suffisante.L’algorithme de clé publique RSA est largement pris en charge,
ce qui rend les clés de ce type un choix sûr par défaut .À 2048 bits, ces clés
fournissent environ 112 bits de sécurité .Si on veut plus de sécurité que cela,
on note que les clés RSA ne s’échelle pas très bien.Pour obtenir 128 bits de
sécurité, on a besoin des clés RSA de 3072 bits, ce qui est sensiblement plus
lent. Les clés ECDSA offrent une alternative qui offre une meilleure sécurité et
de meilleures performances. À 256 bits, les clés ECDSA fournissent 128 bits de
sécurité. Un petit nombre des anciens clients ne prennent pas en charge ECDSA,
mais les clients modernes le font. Il est possible d’obtenir le meilleur des deux

36
et de déployer les clés RSA et ECDSA en simultanée si les frais généraux de la
gestion d’une telle configuration ne vous dérange pas.

5.2.2 Protection des clés privées

Traitez vos clés privées comme un atout important, restreignant l’accès au
plus petit groupe possible d’employés tout en gardant vos arrangements pra-
tiques. Les politiques recommandées comprennent les éléments suivants :
— Générer des clés privées sur un ordinateur de confiance avec une entropie
suffisante. Certaines autorités de certification vous permettent de générer
des clés privées ; dans ce cas il faut les éviter.
— Assister les clés avec un mot de passe dès le début pour éviter tout com-
promis lorsqu’ils sont stockés dans des systèmes de sauvegarde. Les clés
privées ne contribuent pas beaucoup à la production, car un attaquant
bien informé peut toujours récupérer les clés de la mémoire du processus.
Il existe des périphériques matériels (appelés modules de sécurité maté-
rielle ou HSMs(Hardware Security Modules)) qui peuvent protéger les
clés privées, même en cas de compromis du serveur, mais coûtent cher et
ne peuvent être justifiés que pour les organisations ayant des exigences
de sécurité strictes.
— Après un compromis, révoquez les anciens certificats et générez des nou-
velles clés.
— Renouveler les certificats chaque année, et plus souvent si vous pouvez
automatiser le processus. La plupart des sites devraient supposer qu’un
certificat compromis sera impossible à révoquer de manière fiable. Les
certificats avec une durée de vie plus courte sont donc plus garanties en
pratique. Sauf si les mêmes clés sont importantes pour l’épinglage de clé
publique, vous devez également générer de nouvelles clés privées chaque
fois que vous recevez un nouveau certificat.

5.2.3 Assurance d’ une couverture suffisante du nom d’hôte

Assurez-vous que vos certificats couvrent tous les noms que vous souhaitez
utiliser avec un site. Votre objectif est d’éviter les avertissements des certificats
invalides, qui confondent les utilisateurs et affaiblissent leur confiance. Même
lorsque vous vous attendez à utiliser un seul nom de domaine, n’oubliez pas
que vous ne pouvez pas contrôler la façon dont vos utilisateurs arrivent sur le
site ou comment les autres le lient. Dans la plupart des cas, vous devez vous
assurer que le certificat fonctionne avec et sans le préfixe www (par exemple, il
faut qu’il fonctionne pour example.com et www.example.com). La règle générale
est qu’un serveur web sécurisé devrait avoir un certificat valable pour chaque
DNS configuré pour le pointer. Les certificats génériques ont leurs utilisations,
mais évitez de les utiliser si cela implique d’exposer les clés sous-jacentes à
un groupe de personnes beaucoup plus grand, et surtout si elles croisent les
limites de l’équipe ou d’un tel département. En d’autres termes, moins il y a
des personnes avec accès aux clés privées, mieux ca sera. Sachez également que

37
le partage de certificats crée un lien qui peut être abusé pour transférer des
vulnérabilités d’un site web ou d’un serveur à tous les autres sites et serveurs
qui utilisent le même certificat (même lorsque les clés privées sous-jacentes sont
différentes).

5.2.4 Obtension des certificats d’une autorité de certifica-

tion fiable
Sélectionnez une Autorité de certification (CA : Certification Authority) qui
est fiable et sérieuse au sujet de son activité de certification et de sa sécurité.
Considérez les critères suivants lors de la sélection de votre autorité de certifi-
cation :
— Poste de sécurité : Toutes les autorités de certification sont soumises à des
audits réguliers, mais certaines sont plus sérieuses en matière de sécurité
que d’autres . Déterminer quels sont les meilleurs autorités à cet aspect
qui n’est pas facile, mais une option consiste à examiner leur historique
de sécurité et le plus important encore c’est comment ils ont réagi aux
compromis et s’ils ont appris de leurs erreurs.
— Focus d’affaires : Les autorités de certification d’affaires dont les acti-
vités constituent une partie substantielle de leur entreprise ont tout à
perdre si quelque chose est terriblement fausse, et ils ne négligeront pro-
bablement pas leur division de certificats en recherchant des opportunités
potentiellement plus lucratives ailleurs.
— Services offerts : Au minimum, votre autorité de certification sélectionnée
devrait fournir un support pour les méthodes de révocation de liste de
certificats (CRL : Certificate Revocation List) et le protocole de statut
de certificat en ligne (OCSP :Online Certificate Status Protocol), avec
une disponibilité et performances de réseau fiable. De nombreux sites
sont satisfaits des certificats validés par le domaine, mais vous devriez
également considérer si vous avez besoin de certificats de validation éten-
due (EV : Extended Validation). Dans les deux cas, vous devriez avoir
un choix d’algorithme de clé publique. La plupart des sites web utilisent
RSA aujourd’hui, mais ECDSA peut devenir importante à l’avenir en
raison de ses avantages de performance.
— Les options de gestion de certificats : Si vous avez besoin d’un grand
nombre de certificats et que vous êtes dans un environnement complexe,
choisissez une autorité de certification qui vous donnera de bons outils
pour les gérer.
— Support : Choisissez une autorité de certification qui vous donnera un
bon support si vous en avez besoin.
Remarque : Pour de meilleurs résultats, proccurez-vous de vos certificats à
l’avance et au moins une semaine avant de les déployer dans la production.
Cette pratique vous aide à éviter les avertissements de certificat pour certains
utilisateurs qui n’ont pas l’heure correcte sur leurs ordinateurs et contribue à
éviter des vérifications de révocation échouées avec les autorités de certification
qui ont besoin de plus de temps pour propager de nouveaux certificats comme

38
étant valides pour leurs répondeurs OCSP. Au fil du temps, essayez d’étendre
cette période de «réchauffement» à 1 à 3 mois. De même, n’attendez pas jusqu’à
ce que vos certificats soient sur le point d’expirer pour les remplacer. En laissant
plusieurs mois supplémentaires, cela aiderait également les personnes dont les
horloges sont incorrectes

5.2.5 Utilisation des algorithmes de signature de certificat

solide
La sécurité du certificat dépend de la force de la clé privée utilisée pour signer
le certificat et de la force de la fonction de hachage utilisée dans la signature.
Jusqu’à récémment, la plupart des certificats s’appuyaient sur la fonction de ha-
chage SHA1, qui est maintenant considérée comme non sécurisé. Par conséquent,
nous sommes en train de passer à SHA256.
À partir de janvier 2016, vous ne devriez pas pouvoir obtenir un certifi-
cat SHA1 auprès d’une autorité de certification public. Les certificats SHA1
existants continueront de fonctionner (avec des avertissements dans certains na-
vigateurs), mais seulement jusqu’à la fin de 2016.

5.3 Configuration
Avec la configuration correcte du protocole TLS sur un serveur, vous assurez
que vos informations d’identification sont correctement présentées aux visiteurs
du site, que seulement les primitives cryptographiques sécurisées sont utilisées
et que toutes les faiblesses connues sont atténuées.

5.3.1 Utilisation des chaînes de certificats complètes

Dans la plupart des déploiements, un seul certificat d’un serveur est insuf-
fisant, deux certificats ou plus sont nécessaires pour construire une chaîne de
confiance complète. Un problème de configuration commun se produit lors du
déploiement d’un serveur avec un certificat valide, mais sans tous les certificats
intermédiaires nécessaires. Pour éviter cette situation, utilisez simplement tous
les certificats qui vous sont fournis par votre autorité de certification. Un certi-
ficat invalide rend toute la chaîne de certificats d’un serveur invalide et entraîne
des avertissements du navigateur. Dans le pratique, ce problème est parfois dif-
ficile à diagnostiquer car certains navigateurs peuvant reconstruire des chaînes
incomplètes et certains ne le peuvent pas . Tous les navigateurs ont tendance à
mettre en cache et à réutiliser des certificats intermédiaires.

5.3.2 Utilisation des protocoles sécurisés

Il existe cinq protocoles dans la famille SSL/TLS : SSL v2, SSL v3, TLS
v1.0, TLS v1.1 et TLS v1.2 :

39
 — SSL v2 n’est pas sécurisée et ne doit pas être utilisée. Cette version de
protocole est si grave qu’elle peut être utilisée pour attaquer des clés
RSA et des sites avec le même nom même s’ils sont sur des serveurs
entièrement différents (l’attaque DROWN).
— SSL v3 est peu sûr lorsqu’elle est utilisée avec HTTP (l’attaque POO-
DLE) et faible lorsqu’elle est utilisée avec d’autres protocoles. Il est éga-
lement obsolète et ne doit pas être utilisée.
— TLS v1.0 est également un protocole hérité qui ne devrait pas être uti-
lisée, mais il est encore nécessaire dans le pratique. Sa faiblesse majeure
(BEAST) a été atténuée dans les navigateurs modernes, mais d’autres
problèmes subsistent.
— TLS v1.1 et v1.2 sont à la fois sans problèmes de sécurité connus, mais
seulement TLS v1.2 fournit des algorithmes cryptographiques modernes.
TLS v1.2 devrait être votre protocole principal car c’est la seule version
qui offre un cryptage authentifié moderne (également appelé AEAD). Si
vous ne supportez pas TLS v1.2 aujourd’hui, vous avez un manque de
sécurité. Afin de prendre en charge les anciens clients, vous devrez conti-
nuer à prendre en charge TLS v1.0 et TLS v1.1 pour l’instant. Cepen-
dant, vous devriez retirer TLS v1.0 dans le proche avenir. Par exemple,
la norme PCI DSS exigera tous les sites qui acceptent le paiements par
carte de crédit pour supprimer le support de TLS v1.0 d’ici juin 2018.
Des travaux sont actuellement en cours pour concevoir TLS v1.3, dont le but
d’éliminer toutes les fonctionnalités obsolètes et non sécurisées et d’apporter des
améliorations qui permettront de sécuriser notre communication au cours des
décennies suivantes.

5.3.3 Utilisation des suites de chiffrements sécurisées

Pour communiquer en toute sécurité, vous devez d’abord vérifier que vous
communiquez directement avec la partie souhaitée (et pas par l’entremise d’une
personne qui écoute) et échanger des données de manière sécurisée. Dans SSL/TLS
, les suites de chiffrement définissent la manière dont la communication sécurisée
se déroule. Ils sont composés de différents blocs de construction avec l’idée de sé-
curiser la diversité. Si l’un des blocs de construction se révèle faible ou instable,
vous devriez pouvoir passer à un autre. Vous devriez compter principalement
sur les suites AEAD qui fournissent une authentification et un échange de clés
fort, une confidentialité persistante et un chiffrement d’au moins 128 bits.
Certaines suites plus faibles peuvent encore être supportées, à condition
qu’elles ne soient négociées qu’avec des clients plus anciens qui ne prennent en
charge rien de mieux. Il existe plusieurs primitives cryptographiques obsolètes
qui doivent être évitées :
— Anonymous Diffie-Hellman (ADH) sont des suites qui ne fournissent pas
une authentication.
— Les suites de chiffrement NULL qui ne fournissent aucun chiffrement.
— Les ensembles de chiffrement d’exportation ne sont pas sécurisés lorsqu’ils
sont négociés dans une connexion entre deux entités, mais ils peuvent

40
 également être utilisés contre un serveur qui préfère des suites plus fortes
(l’attaque FREAK).
— Les suites avec des chiffres faibles (typiquement de 40 et 56 bits) utilisent
un cryptage qui peut facilement être brisé.
— RC4 n’est pas sécurisé.
— 3DES est lent et faible.
Utilisez la configuration de la liste suivante, conçue pour les clés RSA et ECDSA,
comme point de départ :
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Attention : Nous vous recommandons de tester d’abord votre configuration
TLS dans un environnement de mise en scène, transférez les modifications dans
l’environnement de production uniquement lorsque vous êtes certains que tout
fonctionnent est comme prévu. Veuillez noter que ce qui précède est une liste
générique et que tous les systèmes (en particulier les plus anciens) ne sont pas
compatibles avec toutes ces suites . C’est pourquoi il est important de tester
d’abord. La configuration ci-dessus utilise des noms de suites TLS standard.
Certaines plates-formes utilisent des noms non standard, veuillez consulter la
documentation de votre plate-forme pour plus de détails. Par exemple, les noms
de suite suivants seraient utilisés avec OpenSSL :
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384

41
 ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

5.3.4 Sélection des meilleures suites de chiffrement

Dans les versions de protocole SSL v3 et versions ultérieures, les clients
présentent une liste de suites de chiffrement supportées et les serveurs choisissent
une suite de la liste à utiliser pour la connexion. Tous les serveurs ne sont
pas capables de faire ca correctemment, cependant, certains sélectionneront la
première suite prise en charge dans la liste des suites du client. Les serveurs qui
sélectionnent la meilleure suite de chiffrement disponible sont essentiels pour
obtenir la meilleure sécurité.

5.3.5 Confidentialité persistante

La confidentialité persistante (parfois aussi appelé confidentialité persistante
parfaite) est une fonction de protocole qui permet des conversations sécurisées
qui ne dépendent pas de la clé privée du serveur. Avec les suites de chiffrement
qui ne fournissent pas le confidentialité persistante, quelqu’un qui peut réccu-
pérer la clé privée d’un serveur peut décrypter toutes les conversations cryptées
enregistrées antérieurement. Vous devez soutenir et préférer les suites ECDHE
afin de permettre le confidentialité persistante avec les navigateurs Web mo-
dernes. Pour soutenir une gamme plus large de clients, vous devriez également
utiliser les suites DHE en alternance après ECDHE. Évitez l’échange des clés
RSA à moins d’être absolument nécessaire. Notre configuration par défaut pro-
posée dans la sous section 5.3.3 ne contient que des suites qui fournissent une
confidentialité persistante.

5.3.6 Utilisation d’échange des clés fortes

Pour l’échange de clés, les sites publics peuvent généralement choisir entre
l’échange de clés Diffie-Hellman (DHE) et sa variante ECDHE. Il existe d’autres
algorithmes d’échange de clés, mais ils sont en général instables d’une manière ou
d’une autre. L’échange de clés RSA est encore très populaire, mais il ne fournit
pas la confidentialité persistante. En 2015, un groupe de chercheurs ont publié
des nouvelles attaques contre DHE ; Leur travail est connu comme l’attaque
de Logjam.Les chercheurs ont découvert que les échanges de clés DHE à faible
résistance (par exemple, 768 bits) peuvent facilement être brisés et que certains

42
groupes DHE de 1024 bits connues peuvent être brisés par les agences de l’État.
Pour être sûr, si vous déployez DHE, configurez-le avec au moins 2048 bits de
sécurité. Certains clients plus anciens (par exemple, Java 6) pourraient ne pas
supporter ce niveau de force. Pour des raisons de performance, la plupart des
serveurs préfèrent ECDHE, qui est à la fois plus fort et plus rapide.Le secp256r1
(également appelée P-256) est un bon choix dans ce cas.

5.3.7 Atténuation des problèmes connus

Il y a eu de nombreuses attaques contre SSL et TLS ces dernières années,
mais elles ne devraient généralement pas vous concerner si vous disposez de
logiciels à jour et en suivant les conseils de ce chapitre. Cependant, rien n’est
parfaitement sécurisé, c’est pourquoi il est bon de garder un oeil sur ce qui
se passe en sécurité. Appliquer rapidement les correctifs des fournisseurs si et
quand ils sont disponibles, sinon s’appuyer sur des solutions de contournement
pour atténuer les risques.

5.4 Performance
La sécurité est notre objectif principal dans ce chapitre, mais nous devons
également faire attention à la performance
Un service sécurisé qui ne satisfait pas les critères de performance sera sans
aucun doute abandonné. Avec une configuration correcte, TLS peut être assez
rapide. Avec les protocoles modernes, par exemple HTTP/2, il pourrait même
être plus rapide que la communication en clair.

5.4.1 Évitement de trop de sécurité

L’établissement d’une liaison (handshake) cryptographique, utilisée pour éta-
blir des connexions sécurisées, est une opération pour laquelle le coût est forte-
ment influencé par la taille de la clé privée. L’utilisation d’une clé trop courte
est peu sûr, mais l’utilisation d’une clé trop longue entraînera une sécurité très
élevée et un fonctionnement lent. Pour la plupart des sites web, utilisez des clés
RSA supérieures à 2048 bits et ECDSA supérieures à 256 bits , c’est un gas-
pillage de puissance de la CPU et peut nuire à l’expérience de l’utilisateur. De
même, il y a peu d’avantages à augmenter la force de l’échange de clés éphé-
mères au-delà de 2048 bits pour DHE et 256 bits pour ECDHE. Il n’y a aucun
avantage évident d’utiliser un chiffrement supérieur à 128 bits.

5.4.2 Reprise de session d’utilisation

La reprise de la session est une technique d’optimisation des performances
qui permet de sauvegarder les résultats d’opérations cryptographiques coûteuses
et de les réutiliser pendant un certain temps. Un mécanisme de reprise de ses-
sion invalide ou non fonctionnelle peut introduire une pénalité de performance
significative.

43
5.4.3 Utilisation de l’optimisation WAN et HTTP/2
Ces jours-ci, les frais généraux TLS ne proviennent pas d’opérations crypto-
graphiques affamées par la CPU, mais de la latence du réseau. l’établissement
d’une liaison TLS, qui ne peut démarrer qu’après la fin de l’établissement d’une
liaison TCP, nécessite un nouvel échange de paquets et sera plus coûteuse si
vous êtes loin du serveur. La meilleure façon de minimiser la latence est d’éviter
de créer de nouvelles connexions, c’est-à-dire de garder les connexions existantes
ouvertes pendant longtemps (keep-alives). D’autres techniques qui fournissent de
bons résultats comprennent le soutien de protocoles modernes tels que HTTP/2
et l’utilisation de l’optimisation WAN (généralement via des réseaux de distri-
bution du contenu).

5.4.4 Cache du contenu public

Lors de la communication avec SSL/TLS, les navigateurs peuvent supposer
que tout le trafic est sensible. Ils utilisent généralement la mémoire pour cacher
certaines ressources, mais une fois que vous fermez le navigateur, tout le contenu
peut être perdu. Pour obtenir une amélioration de la performance et permettre
la mise en cache à long terme de certaines ressources, marquez les ressources
publiques (par exemple, les images) en tant que public.

5.4.5 Utilisation d’agglomération OCSP

L’agglomération OCSP est une extension du protocole OCSP qui délivre des
informations de révocation dans le cadre du handshake TLS, directement depuis
le serveur. En conséquence, le client n’a pas besoin de contacter les serveurs
OCSP pour la validation hors bande et le temps total de connexion TLS est
considérablement réduit. L’agglomération OCSP est une technique d’optimisa-
tion importante, mais vous devez savoir que tous les serveurs web ne fournissent
pas de solides implémentations d’agglomération OCSP. Associés à une autorité
de certification qui a un répondeur OCSP lent ou peu fiable, ces serveurs web
peuvent créer des problèmes de performances. Pour de meilleurs résultats, si-
mulez les conditions d’échec pour voir si elles pourraient avoir une incidence sur
votre disponibilité.

5.4.6 Utilisation des primitives cryptographiques rapides

En plus de fournir une meilleure sécurité, notre configuration sur la suite
de chiffrement recommandée offre également les meilleures performances. Dans
la mesure du possible, utilisez des CPU qui prennent en charge l’AES accé-
léré par le matériel. Après cela, si vous voulez vraiment un autre avantage de
performance (probablement pas nécessaire pour la plupart des sites), envisagez
d’utiliser les clés ECDSA.

44
5.5 Protocole HTTP et la sécurité des applica-
tions
Le protocole HTTP et la plate-forme environnante pour la livraison d’ap-
plications web ont continué à évoluer rapidement après la naissance de SSL. À
la suite de cette évolution, la plate-forme contient maintenant des fonctionnali-
tés qui peuvent être utilisées pour vaincre le cryptage. Dans cette section, nous
présenterons ces fonctionnalités, ainsi que les moyens de les utiliser en toute
sécurité.

5.5.1 Chiffrement de tout

Le fait que le cryptage soit facultatif est probablement l’un des problèmes
de sécurité . Nous voyons les problèmes suivants :
— Pas de TLS sur les sites qui en ont besoin.
— Les sites qui ont TLS mais qui ne l’appliquent pas.
— Sites qui mélangent le contenu TLS et non TLS, parfois même dans la
même page.
— Sites avec des erreurs de programmation qui subissent TLS.
Bien que beaucoup de ces problèmes puissent être atténués si vous savez exac-
tement ce que vous faites, le seul moyen de protéger de manière fiable la com-
munication sur le site web est de faire respecter le cryptage sans exception.

5.5.2 Élimination de contenu mixte

Les pages à contenu mixte sont celles qui sont transmises par TLS, mais
incluent des ressources (par exemple, des fichiers JavaScript, des images, des
fichiers CSS) qui ne sont pas transmises par TLS. Ces pages ne sont pas sé-
curisées. Un attaquant actif d’un homme dans le milieu (MITM :Man In The
Middle) peut se détacher sur une seule ressource JavaScript non protégée, par
exemple et détourner toute la session utilisateur. Même si vous suivez les conseils
de la section précédente et cryptez tout votre site web, vous risquez toujours de
réccupérer certaines ressources non cryptées depuis des sites web tiers.

5.5.3 Confiance des tiers

Les sites web utilisent souvent des services tiers activés via le code JavaS-
cript téléchargé à partir d’un autre serveur. Un bon exemple d’un tel service
est Google Analytics, qui est utilisé sur de grandes parties du web. Une telle
inclusion de code tier crée une connexion de confiance implicite qui donne ef-
fectivement à l’autre partie un contrôle total sur votre site web. Le tiers peut
ne pas être malveillant, mais les grands fournisseurs de ces services sont de plus
en plus considérés comme des cibles. Le raisonnement est simple : si un grand
fournisseur est compromis, l’attaquant accède automatiquement à tous les sites
qui dépendent du service. Si vous suivez les conseils de la section 5.5.2, au moins

45
vos liens tiers seront cryptés et donc protégés contre les attaques MITM. Ce-
pendant, vous devriez aller plus loin : apprendre les services que vous utilisez et
les supprimer, les remplacer par des solutions plus sûres ou accepter le risque de
leur utilisation. Une nouvelle technologie appelée intégrité sous-ressource (SRI :
subresource integrity) pourrait être utilisée pour réduire l’exposition potentielle
via des ressources tiers.

5.5.4 Sécurisation des cookies

Pour être correctement sécurisé, un site web nécessite TLS, mais aussi tous
ses cookies sont explicitement marqués comme sécurisés lorsqu’ils sont créés.
La non-sécurisation des cookies permet à un attaquant MITM actif de provo-
quer des informations avec des astuces intelligentes, même sur des sites 100%
chiffrés. Pour de meilleurs résultats, pensez à ajouter une validation d’intégrité
cryptographique ou même un cryptage à vos cookies.

5.5.5 Compression de HTTP sécurisée

L’attaque CRIME 2012 a montré que la compression TLS ne peut pas être
implémentée de manière sécurisée. La seule solution était de désactiver totale-
ment la compression TLS. L’année suivante, deux autres variantes d’attaque ont
suivi TIME et BREACH axés sur les secrets dans les corps de réponse HTTP
compressés à l’aide de la compression HTTP. Contrairement à la compression
TLS, la compression HTTP est une nécessité et ne peut pas être désactivée.
Ainsi, pour résoudre ces attaques, des modifications au code de l’application
doivent être effectuées.
Les attaques TIME et BREACH ne sont pas faciles à réaliser, mais si quel-
qu’un est suffisamment motivé pour les utiliser, l’impact est approximativement
équivalent à une attaque réussie de cross-site request forgery (CSRF).

5.5.6 Déploiement de HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) est un filet de sécurité pour TLS.
Il a été conçu pour garantir que la sécurité reste inpact même dans le cas des
problèmes de configuration et d’erreurs de mise en œuvre. Pour activer la protec-
tion HSTS, vous ajoutez un nouvel en-tête de réponse à vos sites web. Ensuite,
les navigateurs qui prennent en charge HSTS (tous les navigateurs modernes à
ce moment-là) l’appliquent. L’objectif de HSTS est simple : après l’activation,
il ne permet aucune communication non sûre avec le site web qui l’utilise. Il
atteint cet objectif en convertissant automatiquement tous les liens en texte
clair sécurisé. En prime, il désactive également les avertissements de certificat
de clic (les avertissements de certificats sont un indicateur d’une attaque MITM
active). Des études ont montré que la plupart des utilisateurs font un clic sur ces
avertissements, il est donc dans votre intérêt de ne jamais les autoriser. L’ajout
de support pour HSTS est l’amélioration la plus importante possible pour la sé-
curité TLS de vos sites web. Les nouveaux sites devraient toujours être conçus

46
avec HSTS à l’esprit et les anciens sites convertis pour les supporter autant que
possible et dès que possible. Pour une meilleure sécurité, envisagez d’utiliser le
préchargement HSTS, qui intègre votre configuration HSTS dans les navigateurs
modernes, ce qui rend la première connexion à votre site sécurisée.
L’exemple de configuration suivant active HSTS sur le nom d’hôte princi-
pal et tous ses sous domaines pour une période d’un an, tout en permettant
également la précharge :
Strict-Transport-Security : max-age=31536000 ; includeSubDomains ; pre-
load

5.5.7 Déploiement de la politique de sécurité du contenu

La stratégie de sécurité de contenu (CSP :Content Security Policy) est un
mécanisme de sécurité que les sites Web peuvent utiliser pour restreindre le fonc-
tionnement du navigateur. Même si initialement conçu pour traiter Cross-Site
Scripting (XSS), CSP évolue constamment et prend en charge les fonctionnali-
tés qui sont utiles pour améliorer la sécurité TLS. En particulier, il peut être
utilisé pour restreindre le contenu mixte lorsqu’il s’agit de sites Web tiers, pour
lesquels HSTS ne les aide pas. Pour déployer CSP pour empêcher le contenu
mixte tiers, utilisez la configuration suivante :
Content-Security-Policy : default-src https : ’unsafe-inline’ ’unsafe-eval’ ;
connect-src https : wss :
Remarque : Ce n’est pas la meilleure façon de déployer CSP. Afin de fournir
un exemple qui ne cesse rien sauf le contenu mixte, on a dû désactiver certaines
des fonctionnalités de sécurité par défaut. Au fil du temps, à mesure que vous en
apprendrez plus sur CSP, vous devriez modifier votre politique pour les ramener.

5.5.8 Mise en cache du contenu sensible

Tout le contenu sensible doit être communiqué uniquement aux parties concer-
nées et traité en conséquence par tous les périphériques. Bien que les proxies ne
voient pas le trafic chiffré et ne parviennent pas à partager le contenu entre les
utilisateurs, l’utilisation des plates-formes de diffusion d’applications basées sur
le cloud est en augmentation, c’est pourquoi il faut faire très attention lorsque
vous spécifiez ce qui est public et ce qui ne l’est pas.

5.5.9 Considération d’autres menaces

TLS est conçu pour traiter un seul aspect de la confidentialité de la sécurité
et l’intégrité de la communication entre vous et vos utilisateurs, mais il existe
des nombreuses autres menaces auxquelles vous devez faire face. Dans la plupart
des cas, cela signifie que votre site Web n’a pas d’autres faiblesses.

47
5.6 Validation
Avec de nombreux paramètres de configuration disponibles pour les ajus-
tements, il est difficile de savoir à l’avance quel impact certains changements
auront. En outre, les changements sont parfois effectués accidentellement.
Les mises à jour logicielles peuvent introduire des modifications silencieuse-
ment. Pour cette raison, nous vous conseillons d’utiliser d’abord un outil d’éva-
luation SSL / TLS complet pour vérifier votre configuration afin de vous assurer
que vous démarrez en toute sécurité, puis périodiquement pour vous assurer de
rester en sécurité. Pour les sites web publics, nous recommandons le test du
serveur SSL Labs gratuit.

5.7 Conclusion
La partie recommandations et bonnes pratiques est offerte aux auditeurs afin
de les aider pour une meilleure configuration SSL/TLS d’un serveur .

48
Conclusion et Perspectives

Ce stage était une opportunité de mettre l’accent sur le domaine de la sécu-

rité informatique.Notre mission avait comme objectif de réaliser un outil d’audit
sur la configuration SSL/TLS d’un serveur afin de permettre de détailler les
protocoles supportés et les suites de chiffrements. Après une étude profonde qui
porte sur les différentes solutions Opensources disponibles côté client et côté
serveur , on s’est arrivés à choisir le projet open source sslyze grâce à sa rapidité
dans la partie serveur et le projet sslhaf grâce à son exactitude dans la partie
client.
Suite à cette expérience et en réponse à ses enjeux , on aimera prochainement
améliorer cette solution par l’ajout des nouveaux fonctionnalités telque :
— La gestion des comptes des utilisateurs.
— L’utilisation de l’outil nmap qui permet de fournir le niveau de sécurité
d’une suite de chiffrement.
— L’ajout des tests de vulnérabilités pour les attaques les plus récentes .
— L’adaptation de notre outil au protocole TLS 1.3.

49
Bibliographie

[1] https://openweb.eu.org/articles/https-de-ssl-a-tls-1-3 (15 Avril 2017)

[2] https://www.digdeo.fr/securite/ssl-tls-failles-dans-les-versions-et-
methodes-utilises-par-defaut (24 Février 2017)
[3] http://tools.kali.org/information-gathering/sslyze (3 Mars 2017)
[4] https://www.howsmyssl.com/ (10 Mars 2017)
[5] https://geekflare.com/ssl-test-certificate/ (28 Avril 2017)
[6] http://windowsitpro.com/networking/configuring-ssltls (6 Mars 2017)
[7] https://doc.ubuntu-fr.org/tutoriel/securiser_apache2_avec_ssl (20 Mai
2017)
[8] T. Dierks; E. Rescorla (August 2008). "The Transport Layer Security (TLS)
Protocol, Version 1.2"
[9] A. Freier; P. Karlton; P. Kocher (August 2011). "The Secure Sockets Layer
(SSL) Protocol Version 3.0"

50