Interception SSL TLS Fonctionnement Enjeux Risques Pratiques .pdf



Nom original: Interception_SSL-TLS_Fonctionnement_Enjeux_Risques_Pratiques.pdf

Ce document au format PDF 1.5 a été généré par TeX / MiKTeX pdfTeX-1.40.17, et a été envoyé sur fichier-pdf.fr le 04/10/2017 à 18:18, depuis l'adresse IP 176.130.x.x. La présente page de téléchargement du fichier a été vue 884 fois.
Taille du document: 1.1 Mo (62 pages).
Confidentialité: fichier public


Aperçu du document


Formation : M2 MIAGE SIID

L’interception SSL/TLS
Le fonctionnement,
Entre enjeux et risques,
Les bonnes pratiques.

Edouard Petitjean

25 août 2017

Préambule
La sécurisation des échanges numériques, un domaine difficile à appréhender. Autrefois réservés
aux forces militaires, les moyens permettant de chiffrer des données se sont répandus aux organisations
privées et étatiques. Suite à la démocratisation du SSL/TLS qui permet de sécuriser des échanges liés au
web, aux mails et d’autres moyens de communication, le mode d’utilisation d’Internet a radicalement
changé. Le lieu où la confiance ne pouvait régner, voir qualifié de « sans foi ni loi » 1 , est devenu depuis
lors le réseau des communications privées, des achats, de la gestion administrative, etc...
Après que les banques et les sites de e-commerces utilisaient le SSL/TLS pour sécuriser les échanges
avec leurs clients, ce sont les plates-formes de communications (webmails, réseaux sociaux, etc...) qui
ont adopté cette technologie. Avec cette dernière pratique, ce fut les principes du respect de la vie
privée et du secret des correspondances qui faisaient office de justification pour sécuriser les échanges.
Mais c’est avec les révélations d’Edward Snowden sur PRISM 2 que l’échange des données sécurisé entre
un client et un serveur — et de façon qu’aucun intermédiaire ne puisse comprendre la communication
— est devenu l’argument commercial majeur pour la plupart des acteurs du web. Par conséquent, nous
pouvons voir de plus en plus de ces communications sécurisées, souvent via SSL/TLS, apparaître.
Il est tout à fait normal de nos jours, que les utilisateurs d’un système informatique d’une entreprise
accèdent à ces sites sécurisés, que ça soit dans le cadre professionnel ou personnel. Or, ces échanges
sécurisés, entre un utilisateur et le site distant, ne laissent aucune visibilité à l’entreprise sur leurs
contenus. Loin de vouloir « espionner » les employés, ce sont les éventuelles fuites de données et
la récupération de fichiers malveillants qui posent problème. En effet, sans pouvoir comprendre les
échanges, les différents systèmes de sécurité permettant à une entreprise de se protéger deviennent
aveugle. La solution ? L’interception SSL/TLS. Mais est-elle bénéfique ? Sans risques ?
Ce présent article va présenter la technique dite interception SSL. Il sera découpé en trois parties.
La première expliquera le protocole SSL/TLS ainsi que la technique d’interception SSL/TLS. Puis dans
un second temps, cet article traitera des enjeux et risques que présente l’interception SSL/TLS. Nous
terminerons par les bonnes pratiques en matière de déploiement et d’utilisation de cette technique.

1. Expression dite par Alain Finkielkraut le 31/01/2014 sur la chaîne de BFMTV
2. Vaste programme de surveillance des communications mondiales mis en place par la NSA en 2007

Edouard Petitjean — M2 MIAGE SIID

1

Sommaire
I

L’interception SSL

4

1 Quelle différence entre SSL et TLS ?
1.1 Historique du SSL et du TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Obsolescence du SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Un abus de langage historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5
5
5
7

2 TLS : un protocole compliqué ?
2.1 Les objectifs du TLS . . . . . . . . . . . . . . . . . . .
2.2 Le positionnement du TLS dans le modèle TCP/IP . .
2.3 Un protocole fortement évolutif . . . . . . . . . . . . .
2.4 Rappel cryptographique . . . . . . . . . . . . . . . . .
2.4.1 Chiffrement symétrique . . . . . . . . . . . . .
2.4.2 Chiffrement asymétrique . . . . . . . . . . . . .
2.4.3 Empreinte numérique . . . . . . . . . . . . . .
2.5 Authentification : un principe de confiance . . . . . . .
2.5.1 Certificat X.509 : La carte d’identité numérique
2.5.2 La relation de confiance . . . . . . . . . . . . .
2.5.3 PKI : La confiance via un tiers . . . . . . . . .
2.6 TLS : le protocole en détail . . . . . . . . . . . . . . .
2.6.1 Les messages d’extension . . . . . . . . . . . .
2.6.2 TLS Record Protocol . . . . . . . . . . . . . .
2.6.3 Handshake Protocol . . . . . . . . . . . . . . .
2.6.4 Alert Protocol . . . . . . . . . . . . . . . . . .
2.6.5 Change Cipher Spec Protocol . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

8
8
8
9
9
9
10
11
12
13
14
15
17
17
17
19
22
22

3 L’interception TLS
3.1 L’interception TLS sortante . . . . . . . . .
3.1.1 Le placement du proxy TLS . . . . .
3.1.2 Une autorité de certification interne
3.2 L’interception TLS entrante . . . . . . . . .
3.2.1 Le placement du proxy TLS . . . . .
3.2.2 Hébergement des clefs privées . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

23
24
25
25
26
27
27

II

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

Des Enjeux et Des Risques

28

4 L’origine du chiffrement des échanges

29

5 Aspect technique
5.1 Enjeux sécuritaires . . . . . . . . . . . .
5.1.1 Les pare-feux nouvelle génération
5.1.2 Utilisation d’un proxy . . . . . .
5.1.3 Journalisation des connexions . .
5.2 Risques : les contraintes techniques . . .
5.2.1 La performance . . . . . . . . . .

Edouard Petitjean — M2 MIAGE SIID

. . . . . .
: l’analyse
. . . . . .
. . . . . .
. . . . . .
. . . . . .

. . . . .
poussée
. . . . .
. . . . .
. . . . .
. . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

31
31
31
32
32
33
33

2

SOMMAIRE - SOMMAIRE

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

34
36
37
38

6 Une législation complexe
6.1 Un chiffrement libre sous condition . . . . . . . . . . . . . .
6.2 Les obligations légales . . . . . . . . . . . . . . . . . . . . .
6.2.1 Données personnelles : la protection quoiqu’il arrive
6.2.2 L’interception TLS dans la protection des données .
6.2.3 La responsabilité en cas de crime ou délit . . . . . .
6.2.4 L’obligation d’une journalisation . . . . . . . . . . .
6.2.5 La loi HADOPI . . . . . . . . . . . . . . . . . . . . .
6.2.6 Interception dans le cadre judiciaire . . . . . . . . .
6.3 La légalité de l’interception TLS . . . . . . . . . . . . . . .
6.3.1 Des atteintes aux secrets . . . . . . . . . . . . . . . .
6.3.2 La sous-traitance . . . . . . . . . . . . . . . . . . . .
6.3.3 Atteinte au STAD ? . . . . . . . . . . . . . . . . . .
6.4 Récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

39
39
40
40
40
41
42
42
42
43
43
44
44
44

5.3

5.2.2 L’interception . . . . . . .
5.2.3 Les protections des clients
5.2.4 La protection des serveurs
Récapitulatif . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

7 L’impact sociologique
46
7.1 La destruction de la relation de confiance . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2 Une surveillance en trop ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.3 La nécessité d’informer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

III

Quelques bonnes pratiques

48

8 Des réflexes à avoir
9 La mise en oeuvre technique
9.1 L’interception sortante . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.1 Gestion de l’AC interne . . . . . . . . . . . . . . . . . . . . . . .
9.1.2 Protection des clefs privées . . . . . . . . . . . . . . . . . . . . .
9.1.3 Sécurité des connexions entre les clients internes et le proxy TLS
9.1.4 Sécurité des connexions entre le proxy TLS et les serveurs . . . .
9.1.5 Protection de la vie privée . . . . . . . . . . . . . . . . . . . . . .
9.2 L’interception entrante . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Sécurisation entre les clients externes et le reverse proxy TLS . .
9.2.2 Protection des clefs privées . . . . . . . . . . . . . . . . . . . . .

49

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

50
50
50
50
50
51
51
51
51
52

10 Informations et obligations légales
53
10.1 Vis à vis des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.2 Rappel sur l’obligation des administrateurs . . . . . . . . . . . . . . . . . . . . . . . . . 53
11 Conclusion

Edouard Petitjean — M2 MIAGE SIID

54

3

Première partie

L’interception SSL

Edouard Petitjean — M2 MIAGE SIID

4

Chapitre 1

Quelle différence entre SSL et TLS ?
Avant de commencer à expliquer le fonctionnement du protocole, l’article va traiter de la différence
entre SSL 1 et TLS 2 . Ceci afin d’éviter toutes confusions sur la suite de ce texte.

1.1

Historique du SSL et du TLS

Pour la petite histoire, le SSL fut créé par Netscape en 1994. Baptisée « SSL 1.0 », cette version
resta dans le domaine de la théorie. C’est en 1995 avec l’arrivée du « SSL 2.0 » que le protocole fut
utilisé. Mais cette version présentait plusieurs failles, par conséquent, la version « SSL 3.0 » fut créée
en 1996. Avec cette nouvelle version, et une nouvelle RFC 3 (6101), le protocole devint de plus en
plus utilisé et permet une nouvelle utilisation d’internet. Notamment, l’émergence du e-commerce est
fortement due à la sécurisation des connexions que procurait le « SSL 3.0 ».
En janvier 1999, un nouveau protocole fut défini, le « TLS 1.0 » mais par l’IETF 4 et non plus par
Netscape. Ce « nouveau » protocole découle directement du « SSL 3.0 », au point où le numéro de
version de « TLS 1.0 » est 3.1 : « SSL 3.1 ». La structure reste la même, seules quelques fonctionnalités
liées à la cryptographie sont améliorées. Ces modifications empêchent une compatibilité directe entre
le « SSL 3.0 » et le « TLS 1.0 », mais ce dernier à la capacité de basculer en « SSL 3.0 » selon le besoin.
Ce qui permet au TLS de se déployer petit à petit tout en gardant l’utilisation du SSL possible. Par
la suite, le TLS va subir des modifications afin qu’il soit plus sécurisé et plus abouti. On peut noter le
support du Kerberos 5 , de l’AES 6 ou encore du SNI 7 .
Par la suite, les versions « TLS 1.1 » (2006) et « TLS 1.2 » (2008) furent créées, chacun apportant
son lot d’amélioration et surtout de sécurisation dans l’établissement du canal entre le client et le
serveur. De nos jours, seules les versions « TLS 1.1 » et « TLS 1.2 » sont épargnées de vulnérabilité
connue. La version « TLS 1.0 » fut victime de BEAST 8 , ce sont les navigateurs qui permettent la
protection contre cette attaque. Par conséquent, le « TLS 1.0 » est considéré comme vulnérable même
si c’est le protocole le plus utilisé à ce jour. Le graphique fig. 1.1 p.6 9 présente l’évolution d’utilisation
des différents protocoles entre 2014 et 2016.

1.2

Obsolescence du SSL

Comme nous l’avons vu précédemment, les versions « SSL 2.0 » et « SSL 3.0 » datent respectivement
de 1995 et 1996. La première fut remplacée à cause des vulnérabilités découvertes. Par conséquent, la
RFC 6176 créée en 2011, prohibe l’utilisation de cette version.
1. Secure Socket Layer, protocole permettant de créer un canal d’échange sécurisé entre un client et un serveur.
2. Transport Layer Security, protocole permettant de créer un canal d’échange sécurisé entre un client et un serveur.
Successeur du SSL.
3. Request for comments : document décrivant un aspect technique
4. Internet Engineering Task Force : regroupement de personnes créant des RFC
5. Protocole d’authentification et d’autorisation basé sur des tickets
6. Advanced Encryption Standard : protocole de chiffrement symétrique
7. Server Name Indication : extension TLS permettant d’annoncer le CommonName du certificat à demander
8. Browser Exploit Against SSL/TLS : attaque via injection de cookie pour détourner une session SSL/TLS
9. Source : https://www.trustworthyinternet.org/ssl-pulse/

Edouard Petitjean — M2 MIAGE SIID

5

Quelle différence entre SSL et TLS ? - Obsolescence du SSL

Figure 1.1 – Evolution d’utilisation des protocoles entre 2014 et 2016

Edouard Petitjean — M2 MIAGE SIID

6

Quelle différence entre SSL et TLS ? - Un abus de langage historique

Néanmoins, elle n’est pas la seule impactée, en effet, suite à l’attaque POODLE 10 (2014), la version
« SSL 3.0 » fut considérée comme peu sûre et une RFC (7568) mit la version au statut « désapprouvé »
en 2015.
Par conséquent, depuis 2015, tout système informatique qui se respecte devrait avoir supprimé
toute utilisation des versions SSL.

1.3

Un abus de langage historique

Pourquoi le terme de SSL est encore très présent dans le monde informatique alors que depuis 2015,
les versions SSL ne devraient plus être utilisées ?
Cet abus de langage de nos jours est surtout historique. En effet, alors même que les versions
TLS se développaient, énormément de serveurs présentèrent du « SSL 3.0 ». Beaucoup l’utilisèrent
encore à cause de la méconnaissance des administrateurs de l’époque. En effet, il n’est pas évident de
comprendre par exemple la numérotation de version du TLS qui reprend celle du SSL dans les échanges
alors que le protocole est défini avec d’autres numéros. Le SSL et le TLS utilisent des notions, que
nous verrons par la suite, qui ne sont pas simples à appréhender. Aussi, dans certains domaines comme
le e-commerce, il était compliqué de s’aventurer dans la migration d’un protocole de sécurisation que
peu de personnes maîtrisaient, et surtout où aucune attaque sérieuse n’avait été découverte. Ce n’est
qu’en 2014 suite aux attaques BEAST et POODLE que les entreprises ont compris que même si un
protocole permettait de sécuriser une connexion, celui-ci peut lui-même être vulnérable.
Dans la suite de cet article, le terme SSL sera supprimé pour ne garder que le terme TLS.

10. Padding Oracle On Downgraded Legacy Encryption : attaque utilisant le « downgrade dance » et exploite le
manque de vérification du « SSL 3.0 »

Edouard Petitjean — M2 MIAGE SIID

7

Chapitre 2

TLS : un protocole compliqué ?
Afin de bien comprendre comment fonctionne l’interception TLS, il est déjà important de bien
comprendre ce qu’est le TLS.

2.1

Les objectifs du TLS

Le TLS a été développé pour répondre à 3 fonctions bien identifiées :
Authentification : Le TLS a pour but de fournir une garantie de l’identité d’un serveur à un client.
Optionnellement, le TLS peut également assurer l’identité du client auprès du serveur. Cette
fonction sera assurée par des algorithmes cryptographiques basés sur des clefs asymétriques et
de certificats numériques. Actuellement, c’est l’emploi de certificat X.509 1 qui est utilisé pour
authentifier les serveurs.
Confidentialité : Le TLS va s’assurer que les communications entre un client et un serveur ne puissent
être comprises par un tiers. Un algorithme de chiffrement à base de clefs hybrides fournit cette
confidentialité. Un système à base de clefs asymétriques permettra l’échange des clefs de symétriques, qui elles, permettront le chiffrement des données.
Non répudiation et intégrité : Le TLS doit gérer l’intégrité des données 2 échangées et vérifier de
façon certaine l’émetteur des données. La signature des données sera utilisée pour remplir cette
fonction.

2.2

Le positionnement du TLS dans le modèle TCP/IP

Savoir positionner un protocole sur des modèles comme OSI ou TCP/IP peut paraître négligeable,
pourtant, savoir positionner un protocole permet de mieux comprendre son utilité et sa définition.
Le TLS fut conçu pour répondre à un besoin de sécurisation des applications ayant une architecture
basée sur le modèle « client-serveur 3 ». De ce fait, le protocole TLS est donc lui-même basé sur un
modèle client-serveur. Mais attention, le TLS ne fait pas partie de la couche application du modèle
TCP/IP. le TLS aura pour but de créer un canal d’échange sécurisé pour une application donnée, mais
ne va pas agir ou formater des données comme le ferait une application. Il en ressort donc qu’il agit
plus comme un protocole de transport qu’un protocole applicatif. Néanmoins, il n’est pas non plus
un protocole de transport à proprement parler. Puisqu’il se base sur le protocole TCP pour échanger
entre deux hôtes. De plus, le TLS permet également une gestion des sessions TLS entre deux hôtes
(que nous verrons par la suite). Or, cette gestion de la session est complètement indépendante à la fois
de la session de l’application encapsulée, que de la session TCP. Par conséquent, nous pouvons placer
le TLS entre les couches 3 et 4 du modèle TCP/IP. Il encapsule mais ne transporte pas, et ne gère pas
à proprement parler des données. La figure fig. 2.1 p.9 donne une représentation du modèle TCP/IP
avec la position du TLS.
1. Certificat qui base sa validité sur une autorité centralisée hiérarchisée.
2. L’intégrité des données permet de garantir que les données n’ont subi aucune modification (intentionnelle ou non)
3. Modèle basé sur une entité mettant à disposition des ressources, et une multitude de tiers venant accéder ces
ressources.

Edouard Petitjean — M2 MIAGE SIID

8

TLS : un protocole compliqué ? - Un protocole fortement évolutif

Figure 2.1 – SSL sur le modèle TCP/IP

2.3

Un protocole fortement évolutif

Le TLS à une très forte capacité évolutive. Comme vu précédemment, le TLS va utiliser des moyens
cryptographiques pour remplir ses objectifs. Or, même si ces derniers sont essentiels au TLS, celui-ci
n’est pas dépendant d’algorithme de chiffrement précis. Aussi, tant qu’un algorithme reste compatible
avec les besoins du TLS, celui-ci pourra être utilisé par ce dernier. Par conséquent, il est relativement
simple pour TLS d’ajouter ou supprimer le support d’un algorithme pour augmenter la sécurité.
Par ailleurs, la structure du TLS se base sur un système d’extension permettant de rajouter des
fonctionnalités sans pour autant devoir à modifier la structure du protocole. L’avantage de cette architecture permet d’assurer une interopérabilité minimale entre un client et un serveur même s’ils ne
supportent pas les mêmes extensions. Ce service minimum regroupe bien entendu les trois objectifs
vus précédemment. A titre d’information, nous pouvons citer le SNI ou l’ALPN 4 comme extensions
utiles. Mais leur non-support ne présente aucune incidence majeure sur le protocole TLS lui-même.

2.4

Rappel cryptographique

Avant d’aller plus loin, il est important de procéder à quelques rappels de base sur la cryptographie.
Le protocole TLS va utiliser plusieurs notions cryptographiques différentes qui se compléteront entre
elles afin de fournir un niveau de sécurité acceptable. Le but de cette section n’étant pas de voir en
détail les algorithmes existants et utilisés, mais de comprendre les différentes notions cryptographiques
qui sont utilisées par le TLS.

2.4.1

Chiffrement symétrique

Le chiffrement symétrique est un moyen de chiffrement qui utilisera la même clef pour chiffrer
et déchiffrer les données. Cela repose sur un secret partagé entre toutes les identités ayant besoin
d’échanger des données de façon sécurisée.
4. Application Layer Protocol Negotiation : Extension TLS permettant d’annoncer le protocole transporté par TLS.

Edouard Petitjean — M2 MIAGE SIID

9

TLS : un protocole compliqué ? - Rappel cryptographique

Soit,
m : le message
e : le message chiffré
k : la clef symétrique
c : la fonction de chiffrement
d : la fonction de déchiffrement
alors,
e = ck (m)
m = dk (e)
et,
m = dk (ck (m))
Ce type de chiffrement ne permet pas d’assurer que la confidentialité des données. À aucun moment il n’est possible de s’assurer de l’identité de l’expéditeur d’un message, ni même de fournir une
garantie de l’intégrité du message. Pourtant, le chiffrement symétrique a deux atouts majeurs dans
son utilisation. La première est le faible coût en ressource qu’il nécessite comparé à un algorithme
asymétrique. D’autre part, les algorithmes symétriques sont plus complexes et donc plus sécurisés.
Pour finir, la principale faiblesse dont souffre le chiffrement symétrique est de savoir comment
échanger les différentes clefs entre les différentes identités, sans que celles-ci ne puissent être interceptées
par un tiers n’étant pas dans la confidentialité.

2.4.2

Chiffrement asymétrique

Les algorithmes de chiffrement symétrique ont la particularité d’avoir plusieurs rôles. En plus de
pouvoir assurer la confidentialité en chiffrant les données, ils ont la capacité de générer leurs propres
clefs ainsi que de pouvoir « signer » les données, répondant aux besoins de non répudiation et d’intégrité
du TLS.
La plus grosse différence avec le chiffrement symétrique est l’utilisation d’une paire de clefs par
identité. Chaque identité aura deux clefs, une dite publique et la seconde dite privée.
La clef publique sera annoncée à quiconque voulant s’adresser à son propriétaire. Elle servira à la
fois à chiffrer les données qui devront être envoyées à son possesseur, ainsi qu’à la vérification de la
signature envoyée.
La clef privée sera toujours gardée secrète par son propriétaire. C’est celle-ci qui permettra de
déchiffrer les données reçues. Donc le principe de confidentialité est lié au fait que l’identité à destination
du message soit la seule à pouvoir en comprendre le sens. La clef privée sera également utilisée pour
signer un message envoyé, de ce fait, le destinataire du message pour vérifier l’identité de l’expéditeur
en vérifiant la signature via la clef publique de l’expéditeur.

Edouard Petitjean — M2 MIAGE SIID

10

TLS : un protocole compliqué ? - Rappel cryptographique

Soit,
kpub : la clef publique
kpri : la clef privée
m : le message
e : le message chiffré
s : la signature du message envoyé
c : la fonction de chiffrement
d : la fonction de déchiffrement
alors pour chiffrer,
e = ckpub (m)
m = dkpri (e)
et pour signer,
s = ckpri (m)
m = dkpub (m)
Ce type d’algorithme propose clairement un principe de confidentialité plus important que le chiffrement symétrique, dans le sens où un message sera chiffré autant de fois qu’il y aura de destinataires.
Également, en se basant sur un couple de clefs dont une est publique, le problème de communication
des clefs de chiffrement ne se pose plus. Alors pourquoi TLS utilise-t-il le chiffrement symétrique ?
Pour commencer, comme évoqués précédemment, les algorithmes asymétriques reposent sur des
notions mathématiques simples. En effet, tous vont se reposer à la base sur un couple de nombres
premiers, où leur multiplication sera annoncée de façon publique. Aussi, savoir factoriser un nombre
en nombres premiers permet de « casser » la sécurité de ces algorithmes. Pour pallier cela, ces derniers
utilisent maintenant des nombres très grands. De nos jours, il est courant que ces nombres utilisent une
longueur de 2048 bits, soit des nombres avec plus de 600 décimales ! Si les algorithmes asymétriques
sont encore utilisés de nos jours, cela est uniquement dû à l’incapacité technique et mathématique à
factoriser des nombres si grands en des temps raisonnables 5 .
En reprenant le point précédent, les clefs des algorithmes asymétriques sont donc très grandes. Or,
il n’est pas aisé, même en informatique, de faire des calculs avec des nombres si grands. Cela demande
des algorithmes mathématiques spécifiques pour la gestion de la mémoire, mais aussi, des ressources
très importantes, contrairement au chiffrement symétrique.
Néanmoins, les algorithmes de chiffrement ont deux rôles majeurs, le premier, assurer l’identité
et l’intégrité des messages. Mais également de palier au principal défaut du chiffrement symétrique :
l’échange des clefs. En effet, les algorithmes asymétriques seront utilisés pour chiffrer, non pas de la
donnée directement, mais les clefs symétriques afin de pouvoir les échanger en toute quiétude.
A ce stade, il est important de faire attention à une autre limite des algorithmes asymétriques. Ils
permettent de signer un message pour s’assurer l’identité de l’expéditeur, mais cette fonctionnalité a
l’inconvénient de rendre le message lisible par tous et ne permettant plus d’assurer la confidentialité.
Les fonctions utilisées pour signer le message et vérifier la signature sont les mêmes que pour chiffrer et
déchiffrer le message. Par conséquent, en envoyant la signature, qui n’est rien d’autre que le message
chiffré avec la clef privée de l’expéditeur, n’importe qui pourrait prendre connaissance du message en
déchiffrant la signature avec la clef publique de cet expéditeur.

2.4.3

Empreinte numérique

Une empreinte numérique est une représentation chiffrée d’un message. Elle s’effectue au travers
d’un algorithme de chiffrement irréversible aussi dit « hash ». Cela veut dire deux choses :
1. En utilisant un même algorithme, une donnée aura toujours la même empreinte numérique,
5. Nous parlons de temps raisonnable lorsque la durée de factorisation est inférieure à la durée de vie de l’information
à déchiffrer

Edouard Petitjean — M2 MIAGE SIID

11

TLS : un protocole compliqué ? - Authentification : un principe de confiance

2. Il n’existe aucun algorithme permettant de retrouver une donnée à partir de son empreinte
numérique 6 .
Soit,
m : le message
h : l’empreinte numérique du message
alors,
h = Hash(m)

Cette particularité d’irréversibilité sera utilisée par TLS pour combler le défaut de la signature des
messages. Aussi, ça ne sera plus le message lui-même qui sera chiffré pour servir de signature, mais
l’empreinte numérique de celui-ci. Aussi, peu importe si les personnes peuvent déchiffrer la signature, le
résultat sera l’empreinte du message. Et par conséquent, impossible de retrouver le message. Pour ce qui
en est du destinataire, celui-ci fera une comparaison de l’empreinte numérique reçue, avec l’empreinte
numérique du message qu’il aura déchiffré avec sa propre clef privée.
Soit,
Alicepub : la clef publique d’Alice
Alicepri : la clef privée d’Alice
Bobpub : la clef publique de Bob
Bobpri : la clef privée de Bob
m : le message
e : le message chiffré
s : la signature du message envoyé
c : la fonction de chiffrement
d : la fonction de déchiffrement
Alice envoie un message à Bob,
e = cBobpub (m)
s = cAlicepri (Hash(m))
Bob reçoit le message,
m = dBobpri (e)
h = Hash(m)
h0 = dAlicepub (s)

Si h et h0 sont identiques, Bob prend en compte le message et sait qu’il vient d’Alice.
Pour finir avec ce rappel, en combinant ces 3 types d’algorithmes de chiffrement, TLS peut répondre
à deux de ses objectifs principaux : « Confidentialité » et « non répudiation et intégrité ».

2.5

Authentification : un principe de confiance

Le dernier objectif auquel TLS doit répondre est « l’authentification ». Mais pas n’importe laquelle.
Puisque le TLS est censé répondre à un comportement de « client-serveur », il doit pouvoir permettre
aux clients d’authentifier de façon sûre le serveur à joindre. L’authentification des clients est également
6. Nous ne prendrons pas en compte les diverses attaques par collisions permettant de retrouver éventuellement une
donnée.

Edouard Petitjean — M2 MIAGE SIID

12

TLS : un protocole compliqué ? - Authentification : un principe de confiance

Figure 2.2 – Structure d’un certificat X.509
prévue par le TLS mais d’une manière optionnelle, aussi, seule la présentation de l’authentification du
serveur sera expliquée.
Comme dit précédement, les systèmes à chiffrement asymétrique permettent de répondre au besoin
d’« identification ». Or, quelle est la différence entre « identification » et « authentification » ? Dans le
cas présent, le premier va permettre de s’assurer qu’un message a bien été envoyé à partir d’une clef
privée précise (conjointe de la clef publique connue). Mais nous nous retrouvons dans un problème de
sécurité important : comment peut-on être sûr de l’identité derrière ce couple de clefs ? En reprenant
l’exemple d’Alice et Bob, comment Alice peut-elle être sûre que c’est bien Bob qui soit derrière la clef
publique ? Inversement, comment Bob peut s’assurer que c’est Alice qui lui envoie un message ? C’est
là qu’intervient le principe d’« authentification » : s’assurer de l’identité derrière une clef publique.
Cette partie d’« authentification » va être gérée par un certificat. Le rôle d’un tel certificat est de
jouer la carte d’identité numérique.

2.5.1

Certificat X.509 : La carte d’identité numérique

Un certificat X.509 suit une structure spécifique décrite dans la RFC 5280. Elle se compose de
champs basiques, et de champs d’extensions. Cela permet une véritable évolutivité de ce type de
certificat, au même titre que le TLS. En effet, l’utilisation d’extension permet de rajouter des rôles à ce
type de certificat, sans pour autant perturber l’objectif de base qui est d’authentifier son propriétaire.
Par ailleurs, le certificat sera signé par une AC 7 . La figure fig. 2.2 p.13 montre la structure d’un
certificat X.509.
Un certificat signé est donc conçu de trois champs majeurs :
7. Autorité de Certification : est une entité ayant pour rôle de délivrer des certificats et d’attester de l’identité précise
derrière ces certificats

Edouard Petitjean — M2 MIAGE SIID

13

TLS : un protocole compliqué ? - Authentification : un principe de confiance

• Un certificat regroupant toutes les informations permettant d’établir l’identité publique de son
propriétaire.
• L’algorithme de signature utilisé par l’AC, défini dans le certificat, pour signer ledit certificat. Ce champ sera généralement défini par deux algorithmes : un algorithme de hash 8 et un
algorithme asymétrique.
• La valeur de la signature qui sera utilisée pour confirmer la relation de confiance entre le
certificat et l’AC.
Le certificat est donc défini par :
• Version : désigne un numérique, utilisé selon l’implémentation visée du certificat.
• Numéro de série : un numéro qui doit être unique parmi tous les certificats délivrés par une
AC. Le but étant que le couple d’information (numéro de série, AC) doit être unique pour tous
certificats.
• Signature : désigne les algorithmes utilisés par l’AC pour créer la signature. Ce champ doit être
identique à « L’algorithme de signature » vu précédemment.
• Émetteur : est le DN 9 (Distinguished Name) de l’AC qui a signé et délivré le certificat.
• Validité : va définir une date de début et de fin pour le certificat.
• Sujet : est le DN pour lequel le certificat a été créé. Souvent, le CN 10 du DN sera le nom de
domaine pour lequel le certificat a été créé.
• Info clef publique du sujet : contient deux champs, l’un contient la clef publique, l’autre
indique les algorithmes qui seront utilisés avec la clef de chiffrement.
• Identifiant unique émetteur/sujet : sont deux champs optionnels. Ils permettent de donner
un deuxième nom à l’émetteur ou au sujet, si le premier peut-être commun à plusieurs AC.
• Extensions : va regrouper plusieurs champs qui définiront des paramètres optionnels. En règle
général, ces paramètres ont pour but de faciliter et optimiser la gestion des certificats. Une des
extensions la plus utile est sans doute le « Noms alternatifs de sujet de certificat » qui permet
de rendre le certificat compatible avec plusieurs noms de domaines, au lieu d’un seul à la base.

2.5.2

La relation de confiance

Maintenant, voyons comment l’utilisation d’un certificat peut permettre d’accéder à un site web
sécurisé (fig. 2.3 p.14). C’est le cas le plus classique et le plus simple à comprendre. Dans ce schéma,
la signature d’une AC ne sera pas prise en compte.

Figure 2.3 – Echange avec un serveur utilisant un certificat non signé
Dans cet exemple simple, la relation de confiance entre le client et le serveur est très forte. En effet,
le client ne va reposer sa confiance que sur la correspondance entre le nom de domaine qu’il a demandé
8. Un algorithme de chiffrement irréversible permettant de générer une empreinte numérique
9. Distinguished Name : l’identifiant unique d’un objet situé dans un ensemble de données hiérarchisé (ex : LDAP).
Le DN d’un objet est aussi appelé le chemin de l’objet.
10. Common Name : nom commun d’un objet dans un ensemble de données hiérarchisé. Permet d’appeler rapidement
un objet quand le CN est unique.

Edouard Petitjean — M2 MIAGE SIID

14

TLS : un protocole compliqué ? - Authentification : un principe de confiance

et le sujet du certificat qu’il aura reçu. Or, cette forte confiance pose un problème majeur : comment
repérer une usurpation d’identité ? Prenons le cas d’un serveur malveillant qui serait configuré pour
répondre au même nom de domaine que notre exemple, soit « www.edouard.petitjean.com ». Celuici proposerait également un certificat valide pour le nom « www.edouard.petitjean.com » mais avec
une clef publique complètement différente. Dans ce cas, comment Bob peut s’assurer de communiquer
avec le bon serveur et non pas le malveillant ? Dans le contexte de l’exemple, c’est impossible. Pour
pallier ce défaut, un système basé sur plusieurs relations de confiance fut pensé : la PKI (Public Key
Infrastructure).

2.5.3

PKI : La confiance via un tiers

Le système de PKI a été pensé pour renforcer la confiance qu’un client peut avoir envers un certificat.
Le principe de base est simple et se repose sur une chaîne de relation de confiance. Lorsqu’un client
voudra vérifier l’authenticité d’un certificat, il vérifiera l’entité qui l’a signé (l’entité s’engage donc sur
l’authenticité du certificat). Si cette entité fait partie de la liste de confiance du client, alors le client
fera confiance au certificat.
Pour cela, la PKI à plusieurs fonctions : la création, le renouvellement et la publication des certificats, gérer une liste de révocation et la publier pour définir les certificats n’étant plus de confiance.
Pour remplir ses fonctions, une PKI reposera sur plusieurs entités :
• Autorité de certification (AC) : signe les demandes de certificats (CSR 11 ) et gère la liste de
révocation. Cette entité est la plus critique car les clients en ont besoin pour vérifier les certificats.
Il est aussi important de noter que dans les PKI publiques, il existe des AC racines et des AC
intermédiaires. Les clients font confiance aux AC racines mais afin de se protéger 12 , ces dernières
vont déléguer la signature de certificats à une ou plusieurs AC intermédiaires.
• Autorité d’enregistrement (AE) : vérifie les informations sur l’identité des propriétaires de
certificats.
• Autorité de dépôt : stocke les certificats et les listes de révocation.
• Entité finale (EE : End Entity) : est l’entité qui va utiliser le certificat (serveur web, mail,
client, etc...).
• Autorité de séquestre 13 : stocke les clefs privées liées aux certificats.
Le schéma fig. 2.4 p.16 montre en détail le déroulement des étapes qui sont effectuées pour que la
relation de confiance entre un serveur et un client soit à l’oeuvre.
Ce schéma n’est pas exhaustif dans l’ensemble des vérifications qui sont réellement faites dans la
réalité, mais il donne une bonne image du mécanisme de confiance qui est mis en jeu. En effet, avec
l’ajout d’une entité tierce, les clients ne font pas confiance au serveur directement, mais aux entités qui
ont attesté de l’identité du serveur. Aussi, les risques qu’un serveur malveillant se fasse passer pour
un serveur légitime sont très limités, car il existe peu de chance qu’il parvienne à avoir une signature
d’une AC de confiance.

11. Certificate Signing Request : requête envoyée à une AC pour signer un certificat. L’AC renvoie un nouveau certificat
avec sa signature.
12. La protection évoquée ici est la mise hors ligne de l’AC racine. Celle-ci est remise en ligne uniquement pour la
création d’une AC intermédiaire.
13. Contrairement aux quatre précédents, cette entité n’est pas définie par l’IETF.

Edouard Petitjean — M2 MIAGE SIID

15

TLS : un protocole compliqué ? - Authentification : un principe de confiance

Figure 2.4 – Echange avec un serveur utilisant un certificat signé

Edouard Petitjean — M2 MIAGE SIID

16

TLS : un protocole compliqué ? - TLS : le protocole en détail

2.6

TLS : le protocole en détail

Comme dit précédemment, le TLS est un protocole à mi-chemin entre le transport et l’applicatif.
Cette ambiguïté est fortement marquée quand nous regardons de plus près les spécifications détaillées
dans la RFC 5246. Le TLS communique entre le client et le serveur au travers de 4 types de messages
principaux différents (appelés aussi high-level) :
• Handshake protocol : permet d’échanger sur les algorithmes de chiffrements qui seront utilisés,
mais également sur les différentes valeurs pour générer les clefs de chiffrement. L’authentification
des parties via un certificat est gérée par ce type de message, et est considérée comme optionnelle.
Néanmoins, dans le contexte de cet article, l’authentification du serveur sera considérée comme
obligatoire.
• Alert protocol : est en charge de la notification d’erreurs repérées lors d’un échange TLS.
• Change cipher spec protocol : notifie une volonté de changer les algorithmes de chiffrement
utilisés pour une session TLS en cours.
• Application data protocol : contient la charge utile du TLS, c’est-à-dire, les données applicatives chiffrées.
Et un dernier pour les transporter tous : le TLS Record Protocol qui a pour rôle d’annoncer et
encapsuler les différents messages du protocole.

2.6.1

Les messages d’extension

Il existe d’autres types de message mais qui sont liés à des extensions TLS. Ces messages permettent
d’ajouter des paramètres lors de l’établissement d’une session TLS. Pour exemple, il existe le type
de message CertificateURL qui permet, lors de l’authentification du client, que celui-ci n’envoie pas
un certificat, mais une URL vers un certificat pour l’authentifier. Cet article ne s’attardera pas sur
ces messages annexes, mais il est important de connaître leur existence pour comprendre certaines
problématiques de l’interception TLS qui seront abordées dans d’autres chapitres.

2.6.2

TLS Record Protocol

Le TLS Record Protocol a plusieurs rôles à son actif qui seront tous décrits :
• La gestion des états des connexions
• La fragmentation des données
• La compression et décompression des données
• Le chiffrement des données envoyées
La gestion des états de connexions
C’est un concept important dans le TLS. Pour rappel, le TLS va utiliser un chiffrement asymétrique
en début de session puis par la suite utiliser un chiffrement symétrique. Or, une des attaques les plus
fréquentes contre ce genre de chiffrement est l’analyse de fréquence et l’attaque par message connu.
Pour faire simple, un même message chiffré avec la même clef donnera fatalement le même message
chiffré. Or, le TLS chiffre des informations provenant de diverses applications, qui elles-mêmes utilisent
un formalisme pour la présentation des données. Par conséquent, les en-têtes des messages applicatifs
sont souvent les mêmes et font des cibles parfaites pour l’attaque par message connu. Pour pallier cela,
il est important de changer régulièrement la clef de chiffrement afin de limiter le nombre de messages
chiffrés avec la même clef. TLS propose donc de découper une session en plusieurs connexions à état.
C’est-à-dire que chaque connexion aura son propre environnement — les valeurs qui permettent la
création des clefs de chiffrement symétrique changeront entre chaque connexion.
Pour cela, le client et le serveur vont générer une structure de données, appelée SecurityParameters(fig. 2.5 p.18), qui établira le contexte de la connexion.
Cette structure s’instancie suite aux premiers échanges entre le client et le serveur à travers des
messages Handshake protocol. Nous y reviendrons en détail par la suite.
Une fois cette structure remplie, les champs prf_algorithm, master_secret, client_random et server_random seront utilisés pour générer six nouvelles clefs :
Edouard Petitjean — M2 MIAGE SIID

17

TLS : un protocole compliqué ? - TLS : le protocole en détail

struct {
ConnectionEnd
PRFAlgorithm
BulkCipherAlgorithm
CipherType
uint8
uint8
uint8
uint8
MACAlgorithm
uint8
uint8
CompressionMethod
opaque
opaque
opaque
} SecurityParameters ;

entity ;
prf_algorithm ;
bulk_cipher_algorithm ;
cipher_type ;
enc_key_length ;
block_length ;
fixed_iv_length ;
record_iv_length ;
mac_algorithm ;
mac_length ;
mac_key_length ;
compression_algorithm ;
master_secret [ 4 8 ] ;
client_random [ 3 2 ] ;
server_random [ 3 2 ] ;

Figure 2.5 – Définition de SecurityParameters dans la RFC5246
struct {
ContentType type ;
ProtocolVersion version ;
uint16 length ;
opaque fragment [ TLSPlaintext . l e n g t h ] ;
} TLSPlaintext ;
Figure 2.6 – Définition de TLSPlaintext dans la RFC5246
— client write MAC key
— server write MAC key
— client write encryption key
— server write encryption key
— client write IV
— server write IV
Ce sont ces six clefs qui seront utilisées pour chiffrer et signer les messages. Les clefs client write
seront utilisées par le serveur quand il recevra des messages du client, tandis que le client utilisera les
clefs server write. Une fois ces clefs générées, l’échange de message chiffré pourra se faire. Pour finir,
chaque connexion se verra attribuer un identifiant unique appelé sequence number
Record Layer
C’est la couche en charge du transport des données TLS. Pour que le client et le serveur puissent
comprendre les données TLS, celles-ci doivent être formatées de façon précise. Notamment, le TLS
utilise une notion de message de base (TLS record Protocol) et de message high-level, or ces derniers
seront eux-mêmes encapsulés dans des messages de base. Le formatage des données va respecter la
structure TLSPlaintext (fig. 2.6 p.18) définie par la RFC5246.
A ce stade, il est important de comprendre chaque attribut de cette structure.
• type : est un champ sur 1 octet qui permet de définir le type de message qui sera contenu dans
fragment. Ce champ peut prendre les valeurs suivantes :
— 20 : change_cipher_spec
— 21 : alert
— 22 : handshake
Edouard Petitjean — M2 MIAGE SIID

18

TLS : un protocole compliqué ? - TLS : le protocole en détail

— 23 : application_data
• version : est un champ composé de 2 octets représentant respectivement la version majeure et
mineure du protocole utilisé. Le passage de SSL à TLS rend ce champ peu instinctif pour ceux
ne connaissant pas l’historique. Ce champ peut prendre les valeurs suivantes :
— 2 et 0 : SSL 2.0
— 3 et 0 : SSL 3.0
— 3 et 1 : TLS 1.0
— 3 et 2 : TLS 1.1
— 3 et 3 : TLS 1.2
• length : est un champ sur 2 octets donnant la taille du buffer stocké dans fragment. Cette valeur
ne pas excéder 214 , taille maximale pour fragment
• fragment : est un buffer contenant la charge utile. C’est-à-dire les messages high-level.
La fragmentation de fragment.
La taille maximale prévue pour le buffer fragment est de 214 octets. Il est rare que toutes les
données d’un message puissent être stockées dans un buffer de cette taille. Par conséquent, le TLS
record Protocol va procéder à la fragmentation des données, puis envoyer plusieurs messages TLS. Par
la suite, le correspondant récupérera tous ces fragments puis les concaténera pour reformer le message
envoyé.
La compression des messages
Elle permet de réduire la taille de la charge utile à travers le TLS. Même si la compression n’est pas
utilisée, la structure TLSPlaintext sera transformée en une structure TLSCompressed. Les attributs de
la structure ne changent pas. Mais son utilisation apporte quelques changements quant à la structure
utilisée pour échanger des messages. La taille limite du buffer fragment (qui est donc de la donnée
compressée) est de 214 + 1024. Afin de prendre en compte l’en-tête lié à l’algorithme de compression
utilisé. Mais il existe aussi une vérification lors de la décompression. Si la donnée décompressée dépasse
les 214 octets, alors TLS générera une erreur fatale et mettra fin à la connexion en cours.
La protection de fragment
Elle va procéder au chiffrement de fragment. Comme précédemment, la structure va changer et
devenir une structure TLSCiphertext. Cette fois, la taille limite de fragment passe à 214 + 2048 octets.
De plus, fragment ne contiendra plus la donnée (compressée ou non), mais la donnée chiffrée ainsi
que la signature MAC. Cette dernière sera un hash créé à partir de la MAC write key, ainsi que de
la concaténation des éléments suivants : sequence number de la connexion, type, version, length et
fragment. Après cette dernière étape, le message est envoyé au correspondant.

2.6.3

Handshake Protocol

Le Handshake Protocol est constitué de messages permettant de gérer les échanges sur les informations liées à l’établissement d’une session TLS. La compréhension du Handshake Protocol est capitale
pour comprendre la technique de l’interception TLS que nous verrons par la suite. Donc, ce type de
message sera détaillé afin d’appréhender sereinement la suite. Parmi les informations échangées par le
Handshake Protocol, il y a :
• session identifier : une séquence d’octets permettant d’identifier une session.
• peer certificate : l’échange des certificats et leur authentification.
• compression method : l’algorithme de compression utilisé par TLS avant le chiffrement de données
• cipher spec : les différents algorithmes de chiffrement qui seront utilisés par TLS (génération
de clefs, chiffrement, signature). Également certaines valeurs sur la longueur des clefs ou de la
signature.

Edouard Petitjean — M2 MIAGE SIID

19

TLS : un protocole compliqué ? - TLS : le protocole en détail

Figure 2.7 – Echange TLS Handshake Protocol
• master secret : une séquence de 48 octets qui est un secret partagé entre le client et le serveur.
Ce secret sera par la suite utilisé comme source entropique pour générer les clefs de chiffrement
vues précédemment.
• is resumable : un indicateur permettant de définir si la session peut être réutilisée pour une
nouvelle connexion.
Toutes ces informations vont s’échanger en un minimum d’échange pour accélérer l’établissement
des sessions. Le schéma fig. 2.7 p.20 donne un aperçu des échanges.
Les échanges en bleus sont obligatoires dans le protocole TLS alors que les échanges en jaunes sont
facultatifs. La flèche verte indique l’utilisation d’un autre protocole qui sera vu par la suite.
Client Hello est le message envoyé par le client au serveur qui va permettre le début de communication TLS. Ce message est composé des éléments suivants :
• client_version : la version du protocole la plus récente que le client supporte. La version reprend
la codification indiquée au paragraphe Record Layer p.18.
• random : un nombre composé de la concaténation d’un horodatage représentant le nombre de
secondes depuis le 1er janvier 1970 sur 4 octets. Ainsi que d’un nombre aléatoire de 28 octets
généré via un algorithme de génération sécurisée. Cette valeur sera utilisée pour générer les clefs
décrites au paragraphe La gestion des états de connexions p.17.
• session_id : un nombre permettant d’identifier la session en cours. Un champ vide (égale 0)
représente la volonté du client d’ouvrir/réinitialiser la session actuelle.
• cipher_suites : la liste des suites de chiffrements que le client supporte. Cette liste est ordonnancée
par ordre de préférence du client. Souvent, les protocoles les plus sécurisés sont annoncés en début
de liste, mais certains clients peuvent préférer d’annoncer les suites de chiffrement les plus stables
en fonction de leur implémentation.
• compression_methods : une liste des méthodes de compression supportées par le client. Son
ordonnancement suit la même logique que l’élément précédent.
• extensions : une suite d’éléments, tous indépendants les uns des autres, que le client voudrait
utiliser avec le serveur. La structure d’un élément extension sera composée d’un identifiant numérique de 2 octets, ainsi que de la donnée que l’extension va utiliser. Il n’existe pas d’ordre de
préférence pour annoncer les extensions, mais chaque extension ne peut être annoncée qu’une
seule fois.
Server Hello est le message envoyé par le serveur au client pour notifier le choix des options qu’il
aura établi en fonction des préférences du client et de ses capacités. Les éléments qui composent ce
message sont les mêmes que pour Client Hello :
• server_version : la version la plus faible du client et qui correspond à la version la plus haute
du serveur.

Edouard Petitjean — M2 MIAGE SIID

20

TLS : un protocole compliqué ? - TLS : le protocole en détail

• random : un nombre généré aléatoirement par le serveur en se servant de la même méthode que
le client. A l’instar de la valeur contenue dans le Client Hello, cette valeur sera utilisée lors de la
génération des clefs vues précédemment.
• session_id : un nombre permettant d’identifier la session en cours. Si lors du message Client
Hello, la valeur est nulle, alors le serveur va renvoyer les valeurs qu’il aura choisies pour cette
session. Dans le cas contraire, le serveur va vérifier si la valeur est en cache ou non. Si oui, alors
le serveur va reprendre les valeurs en cache. Sinon, il renvoie un session_id nul pour notifier au
client qu’un échange complet est nécessaire.
• cipher_suites : la suite de chiffrement qui aura été retenue par le serveur. Pour choisir, le serveur
parcourra la liste envoyée par le client et récupérera la première valeur qu’il supporte.
• compression_methods : la méthode de compression retenue par le serveur. Son choix est similaire
au cipher_suites.
• extensions : les extensions demandées par le client. Seules les extensions à l’initiative du client
peuvent être présentes.
Server Certificate est le message contenant le certificat du serveur et est envoyé au client. Si
besoin, ce message est envoyé directement après le Server Hello sans attendre une réponse du client.
Le Server Certificate n’est obligatoire que si la méthode d’échange de clefs utilise des certificats pour
l’authentification. A savoir que dans la RFC 5246 qui définit le TLS 1.2, seule la méthode d’échange
anonyme (DH_anon) n’utilise pas de certificat. Donc le certificat du serveur est une quasi-obligation
lors de l’utilisation du TLS 1.2.
Le certificat du serveur n’est pas la seule donnée qui transite dans ce message. Pour rappel, les
clients ne connaissent généralement que les autorités de certificats racines. Par conséquent, c’est souvent
un certificat chaîné 14 qui sera utilisé dans ce message.
Server Key Exchange est envoyé immédiatement après un Server Certificate sans attendre de
réponse du client. Il est utilisé dans le cas où le message précédent ne contient pas de données permettant au client d’échanger de façon sécurisée la clef premaster secret, qui servira à générer la clef master
secret vu au paragraphe Handshake Protocol p.19.
Si ce message est utilisé, alors il fournira au client une clef publique permettant l’utilisation d’un
algorithme de chiffrement asymétrique pour générer (Diffie-Hellman) ou chiffrer (RSA) la clef premaster
secret.
Certificate Request est envoyé quand le serveur à besoin d’authentifier formellement le client.
Cette demande est envoyée directement après un message Server Certificate ou un message Server Key
Exchange et uniquement si le serveur s’authentifie auprès du client. Un serveur anonyme ne peut pas
demander une authentification à un client.
Ce message contiendra une liste de tous les DN des autorités de certification qui devront avoir
signé le certificat du client. Aussi, le client ne peut pas présenter un certificat signé par une AC ne se
trouvant pas dans la liste envoyée par le serveur.
Server Hello Done est le message envoyé par le serveur au client pour notifier qu’il a terminé
d’envoyer les informations relatives à l’établissement de session. Ce message ne contient aucune information. Une fois ce message envoyé, le serveur se met en attente de réponse de la part du client. Quant
à ce dernier, son rôle à ce moment est de procéder à la vérification du certificat du serveur, puis, si
celui-ci est valide, de finir la génération des clefs qui seront utilisées par la suite.
Client Certificate est le premier message envoyé par le client suite au Server Hello Done si le
serveur a procédé au préalable à un Certificate Request. Le client envoie donc une chaîne de certificat
comportant son certificat ainsi que ceux des autorités de certification intermédiaires. Si le client n’a
pas de certificat, alors il renvoie un message avec une chaîne vide. Par la suite, c’est au serveur de
prendre la décision s’il accepte ou non de traiter avec un client anonyme.
14. une succession de certificat permettant de retrouver le certificat du serveur, mais également les certificats des
autorités de certification intermédiaires

Edouard Petitjean — M2 MIAGE SIID

21

TLS : un protocole compliqué ? - TLS : le protocole en détail

Client Key Exchange est le message qui permet de finaliser l’échange de la clef premaster secret,
soit par génération conjointe (Diffie-Hellman), soit par échange chiffré (RSA). Si le client est authentifié
par un message auprès du serveur, et qu’il utilise une clef publique statique, alors le contenu de ce
message sera vide. Néanmoins, même vide, ce message doit être envoyé.
Certificate Verify est envoyé pour fournir une vérification explicite du certificat du client. Suite à
ce message, le client et le serveur ont généré les différentes clefs de chiffrement symétriques énoncées
au paragraphe Handshake Protocol p.19.
Finished est le premier message chiffré et signé avec les clefs générées. Le but de ce message, envoyé
par le client au serveur et inversement, est de s’assurer que les deux protagonistes puissent échanger
de manière compréhensible avec les nouvelles clefs. Si c’est le cas, alors ces clefs seront utilisées pour
chiffrer et signer tous les autres messages de la session TLS.

2.6.4

Alert Protocol

Le protocole Alert Procotol a pour rôle la notification des erreurs à l’interlocuteur. Il permet d’envoyer des messages avec un niveau d’alerte : warning ou fatal — le premier notifie seulement, le second
indique que la session doit être interrompue. Ainsi qu’une description du message d’erreur codé sur un
octet.

2.6.5

Change Cipher Spec Protocol

Ce protocole est très simple car il ne comporte qu’un message contenant un seul octet défini à
1. Ce protocole est utilisé par le client et le serveur pendant la phase de négociation juste avant les
messages Finished. Il permet de signaler que les échanges qui auront lieu par la suite seront chiffrés
symétriquement via les nouvelles clefs générées.

Edouard Petitjean — M2 MIAGE SIID

22

Chapitre 3

L’interception TLS
L’interception TLS est une technique basée sur Man In The Middle (l’homme du milieu) qui
consiste à interposer un proxy TLS entre un client et un serveur, puis usurper l’identité de chacun
auprès de l’autre comme le montre le schéma fig. 3.1 p.23.
Ce schéma très grossier représente parfaitement l’idée derrière cette technique. Détruire l’idée d’un
canal de bout en bout afin de créer deux canaux, un du client au proxy TLS, l’autre du proxy TLS au
serveur. Ainsi, il n’y a pas de déchiffrement mais juste deux connexions TLS bien distinctes permettant
au proxy TLS de voir le contenu en clair. Bien sûr, cette technique est loin d’être anodine et demande
une grande vigilance quant à son exécution. Pour rappel, le TLS se base sur l’authentification de chaque
partie pour s’assurer de l’identité de chaque partie. En outre, c’est surtout le client qui a besoin de
connaître l’identité du serveur. Or, avec cette technique d’usurpation, comment faire pour outrepasser
le système d’authentification ? En effet, l’identité du serveur est censée être approuvée et contrôlée
par une autorité de certification indépendante ce qui permet d’éviter toutes formes d’usurpations à
partir des éléments publics. Pour répondre à cette question, il est nécessaire de voir en détail les étapes
permettant de mettre en place cette technique.
L’interception TLS n’est pas une technique normalisée, notamment parce qu’elle met à mal la
sécurité du TLS définie dans la RFC 5246. Par conséquent, tous les équipements et logiciels permettant
de mettre en place cette technique ont leur propre implémentation. Cet article va présenter la façon
générale et les détails qui doivent être pris en compte pour réussir cette technique. Pour cela, il
est important de comprendre qu’il existe deux types d’interception TLS : l’interception sortante et
entrante. Pour mieux saisir ces notions d’entrant et sortant, le schéma fig. 3.2 p.24 les illustre.
L’interception sortante portera donc sur les flux initiés depuis l’environnement géré (ex : Petitjean
Corp) vers d’autres environnements (ex : Internet). A l’inverse, l’interception entrante se basera sur les
connexions venant depuis d’autres environnements (ex : Internet) que celui qui est géré (ex : Petitjean
Corp).

Figure 3.1 – Man In The Middle

Edouard Petitjean — M2 MIAGE SIID

23

L’interception TLS - L’interception TLS sortante

Figure 3.2 – Différence entre connexion entrante et sortante

3.1

L’interception TLS sortante

L’interception TLS sortante est la pratique la plus courante et la plus compliquée à mettre en place.
Elle va permettre d’intercepter toutes les connexions dont les sources sont souvent les utilisateurs d’une
entreprise vers des sites distants. Pour cela, les utilisateurs passeront, de façon transparente 1 , par un
proxy TLS qui interceptera les requêtes, puis ce dernier va initialiser lui-même les connexions vers les
diverses destinations. Néanmoins, cette pratique à une limite : la rupture de la confiance. En effet, il
ne faut pas oublier que le client va vérifier l’identité du serveur de son côté. Or, dans cette architecture
basée sur l’interception, le client va établir une session TLS avec le proxy TLS à son insu, donc le
certificat que va renvoyer le proxy TLS ne correspondra pas, tant sur son nom que sur l’AC, à ce
qu’aura demandé le client.
Pour pallier cette limitation, le proxy TLS devra avoir la capacité de générer des certificats à la
volée et considérés comme valides par le client. Comment ? Le proxy TLS devra utiliser une autorité
de certification reconnue par les clients. Le schéma fig. 3.3 p.25 montre un exemple.
1. Chris veut établir une connexion avec « www.site-sécurisé.com ». Pour cela, il envoie une requête
Client Hello à « www.site-sécurisé.com »
2. Le proxy TLS est positionné dans l’architecture réseau de telle sorte qu’il soit sur le chemin allant
vers « www.site-sécurisé.com ». Lorsqu’il voit une requête TLS, il va l’intercepter et mettre le
client en attente. Puis il va établir une connexion avec « www.site-sécurisé.com », soit en reprenant
exactement les paramètres que le client a indiqués dans son Client Hello, soit en modifiant
certaines valeurs pour accentuer les paramètres de sécurité par exemple.
3. Le serveur « www.site-sécurisé.com » établit une connexion sans problème particulier. Pour lui, le
proxy TLS est un client comme un autre. Par conséquent, le serveur renvoie les paramètres qu’il
aura choisis ainsi que son certificat et sa chaîne de certificat. Dans le schéma, le certificat a été
1. Pour que cette technique fonctionne, le client ne doit pas repérer une quelconque interception du flux. Puisque le
TLS a été pensé pour justement éviter les interceptions.

Edouard Petitjean — M2 MIAGE SIID

24

L’interception TLS - L’interception TLS sortante

Figure 3.3 – Interception TLS sortante
créé pour répondre au nom « www.site-sécurisé.com » et il a été signé par « AC Intermédiaire »
(une AC publique quelconque mais dont la racine est reconnue par les navigateurs).
4. Après que le proxy TLS ait reçu le certificat du serveur et sa chaîne, il procède aux vérifications
d’usage et décide si la connexion peut-être établie. Une fois la session TLS établie, elle reste en
attente jusqu’à ce que le vrai client envoie des données. Par la suite, le proxy TLS va reprendre
les données du certificat du serveur pour en recréer un autre temporaire et qui sera signé par son
AC interne à l’entreprise « proxytls.local » et qui est connu par les navigateurs de l’entreprise.
Puis ce nouveau certificat sera utilisé par le proxy TLS pour usurper l’identité de « www.sitesécurisé.com » auprès du client.
Le faux certificat généré par le proxy TLS aura donc les caractéristiques suivantes :
— Sujet : www.site-sécurisé.com
— Emetteur : proxytls.local
Par conséquent, lorsque le client voudra vérifier le certificat qui lui est présenté, il pourra constater
que le sujet correspond au domaine et que l’AC qui a signé le certificat est reconnue par le client.
Il établira donc une connexion TLS sécurisée avec le proxy TLS en pensant être directement
connecté à « www.site-sécurisé.com »

3.1.1

Le placement du proxy TLS

Le proxy TLS doit avoir une position particulière sur le réseau afin de mener sa tâche. Même s’il est
couramment appelé Proxy TLS, il est assez rare qu’il représente un équipement dédié. En effet, c’est
souvent un proxy ou pare-feu qui porte ce rôle. Une préférence d’ailleurs pour les pare-feux qui font
maintenant de l’analyse protocolaire et donc portent des analyses d’inspections. Le rôle d’interception
TLS est tout indiqué pur ces équipements qui mutualisent les analyses de haut niveau.
L’emplacement du proxy TLS dans l’architecture du réseau est également une notion importante.
Il doit être « transparent » pour le client, donc il doit être un noeud obligatoire du chemin réseau entre
le(s) client(s) et les sites distants. Les proxy TLS seront donc très souvent proches des accès Internet,
voir sont les équipements frontaliers entre le réseau d’entreprise et Internet. Cette transparence n’est
pas anodine. Le TLS a été conçu pour créer des canaux sécurisés pour la confidentialité et se repose sur
des systèmes d’authentification (certificat X.509) afin d’éviter les usurpations d’identités. Donc, il n’est
pas prévu pour les clients d’avoir une fonctionnalité permettant de passer par un serveur mandataire
TLS qui ferait de l’interception comme pour des services proxy tels que HTTP, FTP, IMAP, etc...

3.1.2

Une autorité de certification interne

Pour recréer des certificats et les signer à la volée, le proxy TLS devra contenir une autorité de
certification qui permettra de procéder à ces opérations. Or cette autorité ne se sera pas reconnue par
défaut par les clients. Seules les autorités racines publiques le sont, et aucune d’entre elles n’accepterait
de délivrer une autorité de certification intermédiaire à un tiers quelconque pour deux raisons.
La première est que ça voudrait dire que l’autorité de certification publique délègue le droit à
un tiers de créer et signer des certificats à son nom. Ce genre de délégation peut-être dangereuse et
engagerait la responsabilité de l’autorité. La deuxième raison est que la technique d’interception TLS
va en l’encontre de ce que protège les autorités de certification : l’identité derrière les certificats. Le
Edouard Petitjean — M2 MIAGE SIID

25

L’interception TLS - L’interception TLS entrante

Figure 3.4 – Interception TLS Entrante
risque pour une autorité de certification d’outrepasser ce principe est très important. L’histoire de MCS
Holding qui avait reçu une délégation de la part de la CNNIC 2 , avait outrepassé ses droits en créant un
faux certificat Google pour tester une technique d’interception TLS. Google ayant repéré ce certificat
avait décidé de révoquer dans son navigateur Chrome l’autorité de certification racine provenant de la
CNNIC. Conséquence, les utilisateurs utilisant Chrome (environ 45% de part de marché au moment
des faits 3 ) pouvaient accéder à ces sites mais une erreur de certificat apparaissait.
Puisqu’il n’est pas possible de passer par une autorité publique pour obtenir une AC permettant de
faire de l’interception TLS, il faut utiliser une AC interne au système informatique. Pour cela, plusieurs
solutions sont possibles.
— PKI interne : elle est souvent utilisée dans les grandes organisations qui utilisent des certificats
pour authentifier leurs équipements en interne. Avec une PKI interne, il est possible d’exporter
les clefs (publique et privée) pour les importer dans le proxy TLS. Une bonne pratique serait de
créer une sous-autorité dédiée au proxy TLS.
— Le déploiement par GPO : les structures se basant sur Active Directory ont la possibilité
de déployer massivement des certificats sur les postes. Pour cela, le proxy TLS hébergera une
autorité de certification auto signée puis son certificat sera déployé par une GPO 4 .
— Autres déploiements : Dans les autres architectures utilisant des navigateurs comme Firefox,
d’autres moyens de déploiement doivent être pensés. C’est souvent cette problématique qui freine
les entreprises voulant mettre en place cette technique. Il existe cependant plusieurs techniques
nécessitant ou non une manipulation des utilisateurs. Par exemple pour Firefox, celui-ci utilise
son propre magasin de certificat, néanmoins, la version ESR et les dernières versions basiques ont
une fonction permettant d’utiliser le magasin Windows. Autre exemple, il est possible de publier
le certificat de l’autorité sur une page Web, ajoutable par action manuelle de l’utilisateur, ou
encore via du code JavaScript dans un fichier de configuration du navigateur. D’autres techniques
existent en fonction du contexte. Le plus compliqué étant de trouver la meilleure méthode de
déploiement en fonction des contraintes propres aux réseaux de l’entreprise.

3.2

L’interception TLS entrante

Cette fois, le serveur accessible par les clients se situe en interne du système géré alors que les
clients proviennent de n’importe où. Cette technique est plus simple à mettre en place, et pour cause,
l’identité que le proxy TLS doit usurper est gérée par le système d’information. Ainsi il n’y aura pas
de création de certificats à la volée. Mais un doublon de clefs (publiques et privées) sera présent sur le
réseau. En effet, le proxy TLS portera les deux clefs du serveur interne qu’il présentera aux différents
clients. Le schéma fig. 3.4 p.26 montre un exemple de cette interception.
2. China Internet Network Information Center, autorité de certification chinoise
3. Mars 2015 : https://www.w3counter.com/globalstats.php?year=2015&month=3 et http://gs.statcounter.com/
browser-market-share/all/worldwide/2015
4. Les GPO (Group Policy Object) sont des ensembles de paramétrages de postes Windows, récupérés depuis un
serveur, qui sont appliqués à divers moments selon des critères précis.

Edouard Petitjean — M2 MIAGE SIID

26

L’interception TLS - L’interception TLS entrante

1. Bob veut établir une connexion sécurisée avec « www.edouard-petitjean.com ». Il envoie une
requête Client Hello à « www.edouard-petitjean.com »
2. Le proxy TLS intercepte la requête du client. Il récupère les différents paramètres que le client a
initié et établi une connexion TLS avec le serveur interne.
3. Le proxy répond au client avec un Server Hello et envoie le certificat du serveur. La connexion
TLS s’établit normalement. Puisque le certificat est valide (il correspond au domaine requêté et
est signé par une AC publique), aucune erreur n’est détectée par les clients.

3.2.1

Le placement du proxy TLS

Comme pour la technique précédente, le proxy TLS devra se placer en coupure réseau entre les
clients et le serveur. Sauf que cette fois, sa position sur le réseau peut-être à plusieurs endroits selon
l’architecture en place. Il peut être proche de l’accès externe tout comme proche du serveur. Bien que
la seconde option est préférable de par la présence des clefs privées des serveurs qu’il héberge et la
possibilité d’ajouter des couches de sécurité réseau entre le client et le serveur.

3.2.2

Hébergement des clefs privées

Cette technique ne va pas se baser sur une AC interne qui va régénérer des certificats. A la place,
le proxy TLS va stocker toutes les paires de clefs des serveurs dont il devra usurper l’identité. Ainsi,
comme le proxy TLS va intercepter les requêtes des clients, il pourra présenter sans problème le
certificat concerné et déchiffrer le trafic grâce à la clef privée. La « simplicité » de cette technique tient
au fait que le système informatique gère le serveur ainsi que le certificat et la clef privée associée. Il est
donc simple d’importer cette paire de clefs à un proxy TLS qui répondra favorablement aux requêtes
des clients.

Edouard Petitjean — M2 MIAGE SIID

27

Deuxième partie

Des Enjeux et Des Risques

Edouard Petitjean — M2 MIAGE SIID

28

Chapitre 4

L’origine du chiffrement des
échanges
Le TLS permet à la fois d’assurer l’identité, l’intégrité, la non-répudiation et la confidentialité des
données lors d’un échange biparti. Les trois premiers points sont purement « bénéfiques ». C’est-à-dire
qu’ils apportent une sécurité sans compromis. En effet, ils permettent de s’assurer que nous échangeons
bien avec la personne voulue, que la donnée reçue soit identique à celle envoyée, et donc que personne
ne l’a modifiée en cours de route. Ainsi que de permettre de dire que l’émetteur à bel et bien envoyé
un message et ne pourra pas le nier. Ces trois points sont donc essentiels à un échange sécurisé mais
surtout, n’apporte aucune problématique particulière.
A l’inverse, le rôle de confidentialité qu’apporte le TLS est au centre de débats importants et
houleux. Comme vu précédemment, la confidentialité des données est garantie par la cryptographie.
Or, ce chiffrement des données est assez mal vu par certains organismes. Et pour cause, reprenons
rapidement l’évolution du chiffrement dans l’histoire.
Le but de la cryptographie a toujours été d’assurer la confidentialité d’une donnée en la rendant
illisible pour tout individu n’ayant pas les connaissances suffisantes pour décoder le message. Cette
pratique remonterait, au moins, au XVIième avant J.C. Un document retrouvé en Irak semble avoir fait
l’objet d’une technique cryptographique, en effet, un potier a voulu protéger sa recette, en modifiant
l’orthographe de certains mots et en supprimant des consonnes 1 .
Par la suite, la cryptographie a eu une place importante dans les stratégies et tactiques militaires.
Elle permettait de pouvoir communiquer entre différentes parties sans vraiment se soucier que le
message puisse être intercepté. Par conséquent, une cryptographie bien pensée offrait un avantage
important lié à la communication. Dans les cas les plus connus de cryptographie militaire, nous pouvons
citer le décalage de César 2 ainsi que la machine Enigma 3 utilisée par l’Allemagne lors de la Seconde
Guerre Mondiale. C’est donc assez naturellement, qu’en France, la cryptographie a longtemps été
considérée comme une arme militaire, par conséquent les civils n’avaient pas le droit d’utiliser cette
pratique.
A partir de 1990, les moyens cryptographiques ne sont plus considérés comme armes militaires sauf
exception 4 . Néanmoins, les moyens permettant d’assurer la confidentialité des données restent sous
le contrôle de l’Etat. En effet, toutes utilisations permettant de rendre un message illisible doivent
forcément faire l’objet d’une demande d’autorisation auprès d’un organisme dédié. Par la suite, la
démocratisation d’Internet et des outils s’en rapprochant et l’arrivée du SSL, obligèrent la France à
revoir sa législation. le 26 juillet 1996, une réforme vint modifier la loi de 1990 afin d’assouplir le
contrôle de la cryptographie. Désormais, les moyens « peu sûrs » 5 n’était plus soumis à autorisation,
1. https://fr.wikipedia.org/wiki/Histoire\_de\_la\_cryptologie et « The Codebreakers : A Comprehensive
History of Secret Communication from Ancient Times to the Internet, Revised and Updated » de David Kahn
2. Technique cryptographique basée sur la substitution de lettre. Cette technique utilisait un alphabet décalé de N
lettres vers la droite et le message originel était écrit en fonction de ce deuxième alphabet. Le destinataire du message
connaissant N, décalait l’alphabet du message de N lettres sur la gauche pour retrouver le message originel.
3. Technique basée sur la substitution de lettre. En utilisant une clef de départ et qui change à chaque lettre substituée, elle permet que lors de l’utilisation à plusieurs reprises d’une même lettre, cette dernière ne soit pas remplacée
systématiquement par une même lettre. Cela complexifiant le travail de cryptanalyse sur les messages.
4. Loi n◦ 90-1170 du 29 décembre 1990 sur la réglementation des télécommunications
5. Moyens de chiffrement utilisant des clefs inférieures ou égales à 40 bits

Edouard Petitjean — M2 MIAGE SIID

29

L’origine du chiffrement des échanges -

mais uniquement à déclaration. Mais surtout, la totalité des techniques de chiffrement était libre
d’usage à la seule condition que les clefs de chiffrement soient stockées dans un système de séquestre.
Dans lequel, une personne agréée aurait le droit d’utiliser les clefs pour déchiffrer des messages. Par la
suite, en 1999, certaines contraintes ont encore été assouplies car les outils de chiffrement utilisant des
clefs comprises entre 40 et 128 bits ne sont plus soumis à autorisation mais à déclaration uniquement.
Néanmoins, ces restrictions restèrent lourdes pour les entreprises de e-commerce et banque en ligne
qui ont besoin d’assurer une sécurité maximale à leurs clients. Avec l’arrivée de la LCEN 6 , l’utilisation
des moyens de chiffrement est désormais complètement libre de déclarations et d’autorisations pour
l’usage. La fourniture, importation et exportation en fonction des pays restent tout de même soumises
à des démarches. Avec la LCEN, tout individu est libre de naviguer de façon sécurisée sur Internet.
Cette liberté a permis la forte croissance des sites de e-commerce et des banques en ligne puisque
ces derniers pouvaient proposer des moyens de confidentialité sûrs. Mais d’autres types d’activités ont
profité de cette liberté : les réseaux sociaux et les webmails. Pour l’utilisateur, ces sites sont tout aussi
sensibles puisqu’il est question d’échanger sur leur vie privée. Ainsi, en plus de permettre à l’économie
numérique de croître, l’étendard du respect de la vie privée et du secret de la correspondance est utilisé
pour justifier l’utilisation des moyens cryptographiques forts.
Cependant, le 6 juin 2013, un citoyen américain, Edward Snowden, fit des révélations accablantes
sur un programme étatique américain : PRISM 7 . Ce programme, géré pas la NSA (National Security
Agency) et supervisé par le FISC (Foreign Intelligence Surveillance Court), portait sur une surveillance
massive des individus ne vivant par le sol des États-Unis. Une des révélations la plus troublante a été
les liens entre la NSA et les entreprises américaines (Microsoft, Google, Facebook, Apple, etc...) qui
permettaient aux renseignements américains, de glaner des informations stockées sur les serveurs de
ces entreprises concernant des individus ciblés.
Même si dans le scandale de PRISM, l’organisme étatique se fournissait directement à la source,
le monde d’Internet à pris conscience de l’ampleur de la surveillance de masse. Aussi, même s’il n’est
pas possible d’empêcher des structures d’état de demander des informations à une entreprise du même
pays si la loi le permet, les échanges pouvaient être protégés avec le TLS et éviter cette surveillance.
Aussi, de plus en plus de sites, de toute nature, proposent d’accéder à leurs ressources en TLS. Le
mode classique, c’est-à-dire la navigation non chiffrée, est de plus en plus rare, notamment dû à la
technologie HSTS 8 , mais surtout par la préconisation qu’en font la CNNum 9 (Conseil National du
Numérique) et l’ANSSI 10 (Agence Nationale de la Sécurité des Systèmes d’Information).
Le TLS étant de plus en plus répandu, il devient compliqué pour les entreprises de maîtriser leurs
flux. En effet, que ce soit pour des raisons professionnelles ou personnelles, les utilisateurs d’un système
informatique sont amenés à accéder à divers sites web. Or, vu que le TLS chiffre de bout en bout entre
le client et le serveur, les équipements de sécurité de l’entreprise deviennent inopérants. C’est dans ce
cadre-là que l’interception TLS est mise en place.

6. Loi n◦ 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique
7. https://www.theguardian.com/us-news/prism
8. HTTP Strict Transport Security, mécanisme HTTP permettant de signaler à un client qu’il doit communiquer de
façon sécurisée (HTTPS) et non en clair.
9. https://cnnumerique.fr/cp-chiffrement/
10. https://fr.scribd.com/document/319975624/Note-de-l-Anssi-sur-le-chiffrement\#download\&from\_embed

Edouard Petitjean — M2 MIAGE SIID

30

Chapitre 5

Aspect technique
5.1

Enjeux sécuritaires

Pour la partie technique de l’interception TLS, les enjeux sont surtout sécuritaires. Après tout, la
mise en place de l’interception se fait car le TLS rendait les équipements de sécurité sur un mode de
fonctionnement dégradé. C’est-à-dire un mode de fonctionnement ne permettant pas aux équipements
de remplir leurs fonctions avec efficacité. Les différentes notions qui seront vues par la suite, sont celles
rendues inopérantes par le TLS mais que l’interception TLS permet de rendre opérationnelles.

5.1.1

Les pare-feux nouvelle génération : l’analyse poussée

Depuis quelques années, les pare-feux nouvelle génération ont vu le jour. Ils permettent des analyses de flux plus poussées et embarquent maintenant des composants permettant de reconnaître les
protocoles. Aussi, ces pare-feux ne se basent plus uniquement sur des informations de bas niveau (3
et 4 du modèle OSI), mais également de haut niveau en étant capables de reconnaître un flux HTTP
par exemple. Ainsi, avec cette capacité d’analyse, ces équipements proposent de plus en plus d’outils
de filtrage en fonction des applications. Notamment, ils sont souvent eux-mêmes utilisés comme proxy
TLS pour faire de l’interception.
Analyse protocolaire
Comme dit précédemment, ces pare-feux nouvelle génération permettent de reconnaître une application utilisée dans un flux (HTTP, TLS, SSH, SMTP, etc...). Pour cela, ils se basent sur des RFC et
pattern de données pour différencier les applications. Cette protection est plus efficace que le simple
filtrage d’un ou plusieurs ports. En effet, les anciens pare-feux se limitaient uniquement aux réseaux et
transports (TCP ou UDP) utilisés. Aussi, il était possible d’utiliser n’importe quel protocole à partir du
moment où le port était bon. De plus, ces nouveaux équipements permettent également de garantir la
fiabilité du protocole filtré. En effet, sachant reconnaître les applications, les pare-feux peuvent détecter
des anomalies d’utilisation (mauvaises requêtes à un mauvais moment par exemple, tailles d’en-têtes
anormales, etc...) et même appliquer des analyses IDS/IPS 1 (exemple : détection d’injection de code
dans du HTTP). Ce genre d’analyse est très précieux pour les flux allants et venants d’Internet. Comme
il est impossible de maîtriser les différents tiers se situant sur Internet, l’analyse protocolaire permet
de protéger fortement les utilisateurs d’un réseau contre les diverses attaques provenant d’Internet,
voire de protéger les serveurs publiés sur Internet des nombreuses attaques.
Analyses « classiques »
Les analyses « classiques » vont regrouper toutes les analyses liées aux malwares 2 et les spams.
Généralement, les postes clients sont équipés d’un antivirus local pour se protéger. Cette protection se
1. Intrusion Detection/Prevention System, Système d’analyse de données permettant de détecter ou prévenir des
attaques connues
2. Malware est un terme généraliste pour désigner les divers programmes nuisibles (virus, spywares, chevaux de Troie,
vers, backdoors, rootkits, keyloggers, publiciels, etc...)

Edouard Petitjean — M2 MIAGE SIID

31

Aspect technique - Enjeux sécuritaires

base souvent sur une analyse basée sur la signature 3 , qui par nature permet de détecter rapidement
des malwares connus. Le principal risque de ce genre d’analyse est la latence entre la création d’un
nouveau malware et la notification de sa signature. Pour pallier cela, les analyses heuristiques 4 sont
nécessaires. Or, ce type d’analyse demande une certaine puissance de calcul que les postes bureautiques
n’ont pas. A la place, les entreprises ont soit des équipements d’analyses dédiées (sandbox 5 ), soit des
services hébergés par des prestataires de sécurité qui ont de fortes capacités d’analyses auxquelles sont
envoyées les données à analyser.
Prévention de perte/fuite de données
La perte et la fuite de données sont une hantise pour toutes les entreprises. Les causes de ces pertes
sont très nombreuses : fuite de données suite à une attaque interne ou externe, transmission de données
bancaire suite à une campagne de phishing 6 , utilisation d’une plateforme d’échange non autorisée par
l’entreprise, etc...
Contre ça, les techniques de prévention de pertes de données (Data Loss Prevention) ont vu le
jour. Ces techniques utilisent l’analyse en profondeur des données pour détecter des patterns bien
particuliers dans des contextes donnés. Aussi, si une personne essaye d’envoyer une donnée sensible à
travers un moyen de communication considérée comme non sécurisée par l’entreprise, l’équipement en
charge de la prévention pourra supprimer tout ou une partie du flux concerné.

5.1.2

Utilisation d’un proxy

En fonction de son utilisation, l’interception TLS est placée soit en mode proxy TLS, soit en mode
reverse proxy TLS 7 . Dans les deux cas, cela permet de scinder un flux entre deux tiers passant par
l’équipement. Ce faisant, il est possible de limiter le taux d’exposition des clients et serveurs d’une
entreprise à Internet. L’autre avantage d’un proxy est le cache pour les pages web, permettant de limiter
le nombre de connexions vers Internet et donc l’économie de la bande passante qui est onéreuse.

5.1.3

Journalisation des connexions

Un inconvénient majeur du TLS et de son chiffrement est l’impossibilité de journaliser les informations des protocoles encapsulées dans le TLS. Même si la problématique majeure de la journalisation
est liée aux aspects juridiques que nous verrons par la suite, le côté technique a également un fort
besoin de ces journaux. Que ce soit pour résoudre des incidents ou auditer l’utilisation du système
dans sa globalité ou partiellement, les logs sont une composante importante dans la vie d’un système
informatique.
Aide à l’exploitation
Les journaux sont la première source de données permettant d’assurer l’exploitation au quotidien
d’un système. Sans trace, il est impossible de comprendre une anomalie passée, ni même de comprendre
l’état actuel du système. En particulier, les métadonnées des protocoles sont une source d’information
précieuse qui permet de définir le contexte dans lequel s’est déroulée la connexion (l’heure, la source, la
destination, l’action, les paramètres, etc...). Ainsi, ces éléments sont très importants pour toutes actions
d’investigations sur des anomalies rencontrées. Ils permettent de comprendre, voire de reproduire,
les incidents afin de mettre en place des contre-mesures adéquates pour protéger la production de
l’entreprise.
3. Cette analyse se repose sur une base locale, mise à jour régulièrement, contenant des signatures de malwares.
4. Cette analyse se base sur le comportement d’un programme, en évaluant son code ou en l’exécutant dans un espace
protégé, pour définir s’il est nuisible ou non.
5. Aussi appelé bac à sable, est un environnement d’exécution de programme isolé pour inspecter leur comportement.
6. Technique permettant de récupérer des informations confidentielles en se faisait passer pour un tiers de confiance
(banque, assurance, compagnie d’énergie ou télécoms, etc...)
7. Dans le cas d’une connexion d’un client interne allant vers une ressource externe, nous parlerons de proxy. Dans
le cas d’un client externe arrivant sur une ressource interne, nous parlerons de reverse proxy (proxy inversé).

Edouard Petitjean — M2 MIAGE SIID

32

Aspect technique - Risques : les contraintes techniques

Temps de traitement global (en s)
Requêtes traitées par seconde
Requêtes échouées

HTTP

TLS

TLS intercepté

132,552

171,716

772,082

37,72

29,12

6,48

0

0

99

Table 5.1 – Comparaison traitement des requêtes
Déterminer la volumétrie
Les journaux sont aussi très utiles à la détermination de la volumétrie d’un système informatique.
Selon la configuration de la journalisation, celle-ci peut permettre d’évaluer le nombre de connexions
(total ou dans une période donnée) d’un ou plusieurs protocoles. Ainsi que de déterminer la quantité de
données échangées dans les protocoles (si la journalisation ressort bien ce type de données). Ces deux
informations sont cruciales pour un système informatique car elles permettent de connaître l’évolution
de son utilisation et anticiper un dépassement des limites imposées par le système.

5.2

Risques : les contraintes techniques

Pour la partie technique, les risques de l’interception TLS vont se concentrer sur la limitation
technique des équipements utilisés, mais aussi sur la modification d’utilisation du TLS entraînée par
l’interception.

5.2.1

La performance

La principale limite à prendre en compte pour l’interception TLS est la ressource qu’elle va utiliser.
Le TLS repose sur plusieurs algorithmes mathématiques utilisant de grands nombres, complexifiant
ainsi les calculs. Par conséquent, l’utilisation du TLS est en soi consommatrice de ressources. En
effet, l’équipement utilisé comme proxy TLS va établir deux sessions, là où les clients et serveurs n’en
utiliseront qu’une seule. Le tableau tab. 5.1 p.33 et le graphique fig. 5.1 p.34 montrent un comparatif
basé sur l’envoi de 5000 connexions HTTP, dont 30 sont envoyées simultanément, en clair, en TLS et
en TLS intercepté 8 .
Avec ce comparatif, il est facile de voir que l’interception TLS a des impacts significatifs sur la
gestion des flux. En effet, par rapport à un flux TLS classique, le fait d’intercepter demande plus
de puissance de calcul, et avec la gestion parallèle des connexions, le nombre de requêtes pouvant
être gérées chute brutalement. Autre point à prendre en compte : le taux d’échec de l’interception
TLS. Comme il est possible le voir dans l’exemple, l’interception TLS échoue dans la transmission des
requêtes. Ces anomalies proviennent surtout sur des erreurs d’échange dans l’établissement TLS.
Bien que l’impact directement visible repose sur le nombre de connexions simultanées pouvant
être gérées, la problématique provient surtout des éléments physiques de l’équipement dédié à être
proxy TLS. En effet, que l’équipement soit équipé de cryptoprocesseurs 9 ou non, l’interception TLS
peut entraîner une saturation du système de calcul. Or, si le système de calcul est saturé, alors les
divers flux vont être mis en file d’attente jusqu’à leur traitement. Mais si le cryptoprocesseur n’est
pas assez performant, alors la file d’attente ne cessera de s’agrandir jusqu’à ce que des comportements
anormaux apparaissent (blocages de flux, flux non déchiffrés, etc...). Le problème étant plus grave si
l’équipement ne fournit pas de cryptoprocesseur et utilise son processeur classique. Dans ce cas, c’est
tout le système d’exploitation de l’équipement qui peut être en péril. Et puisque le proxy TLS doit
être placé en coupure de réseaux entre les clients et les serveurs, sa saturation peut entraîner un arrêt
complet du réseau sur lequel il se situe.
8. Ce comparatif provient d’un environnement laboratoire conçu spécialement pour ce test. Par conséquent, cela ne
reflète pas les capacités des équipements en production dans les entreprises, mais permet de comprendre l’impact de
l’interception TLS sur un environnement donné.
9. Processeurs optimisés pour les tâches cryptographiques

Edouard Petitjean — M2 MIAGE SIID

33

Aspect technique - Risques : les contraintes techniques

Figure 5.1 – Comparaison traitement des requêtes

5.2.2

L’interception

Outre les problèmes liés à la performance, l’interception TLS apporte de lui-même un lot de
contrainte à prendre en compte. Si ces contraintes sont mal estimées avant le déploiement de cette
technique, les impacts sur le système d’information peuvent être préjudiciables à l’organisme voulant
la mettre en place.
Évolution des algorithmes de chiffrement
Comme pour la plupart des équipements d’un système informatique, les éléments de sécurité ont
généralement une durée de vie de 5 années. Or, le monde des chiffrements sécurisés évolue plus vite.
En effet, de nouveaux algorithmes (notamment pour la génération de grands nombres premiers avec
Diffie-Hellman 10 ) voient le jour et sont implémentés sur les serveurs web au détriment des plus anciens.
La problématique pour un proxy TLS dans ce contexte d’évolution est d’être en capacité de suivre cette
évolution. Si le proxy TLS n’est pas capable d’apprendre les nouveaux algorithmes, ou uniquement en
étant mise à jour, cette contrainte devient sérieuse afin de limiter les temps de coupure.
Pour prendre un exemple, le site « moodle.com » 11 a récemment mis à jour sa configuration TLS.
Depuis cette modification, ce site n’accepte les algorithmes Diffie-Hellman que s’ils utilisent une méthode appelée elliptic curve 12 . Chez un client, j’avais mis en place de l’interception TLS via une
solution tierce, avant cette modification opérée par « moodle.com ». Or, cette solution ne sait pas
gérer cette notion de courbe elliptique dans les algorithmes de chiffrement. Pour être mise à jour,
la solution a besoin d’une montée de version majeure qui aura un impact significatif sur le système
informatique. Sans cette montée de version, le client n’a d’autre choix que d’autoriser « moodle.com »
sans le déchiffrer. Ainsi, le choix qui s’impose au client est le suivant :
1. Ne pas déchiffrer le flux vers ce site, au risque de laisser tous les échanges sans surveillance
2. Prévoir une montée de version majeure de son proxy TLS qui entraînera un travail de refonte de
la solution (problème de comptabilité de version) ainsi qu’un risque de coupure de service lié à
la montée de version (erreur de paramétrage, comportement anormal, etc...)
Dans ce genre de cas, le choix est cornélien et peut poser une véritable problématique sur l’évolution
future du système informatique. En effet, la décision sera prise en calculant l’impact économique
prévisionnel dans les deux cas de figure, l’impact le plus bas sera le plus déterminant. Or, l’évaluation
de l’impact peut être très compliquée à prendre en compte si la direction manque d’informations sur
la multitude de facteurs à appréhender.
10.
11.
12.
pour

Méthode permettant à deux tiers de générer une paire de clefs asymétriques sans avoir à les échanger.
Plateforme d’apprentissage en ligne.
La courbe elliptique est un cas particulier de courbe algébrique utilisée dans divers domaine dont la cryptographie
trouver des nombres premiers très grands rapidement

Edouard Petitjean — M2 MIAGE SIID

34

Aspect technique - Risques : les contraintes techniques

La souplesse des proxy TLS
Un problème récurrent lié aux proxy TLS est leur « souplesse ». Souvent dans leurs configurations, les proxy TLS vont proposer un ou plusieurs paramétrages possibles pour l’interception TLS en
fonction des cas de figure. Or, ce nombre de paramétrages reste toujours limité et lié à des critères
de reconnaissance de flux précis. A cela s’ajoute souvent la difficulté de spécifier les algorithmes de
chiffrement voulu. Il y aura souvent des notions de niveau cryptographique dans les équipements qui
regrouperont des suites cryptographiques, mais il reste rare de pouvoir personnaliser ces niveaux.
Par conséquent, le choix de limiter ou non les suites cryptographiques demande une sérieuse réflexion
en fonction des besoins. Soit, la décision est de n’accepter que des chiffrements robustes, dans quel cas
une multitude de sites divers ne sera plus acceptée. Soit, les algorithmes plus faibles sont acceptés, ce
qui augmente le risque qu’un individu malveillant puisse déchiffrer le flux.
Attention toutefois, autoriser des algorithmes de chiffrement moins robustes ne veut pas forcément
dire que ces derniers présentent des failles importantes, mais au vu des techniques de cryptanalyses 13
actuelles, « moins » de temps est nécessaire pour déchiffrer un flux, mais cela reste impossible pour un
simple poste de procéder à la cryptanalyse en un temps raisonnable 14 .
Le cache TLS
Nous avons vu précédemment que l’interception TLS à un impact significatif sur la vitesse de
traitement des requêtes. Une des causes est que lors de l’interception sortante, le proxy TLS, avant de
créer un faux certificat pour le client, va procéder à des vérifications d’usage sur le certificat serveur.
En effet, il va tester qui a signé le certificat, sa date de validité, si le nom du certificat correspond
au domaine requêté, etc... Afin de minimiser le temps de traitement lié à la validation du certificat,
certaines solutions proposent un cache de certificats TLS générés à la volée. Ainsi, le proxy TLS a,
par le passé, procédé aux vérifications d’usages d’un certificat puis généré le faux pour le client, alors
il garde ce dernier en mémoire pour un temps. Lorsqu’un client, le même ou un autre, vont vouloir
accéder au site présentant le certificat en question, le proxy TLS ne procédera pas aux vérifications et
présentera le certificat généré précédemment.
Cette fonctionnalité de cache permet de gagner un temps précieux, notamment si un nombre
conséquent de requêtes sont à traiter simultanément, mais elle peut également être une source de
risque important. Le proxy TLS va donc se reposer sur son cache qui garde généralement quelques
jours. Durant cette période, le proxy TLS n’effectuera aucune vérification sur le certificat serveur. Or,
si ce dernier a été corrompu récemment, alors il y a un vrai risque que la confidentialité des données
soit remise en cause le temps que le cache soit purgé.
Authentification des clients par certificat
Lors de l’établissement d’une session TLS, le serveur peut demander au client une authentification
via un certificat afin de s’assurer de l’identité du client. L’interception TLS pose un réel problème pour
ce mode d’authentification. En effet, il est impossible de procéder à l’identification du client via un
certificat.
Pour être plus précis, ce n’est pas le fait de transférer la demande du serveur et le certificat client
qui pose problème, mais l’utilisation du certificat client par la suite. Pour rappel, le proxy TLS placé en
coupure se fait passer à la fois pour un client et un serveur en fonction de son interlocuteur. Il établit
donc deux sessions TLS avec le client et le serveur, et par conséquent, chaque échange qu’il effectue est
signé afin d’assurer l’intégrité et l’identification du message. Or, dans le cas d’une authentification client
par certificat, les deux protagonistes ne savent pas que leurs trafics sont interceptés. Donc, lorsque le
client voudra échanger avec le serveur, ce dernier connaîtra le certificat du client, et voudra vérifier
que tous les messages qu’il reçoit ont bien été signés avec le certificat du client. Ceci impossible, car le
trafic étant intercepté, les messages seront signés avec le certificat du proxy TLS.
Pour ce genre de connexion, seule une liste blanche permettant d’outrepasser l’interception TLS
est envisageable pour rendre les sites demandant une authentification accessible. Dans le cas contraire,
le flux sera bloqué.
13. La science de déchiffrer un message sans en posséder la clef.
14. En cryptanalyse, déchiffrer un message en un temps raisonnable signifie réussir à déchiffrer le message avant la fin
de la durée de vie contenue dans le message.

Edouard Petitjean — M2 MIAGE SIID

35

Aspect technique - Risques : les contraintes techniques

Le flux en clair
Évidemment, le but de l’interception TLS est d’avoir le trafic en clair pour y apporter des analyses
diverses, mais cela reste un risque en soi. L’utilisation du TLS permet la confidentialité lors d’un
échange où les données sont censées être sensibles, or, sur le proxy TLS, le trafic est momentanément
stocké en clair. Par conséquent, si le proxy TLS est compromis (accès par un individu non autorisé),
la confidentialité des flux est également compromise.
La gestion des certificats
Dans le cas d’une interception de flux sortants, nous avons vu que le proxy TLS a besoin d’agir
comme une autorité de certification interne pour générer de faux certificats à la volée. Pour cela,
plusieurs solutions existent mais chacune apporte des risques.
Pour la mise en place de l’interception TLS, il faut réfléchir au mode de déploiement du certificat
de l’autorité de certification interne auprès des divers clients internes. La principale difficulté réside
souvent dans hétérogénéité des systèmes d’exploitation et navigateurs utilisés. Pour rappel, plusieurs
méthodes ont été évoquées à la sous-section Le placement du proxy TLS p.25. Même si plusieurs
méthodes de déploiement existent, aucune ne permet de prendre en compte tous les cas de figure.
Notamment à cause du nombre considérable de navigateurs internet qui existent, et qui utilisent leur
propre magasin de certificats. Il faudra donc prévoir comment déployer le certificat de l’autorité de
certification sur tous les navigateurs utilisés au sein du système informatique.
Dans tous les cas, le principal risque restera la compromission du certificat et notamment de la clef
privée qui lui correspond. Si cette dernière tombe entre de mauvaises mains, alors la confidentialité
des flux interceptés n’existera plus. Mais aussi, cette compromission peut permettre à une personne
compétente de créer des certificats de confiance auprès des utilisateurs faisant confiance à l’autorité
de certification interne. Si une telle situation arrive, la priorité pour le système informatique sera de
révoquer le certificat de l’autorité de certification interne au plus vite. De ce fait, dans le cas d’une
utilisation d’une PKI interne, il est très important de dédier une sous-autorité de certification pour
l’interception TLS afin de limiter l’impact d’une révocation du certificat de l’autorité utilisée. En effet,
si un certificat d’une autorité ou sous-autorité est révoqué dans une PKI, alors la totalité des certificats
générés par cette autorité ou sous-autorité seront invalides car l’autorité de certification intermédiaire
ne sera plus de confiance. Ce risque peut-être très critique dans les architectures où le déploiement du
certificat de l’autorité de certification doit se faire manuellement, cela veut dire que pour la révocation
auprès des clients, elle devra également être également manuelle.
Dernier point concernant l’interception des flux sortants : il est fortement déconseillé d’utiliser les
certificats d’autorité de certifications embarqués dans les solutions de proxy TLS. La raison évidente
est d’éviter d’utiliser une paire de clefs connue par d’autres entités utilisant cette même solution. Par
ailleurs, rien n’affirme comme n’infirme que l’éditeur de la solution n’a pas gardé une copie des clefs
sur les équipements lors de leur production avant vente.
Pour l’interception entrante, le risque est tout autre. Le reverse proxy doit connaître toutes les paires
de clefs dont il sera en coupure des serveurs internes. Par conséquent, il sera également concentrateur
de certificats et clefs privées prévues initialement pour authentifier les serveurs hébergés en interne.
Or cette fois-ci, les certificats sont bel et bien valides et reconnus publiquement. Par conséquent, la
compromission du reverse proxy TLS va permettre aux personnes mal intentionnées de se faire passer
pour les serveurs légitimes. La réplique directe devrait être de révoquer les certificats compromis, hélas,
les temps de mise à jour sur Internet sont longs et beaucoup d’utilisateurs peuvent se faire avoir par
des usurpateurs.

5.2.3

Les protections des clients

Même si l’interception TLS est tolérée dans un cadre précis que nous verrons par la suite, il ne fait
pas le bonheur des éditeurs de navigateurs web, qui eux, veulent assurer la sécurisation des échanges,
et notifier tout comportement suspect. Or, l’interception TLS agit comme une attaque dite Man In
The Middle 15 connue notamment pour usurper une identité sur un réseau. Ce genre de comportement
fait partie des comportements suspects que les navigateurs web essayent de détecter. Dans le cas du
TLS, les éditeurs redoublent d’efforts pour détecter les faux certificats. Ce qui est très bien pour les
15. Cf. L’interception TLS p.23

Edouard Petitjean — M2 MIAGE SIID

36

Aspect technique - Risques : les contraintes techniques

utilisateurs, beaucoup moins pour les structures ayant besoin de l’interception TLS pour garantir un
niveau de sécurité optimal de leur système.
La principale technique utilisée pour détecter les faux certificats est le HPKP 16 (HTTP Public
Key Pinning). C’est une technique se basant sur la confiance au premier accès. C’est-à-dire que si le
client et le serveur utilisent cette fonctionnalité, alors à la première connexion au serveur, celui-ci va
renvoyer une liste des clefs publiques lui appartenant. Si lors de nouvelles connexions, la clef publique
reçue n’est pas présente dans la liste de la première connexion, alors le navigateur coupe la connexion.
Au bout d’une certaine période (envoyée par le serveur à la première connexion), la liste est purgée et
la prochaine connexion sera autorisée pour récupérer la liste.
Il existe également d’autres techniques, ne provenant pas de RFC, qui voient également le jour
comme CheckMyHTTP 17 qui se base sur un tiers de vérification. C’est à dire que lorsque le client
récupère un certificat en visitant un site, le client va envoyer une requête à un serveur de confiance se
situant dans un autre réseau pour que celui-ci requête le certificat du site en question. Une comparaison
entre le certificat reçu par le client et celui reçu par le serveur de confiance va permettre de déterminer
si une attaque MITM (Man In The Middle) est en cours ou non.
La démocratisation de ces moyens de détection rend l’application de l’interception TLS très délicate.
En effet, ce sont des mécanismes de détection que les navigateurs web proposent et donc ils nécessitent
des paramétrages particuliers afin de les outrepasser. Selon la taille, hétérogénéité d’une structure et
des droits accordés aux utilisateurs, il peut être très compliqué de trouver un processus permettant la
configuration massive des postes clients. A l’instar des sites proposant une authentification des clients
par certificat, il faudra prendre la réflexion du comportement des postes vis à vis de ces protections.
Les sites doivent-ils faire partie d’une liste blanche outrepassant l’interception TLS au risque d’exposer
le système informatique à des attaques ? Ou alors, les sites doivent-ils rester bloquer ? Ou encore, fautil prévoir une configuration de tout ou une partie des postes du parc pour que les sites en question
deviennent accessibles même avec l’interception TLS ? Si ces questions sont simples à poser, elles restent
difficiles à répondre en fonction du contexte dans lequel elles sont présentées.

5.2.4

La protection des serveurs

Les postes clients ne sont pas les seuls à présenter des protections contre les attaques MITM. Les
sites sécurisés trouvent des astuces pour détecter ces comportements et protéger leurs clients. C’est
notamment le cas des sites bancaires et du gouvernement qui arrive à détecter les attaques MITM.
Chaque site voulant détecter une attaque MITM procède à sa manière. Par conséquent, il n’est pas
possible d’énumérer toutes les techniques existantes, ni même de les expliquer en détail car une grande
partie de la détection se déroule en background des systèmes informatiques. Néanmoins, cet article va
citer deux méthodes pour montrer ce qui peut être utilisé en matière de détection pour les serveurs.
Dans un article appelé The Security Impact of HTTPS Interception 18 , les auteurs proposent une
méthode de détection d’interception TLS en se basant sur des analyses heuristiques portant sur le
comportement des navigateurs connus lors de l’établissement d’une session TLS. Pour faire simple,
ils ont découvert que chaque navigateur a une manière d’établir une session TLS (ordre des suites
cryptographiques, extensions proposées, etc...). Si lors de l’établissement de la connexion TLS, le
serveur détecte un comportement ne faisant pas partie de ceux connus en fonction du navigateur
annoncé via l’en-tête User-Agent, alors le serveur considérera que la connexion est interceptée.
A l’instar des protections proposées par les clients, les serveurs peuvent aussi utiliser un tiers de
confiance pour détecter une interception. Le projet open-source snuck.me 19 permet au client d’avoir
un comportement similaire proposé par CheckMyHTTP vu précédemment. Sauf que cette fois, ce sont
les pages web du site qui embarquent du code JavaScript qui va permettre d’effectuer la vérification.
Aussi, il n’est pas possible de configurer le poste client pour outre passer la vérification, puisque c’est
le site lui-même qui effectue la vérification depuis le poste client.
Contrairement aux protections des postes clients, les protections des serveurs contre les attaques
MITM sont très pénibles à prendre en compte pour un système informatique. Puisque les vérifications
sont faites, soit par les pages web reçues, soit par les serveurs distants. Il n’est pas possible d’agir
16. https://tools.ietf.org/html/rfc7469
17. https://checkmyhttps.net/info.php
18. https://jhalderm.com/pub/papers/interception-ndss17.pdf
19. https://jlospinoso.github.io/node/javascript/security/cryptography/privacy/2017/02/20/snuckme-certquery.html

Edouard Petitjean — M2 MIAGE SIID

37

Aspect technique - Récapitulatif

Enjeux

Risques

L’analyse protocolaire (reconnaissance des applications)

Peut poser des problèmes de performances réseaux

La détection des malwares dans les flux

Évolution rapide des suites cryptographiques

La détection de la prévention de perte/fuite de données

Le manque de modularité des proxy TLS dans la
gestion des suites cryptographique

Avoir une coupure entre client et serveur comme
pour un proxy

Le cache TLS peut autoriser des certificats non valides sur une courte période

Avoir la même politique de journalisation des protocoles comme s’ils étaient en clairs

Authentification des clients TLS par certificats impossibles
Le proxy TLS stocke les flux en clair le temps d’appliquer les analyses
La gestion (création, déploiement, révocation) des
certificats peut être compliquée en fonction du
contexte
Protections des clients qui peuvent être compliquées à contourner
Protections des serveurs qui ne sont pas outrepassables

Table 5.2 – Récapitulatif de l’aspect technique
directement pour outre passer la vérification. La plupart du temps, la question à se poser concernant
ces sites sont : doit-on les laisser inaccessibles ? Doit-on les mettre en liste blanche ?

5.3

Récapitulatif

Afin d’y voir plus clair dans les enjeux et les risques liés aux éléments techniques de l’interception
TLS, le tableau tab. 5.2 p.38 va reprendre les divers points vus précédemment. Même si à première
vue, il existe plus de risques que d’enjeux à mettre en place l’interception TLS sur un plan technique,
il ne faut pas se fier au seul nombre de points enjeux/risques. En effet, la pondération de ces points est
primordiale car variera fortement en fonction du contexte. Par exemple, le risque lié aux problèmes de
performances réseau n’est valable que dans le cas où un fort trafic est analysé.

Edouard Petitjean — M2 MIAGE SIID

38

Chapitre 6

Une législation complexe
Chaque pays possède sa propre législation en matière de chiffrement et de son utilisation, aussi,
cet article ne traitera que la législation française. Pour cela, ce document va fortement se baser sur
les publications de la CNIL et de l’ANSSI. Mais nous verrons que ces entités n’ont pas toutes les
réponses juridiques car l’interception TLS n’est tout simplement pas encadrée par la loi française.
Aussi, l’objectif ne sera pas d’être conforme à la loi, mais d’éviter le plus possible d’être en infraction.

6.1

Un chiffrement libre sous condition

Avant de s’attaquer à la législation concernant le déchiffrement, voyons d’abord celle qui réglemente le chiffrement. Depuis l’année 2004, la LCEN 1 prévoit par son article 30 la libre utilisation
des moyens cryptographiques permettant les fonctions d’identification, d’intégrité et de confidentialité
des données 2 . C’est-à-dire que toute personne en France est dans son droit d’utiliser toutes formes
de chiffrement afin de préserver la confidentialité d’une donnée. Néanmoins, cela ne veut pas dire que
l’échange des données doit être opaque en toutes circonstances. En effet, par son article 37, la LCEN à
créé l’article 132-79 du code pénal qui définit les peines privatives de libertés en cas de crime ou délit,
et les moyens de chiffrement ont permis ou facilité leur préparation ou commission. Ces peines peuvent
monter jusqu’à la réclusion criminelle à perpétuité, mais, elles ne sont applicables que si l’auteur ou
complice n’est pas en mesure de fournir les messages en clair (non chiffrés), ni les moyens de chiffrement
(algorithmes et clefs) utilisés aux autorités judiciaires ou administratives.
Pour résumer, l’utilisation de tout type de chiffrement est légale tant qu’il est possible de fournir les
données en clair et les moyens cryptologiques utilisés, à la demande des autorités compétentes. Aussi,
l’utilisation du TLS est parfaitement autorisée en France, ce qui permet à de nombreux sites web de
proposer du chiffrement.
Dans la réalité, il est rare que les autorités demandent aux clients de fournir de telles données. Pour
rappel du fonctionnement de TLS, lors de l’établissement de la connexion, le client n’a pas l’obligation
de fournir un certificat, par conséquent, la paire de clefs qu’il utilisera pour une session TLS sera
dynamique et dépendra en partie de la clef publique du serveur distant. Au vu de cette complexité,
voire de l’impossibilité de récupérer ces clefs, ce sont souvent les propriétaires des serveurs qui sont
sollicités pour répondre aux besoins des autorités lors d’une enquête. Or, nous avons pu voir également
que pour les serveurs, leurs certificats peuvent servir uniquement pour l’authentification. Si tel est
le cas, le serveur utilisera également des paires de clefs dynamiques en fonction des clients. Autant
ce mode de fonctionnement permet d’accroître la sécurité — le serveur n’utilise pas qu’une paire de
clefs statiques, mais plusieurs dynamiques — autant il peut être compliqué pour l’administrateur de
fournir la paire de clefs utilisée pour une session précise. Ce qui peut entraîner des sanctions pénales
en fonction de la gravité du crime ou délit sur lequel les autorités enquêtent. L’interception TLS peut
permettre de stocker les données nécessaires sans pour autant prévoir un archivage de toutes les clefs
utilisées dans le temps.
1. Loi n◦ 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique.
2. Définition des moyens cryptologies donnée par l’article 29 de la LCEN.

Edouard Petitjean — M2 MIAGE SIID

39

Une législation complexe - Les obligations légales

6.2

Les obligations légales

Toute organisation a besoin de manipuler des données pour produire et prospérer. Ces données
peuvent concerner soit secrets internes (secrets de productions, méthodes de travail, etc...) ou des données personnelles recueillies au fil du temps. Dans ces deux cas, il existe un besoin réel de protéger ces
informations. Tant parce qu’elles permettent le bon fonctionnement de l’organisation qui les emplois,
que par les obligations légales qui en découlent.
La croissance forte de l’utilisation du TLS dans les usages du quotidien empêche bon nombre
d’organismes de procéder à des contrôles de sécurité satisfaisants. Or, le manque de contrôle sur les
données transitant sur un réseau peut avoir des répercussions juridiques importantes. L’interception
TLS est donc un réel enjeu juridique sur le fonctionnement d’une structure.

6.2.1

Données personnelles : la protection quoiqu’il arrive

La CNIL définit par données personnelles « toutes informations relatives à une personne physique
identifiée ou qui peut être identifiée, directement ou indirectement, par référence à un numéro d’identification ou à un ou plusieurs éléments qui lui sont propres. Pour déterminer si une personne est
identifiable, il convient de considérer l’ensemble des moyens en vue de permettre son identification
dont dispose ou auxquels peut avoir accès le responsable du traitement ou toute autre personne » 3 .
Donc tous les systèmes d’informations permettant à une structure de vivre utiliseront forcément des
données personnelles telles qu’elles sont définies par la CNIL. Que ça soit par la gestion des ressources
humaines, la gestion commerciale, les services de santé et d’aide à la personne et autres, l’acquisition de
données personnelles et leurs traitements se fait naturellement selon le besoin de la structure. Aussi,
les traitements liés à ces données personnelles doivent faire l’objet d’une déclaration concernant la
finalité et les moyens de ces traitements auprès de la CNIL. Pour cela, un responsable de traitement
est nécessairement identifié (personne physique, service ou organisme) pour tout traitement déclaré 4 . Il
est par conséquent possible d’avoir plusieurs responsables de traitement au sein d’une même entreprise.
Le DRH (Directeur des Ressources Humaines) sera responsable des traitements dédiés aux informations
personnelles liées aux ressources humaines, tandis que le DSI (Directeur du Système d’Information) sera
responsable des données personnelles liés à l’utilisation quotidienne de son système par les utilisateurs.
Lorsqu’un responsable de traitement est identifié, plusieurs obligations en matière de protection
des données lui incombent. L’article 34 de la Loi 78-17 du 6 janvier 1978, ainsi qu’une directive
européenne 5 oblige un responsable de traitement de prendre toutes les mesures nécessaires afin de
préserver la sécurité des données. Pour cela, il doit empêcher toutes corruptions ou accès à des tiers
non autorisés. Pour le responsable, manquer à cette obligation l’expose à un risque pénal pouvant
monter à cinq ans de prison et 300 000 euros d’amende 6 .

6.2.2

L’interception TLS dans la protection des données

Même s’il peut y avoir plusieurs responsables de traitement au sein d’une entreprise, la gestion
du système d’information reste à la charge du service associé. De plus, les données propres à l’entreprise doivent faire l’objet d’une sécurisation importante afin d’éviter des problèmes de production,
d’espionnage, etc... Aussi, il n’est pas rare de voir un service informatique proposer, voire vendre, des
« services » aux autres secteurs de l’entreprise. Cela permet à la fois de centraliser les responsabilités
légales mais aussi d’optimiser la protection des données de l’entreprise et de mutualiser les outils de
sécurisation.
Pour la CNIL, l’employeur doit assurer la sécurité de son système d’information, par conséquent,
l’interception TLS est parfaitement légitime si elle est encadrée 7 . Pour cela, plusieurs critères doivent
être respectés.
Premièrement, l’utilisation de l’interception et de l’utilisation des flux interceptés doivent être en
accord avec les cinq principes clefs de la CNIL qui sont : la finalité du traitement, la proportionnalité
3. Article 2 de la Loi 78-17 du 6 janvier 1978
4. Article 3-I de la Loi 78-17 du 6 janvier 1978
5. Article 17 de la directive 95/46/CE du Parlement européen et du Conseil, du 24 octobre 1995, relative à la
protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de
ces données
6. Article 226-17 du code pénal.
7. https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions

Edouard Petitjean — M2 MIAGE SIID

40

Une législation complexe - Les obligations légales

des moyens mis en oeuvre et la pertinence des données analysées, la durée de conservation des données
traitées, la sécurité et confidentialité des données recueillies, et pour finir, le respect des droits à la
personne 8 .
Deuxièmement, puisque l’interception TLS va donner la possibilité à des personnes habilitées de
l’entreprise, la possibilité de visualiser des informations normalement confidentielles aux utilisateurs,
plusieurs mesures sont nécessaires 9 .
L’information aux utilisateurs
Il est important que si la technique d’interception TLS est mise en pratique, les utilisateurs impactés soient avertis. Une explication claire et précise sur les raisons qui ont amené la mise en oeuvre
de cette technique doit être donnée aux utilisateurs. Également, le détail des flux interceptés devra
être communiqué (population d’utilisateurs impactée, protocoles interceptés, sites présents dans une
liste blanche non soumise à l’interception, les données recueillies, etc...) afin de laisser la liberté aux
utilisateurs de naviguer ou non en toute connaissance de cause.
Cette notification peut très bien se faire au travers de la charte informatique. Néanmoins, il ne faut
pas oublier que pour qu’une charte informatique soit opposable aux salariés, elle doit être déployée au
même titre que le règlement intérieur.
L’accès aux courriers électroniques
L’interception des courriers électroniques est soumise aux mêmes règles que leur exploitation sur un
serveur de messagerie. Il est nécessaire de définir précisément des processus d’accès (administrateurs,
droits, méthodes, contextes) aux courriers électroniques des utilisateurs. Pour rappel, tous les courriers
électroniques envoyés et reçus par la messagerie de l’entreprise sont présumés professionnels à moins
d’être explicitement identifiés comme étant personnels.
Minimisation des traces conservées
Un des enjeux de l’interception TLS est la journalisation des flux. Il est très important que la
journalisation des flux interceptés se base sur les mêmes critères que la journalisation d’un flux en clair
le permet. Aussi, il est possible de journaliser la source et destination d’un flux, le protocole utilisé,
quelques métadonnées, etc... Mais le contenu des messages échangés ne doit pas faire l’objet d’un
stockage ciblé. Aussi, il n’est pas autorisé de conserver les identifiants, mots de passe, codes personnels
et autres.
Une protection des données d’alertes extraite de l’analyse
C’est-à-dire que tout résultat suite à un traitement ne doit être accessible que par des personnes
habilitées à voir ces résultats.

6.2.3

La responsabilité en cas de crime ou délit

Comme je l’ai évoqué dans la section Un chiffrement libre sous condition p.39, il existe un risque
que le chiffrement des moyens de communication puisse permettre ou faciliter les crimes ou délits. Dans
tel cas, la LCEN prévoit d’alourdir la peine de prison en fonction de la gravité du crime ou délit. Mais
dans le cadre d’un organisme, il ne faut pas oublier que chaque salarié est sous la responsabilité d’une
personne, et qu’en cas de crime ou délit commis par le salarié, le responsable de ce salarié, ainsi que le
service informatique, peut voir sa responsabilité civile engagée. Il est donc nécessaire de déployer les
moyens adéquats pour prévenir et bloquer l’utilisation illégale du système informatique.
La responsabilité du responsable du salarié
Dans le cas où un salarié utilise les outils professionnels, pendant ses heures et sur son lieu de
travail, pour commettre un crime ou un délit, la responsabilité civile de la personne qui répond du
salarié peut être engagée sur le fondement de l’article 1242 du code civil. Cette responsabilité a déjà
8. https://www.cnil.fr/sites/default/files/typo/document/Guide_employeurs_salaries.pdf.pdf
9. https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions

Edouard Petitjean — M2 MIAGE SIID

41

Une législation complexe - Les obligations légales

été engagée en 2003. En effet la société Estoca avait attaqué la société Lucent Technologies pour un
site web litigieux créé par un de ses employés. La société Lucent Technologies a bel et bien été déclarée
responsable sur le fondement de l’article précédemment cité 10 .
La responsabilité du service informatique
Toujours dans le cas où un salarié commet un crime ou délit en utilisant les outils informatiques
de l’entreprise, la responsabilité civile du DSI et/ou de son équipe peut être engagée. Non pas qu’ils
doivent répondre du salarié, mais sur la base que si le salarié a pu commettre le crime, c’est grâce
aux moyens fournis sans avoir mis en place des contre-mesures ou avoir notifié la direction des risques
possibles. Aussi, la direction peut engager la responsabilité du service informatique sur le principe de
la négligence en se basant sur l’article 1241 du code civil.

6.2.4

L’obligation d’une journalisation

La LCEN prévoit une disposition particulière pour les fournisseurs d’accès à Internet (FAI). La
définition d’un FAI se résume à « toute personne physique ou morales dont l’activité est d’offrir un
accès à des services de communication au public en ligne » 11 . Pour ces FAI, la LCEN leur impose de
concourir à la lutte contre « l’apologie des crimes contre l’humanité, la provocation à la commission
d’actes de terrorisme et de leur apologie, l’incitation à la haine raciale, la haine à l’égard de personnes
à raison de leur sexe, de leur orientation ou identité sexuelle ou de leur handicap ainsi que de la
pornographie enfantine, de l’incitation à la violence, notamment l’incitation aux violences faites aux
femmes, ainsi que des atteintes à la dignité humaine » 12 . Cela se traduit pour les FAI à détenir et
conserver toutes « les données de nature à permettre l’identification de quiconque a contribué à la
création du contenu ou de l’un des contenus des services dont elles sont prestataires » 13 .
Mais en 2006, la loi antiterrorisme étend les obligations des FAI à toutes structures et personnes
permettant un accès Internet, privé ou public 14 . Par conséquent, à partir du moment où un accès
Internet est déployé dans n’importe qu’elle organisme, il est obligatoire de converser tous éléments
permettant l’identification tel que définie dans l’article 6-II de la LCEN. La loi oblige la conversation
de ces données pour la période d’un an avant de pouvoir anonymiser ou supprimer ces données 15 .

6.2.5

La loi HADOPI

La loi HADOPI est surtout connue en France pour être une loi antipiratage des oeuvres circulant sur
les réseaux peer-to-peer 16 . Pour les entreprises, cette loi est un risque à prendre en compte puisqu’elle
introduit une nouvelle notion : la négligence caractérisée 17 . Ainsi, si le réseau d’entreprise est utilisé a
des fins malveillantes, l’entreprise peut être tenue pour responsable car elle n’aura pas ou mal mis en
oeuvre les moyens de protections sur son réseau. Cette obligation de surveillance et de protection est
appuyée par l’article L336-3 du Code de la propriété intellectuelle quand il s’agit d’une atteinte aux
droits d’auteurs (téléchargement illégal, distribution de contrefaçon).

6.2.6

Interception dans le cadre judiciaire

Nous l’avons vu précédemment, l’utilisation du chiffrement est libre mais à condition de pouvoir
communiquer les clefs de chiffrement. Mais pas seulement, il existe une obligation légale de déchiffrement lors d’une interception judiciaire 18 , ou dans le cadre d’interception de sécurité 19 ou encore lors
d’une enquête ou instruction 20 .
10. TGI Marseille, 11 juin 2003, D. 2003
11. Article 6-I-1 de la LCEN
12. Article 6-I-7 de la LCEN
13. Article 6-II de la LCEN
14. Article 34-1-I du Code des postes et des communications électroniques
15. 34-1-II du Code des postes et des communications électroniques
16. Est un modèle de réseaux informatiques basé sur le client-serveur mais dans lequel tous les clients sont serveurs et
inversement.
17. Article R335-5 du Code de la propriété intellectuelle
18. Article 100 à 100-8 du Code de la procédure pénale
19. Article L241-1 à 245-3 du Code de la sécurité intérieure
20. Article 230-1 du Code de la procédure pénale

Edouard Petitjean — M2 MIAGE SIID

42

Une législation complexe - La légalité de l’interception TLS

Même si ces obligations concernent toutes formes d’interceptions des communications, le TLS est un
peu particulier car il est extrêmement compliqué, même pour un organisme étatique d’intercepter une
communication chiffrée avec TLS. Aussi, il est possible que dans le cadre d’une interception judiciaire,
une entreprise soit sollicitée pour mener à bien cette interception.

6.3

La légalité de l’interception TLS

Pour le moment, nous n’avons traité que les risques légaux que le chiffrement de données entraîne
pour un individu ou à une entité. Aussi, nous pourrions croire qu’il faudrait impérativement mettre
en place cette technique afin d’éviter des risques judiciaires importants, mais nous allons voir que la
mise en place du déchiffrement expose également à des risques juridiques loin d’être anodins.

6.3.1

Des atteintes aux secrets

En mettant en pratique l’interception TLS, beaucoup de problèmes de confidentialité peuvent
subvenir. En effet, il n’est possible d’analyser le contenu qu’une fois un message déchiffré, or, le simple
fait de déchiffrer le message peut être considéré comme une infraction.
Le secret des correspondances privées
Le premier problème auquel il est facile de penser est celui lié au secret des correspondances privées.
Puisque l’interception d’un message électronique est punie d’un an d’emprisonnement et 45 000 euros
d’amende 21 , un mécanisme permettant de tous les intercepter est clairement contraire à cette loi.
La protection des données personnelles
Précédemment, nous avons vu l’importance de protéger les données personnelles au sein d’un organisme 22 . Néanmoins, il ne faut pas oublier que l’interception TLS est en soi un traitement appliqué
aux diverses données qu’il manipulera. Par conséquent, son utilisation non déclarée ni encadrée peut
entraîner une peine de cinq ans de prison et de 300 000 euros d’amende 23 .
Un autre problème relatif aux données personnelles est celles non gérées par l’entreprise. Pour
qu’une déclaration auprès de la CNIL soit valable, il faut détailler les finalités et moyens mis en place,
mais aussi les données qui feront l’objet du traitement. Or, avec l’interception TLS qui peut déchiffrer
beaucoup de choses, il est plus que probable qu’il analyse des données personnelles qui ne seront
pas déclarées auprès de la CNIL (par exemple : numéro de carte bancaire, dossiers administratifs ou
médicaux). Même, il peut permettre de prendre connaissance de données personnelles que l’entreprise
n’a pas à connaître.
Même si la CNIL autorise et recommande l’analyse des flux chiffrés tant qu’elle est encadrée, cela
n’ôte pas pour autant les risques juridiques liés aux traitements de données personnelles.
La vie privée des utilisateurs
Les utilisateurs ont le droit d’utiliser les outils professionnels pour des activités personnelles pendant les heures de travail, tant que cette utilisation personnelle reste acceptable 24 . Par conséquent,
l’utilisateur est susceptible de communiquer des propos, photos et vidéos sur des plateformes publiques
ou privées. Dans de tels cas, l’interception de ces données, sans le consentement de son auteur peut
valoir un an d’emprisonnement et 45 000 euros d’amende 25 . Pour aller plus loin, la détention d’un
dispositif technique permettant cette interception non consentie expose à un risque de cinq années de
prison et 300 000 euros d’amende 26 .
21.
22.
23.
24.
25.
26.

Article 226-15 du Code pénal
Cf. Données personnelles : la protection quoiqu’il arrive p.40
Articles 226-16 à 226-24 du Code pénal
Arrêt Nikon, le 2 octobre 2001
Article 226-1 à 226-7 du Code pénal
Article 226-3 du Code pénal

Edouard Petitjean — M2 MIAGE SIID

43

Une législation complexe - Récapitulatif

La sensibilité des informations
Cela a été dit précédemment, l’interception TLS va analyser et prendre connaissance de beaucoup
de données. Cela peut être problématique pour certaines activités. D’une part, les divers secrets professionnels, auxquels seules les personnes habilitées doivent avoir connaissance, peuvent être connus
des personnes travaillant sur l’interception TLS. Cela peut être plus gênant quand il s’agit d’informations hautement confidentielles et/ou pouvant entraîner un risque de conflit d’intérêts. Par exemple,
des informations sur une restructuration de l’entreprise, une négociation de salaire d’un collègue, ou
encore un échange entre des salariés protégés.
Nous pouvons aussi avoir des données qui sont protégées par une réglementation spécifique, comme
la réglementation relative à la protection du patrimoine scientifique et technique de la nation. Ou
encore des données relatives aux secrets de la défense nationale 27 .

6.3.2

La sous-traitance

Dans un modèle de gestion où les compétences informatiques sont de plus en plus sous-traitées,
il n’est pas rare que des employés d’une autre entité manipulent les équipements de sécurité relatifs
au système d’information, et bien sûr, à l’interception TLS. Aussi, il est important de bien encadrer
le périmètre précis et les actions que le prestataire pourra effectuer. En effet, la sous-traitance de la
compétence ne signifie pas la délégation des risques juridiques. L’entreprise qui emploie la sous-traitance
est toujours responsable si le sous-traitant commet des crimes et délits avec les moyens de l’entreprise.
Dans l’affaire du piratage de Greenpeace par un sous-traitant d’EDF, EDF a vu sa responsabilité
pénale engagée et a été condamnée à verser 1 500 000 euros 28 .

6.3.3

Atteinte au STAD ?

La question la plus problématique auquelle même la CNIL ne saurait répondre est la suivante :
l’interception TLS porte-t-elle atteinte au STAD 29 ?
Le terme de STAD est un terme bien trop vague pour en définir un périmètre précis. Par exemple,
le réseau de France Telecom dans son ensemble est un STAD. Un disque dur peut être aussi considéré
comme un STAD. Donc, est-ce que la mise en place de l’interception TLS porte atteinte dans le sens où
elle intercepte un trafic entre deux entités formant à ce moment-là un STAD ? Ou bien l’interception
TLS fait elle-même partie du STAD ?
Même si cette question peut sembler déroutante, il est nécessaire de ne pas être certains de son
interprétation. Les infractions concernant les STAD sont définies par les articles 323-1 à 323-7 du code
pénal, Les peines pouvant varier de deux ans de prison et 60 000 euros d’amende à dix ans de prison
et 300 000 euros d’amende.
La principale incertitude concernant cette question est que malgré la croissance de l’interception
TLS dans les entreprises, il n’y a eu à ce jour, aucune affaire, et donc aucune jurisprudence concernant
ce point.

6.4

Récapitulatif

La véritable problématique de l’interception TLS est qu’il n’existe aucun cadre légal qui lui est
consacré. La CNIL et l’ANSSI l’autorisent car elle permet d’accroître la sécurité des systèmes d’informations mais leurs autorisations ne valent pas la loi. Par conséquent, tant qu’il n’y aura pas de texte
l’encadrant spécifiquement, tant qu’il n’y aura pas eu de jurisprudence sur son utilisation, et tant que
le terme STAD sera toujours aussi large, la mise en place ou non de l’interception sur un plan légal se
résumera à cette question : ne pas déchiffrer et être responsable par manque d’informations, ou mettre
en place et être responsable d’atteintes aux STAD et données diverses ?
27. n◦ 1300/SGDSN/PSE/PSD du 30 novembre 2011
28. https://www.legalis.net/jurisprudences/tribunal-correctionnel-de-nanterre-jugement-du-10-novembre2011/
29. Système de Traitement Automatisé de données, un terme juridique extrêmement large désignant un ensemble
composé d’une ou plusieurs unités de traitement, de mémoire, de logiciel, de données, d’organes d’entrées-sorties et de
liaisons, qui concourent à un résultat déterminé, cet ensemble étant protégé par des dispositifs de sécurité.

Edouard Petitjean — M2 MIAGE SIID

44

Une législation complexe - Récapitulatif

Enjeux

Risques

Une cryptographie libre à condition de pouvoir
fournir des données en clair

Atteinte aux secrets des correspondances

Responsable de traitement des données en charge
de les protéger

Atteinte aux données personnelles non gérées par
l’entreprise

L’employeur doit assurer la sécurité de son système

Atteinte à la vie privée des utilisateurs

L’employeur et le service informatique peuvent être
responsables en cas de crimes ou délits commis

Atteinte à des données sensibles

Obligation de journaliser si un accès Internet est
fourni

Gestion des sous-traitants ayant accès aux données
déchiffrées

Se prémunir de la négligence caractérisée (loi HADOPI)

Incertitude sur l’atteinte aux STAD

Obligation légale de déchiffrement lors d’enquête
judiciaire
Table 6.1 – Récapitulatif de la législation française
Comme pour l’aspect technique, le tableau tab. 6.1 p.45 va présente les enjeux et risques légaux de
mettre en place cette technique.

Edouard Petitjean — M2 MIAGE SIID

45

Chapitre 7

L’impact sociologique
Nous allons terminer cette partie en parlant un peu 1 de l’impact sociologique que peut avoir
cette technique sur les utilisateurs. En effet, très souvent dans les diverses présentations techniques de
sécurisation, on nous présente les divers enjeux et risques d’un point de vue technique et surtout légal.
Ce n’est pas pour rien, car à la vue des diverses condamnations qui peuvent être sévères, l’argument
légal fait souvent mouche auprès des DSI et des employeurs.
Or, il est aussi important de comprendre que certaines techniques de sécurisation 2 peuvent avoir
un impact sur les utilisateurs, qui se répercute par la suite sur leur relation vis à vis du système
d’information. Il existe plusieurs cas de figure sur l’évolution des utilisateurs, mais deux me viennent
directement à l’esprit : utiliser le moins possible le système et essayer de contourner la sécurité. Dans
ces deux cas, cela entraîne souvent une baisse de la productivité ainsi qu’une mauvaise utilisation du
système.

7.1

La destruction de la relation de confiance

Dans une époque où les réseaux sociaux et les diverses messageries prennent une place importante
dans la vie quotidienne, l’interception TLS peut être vue comme une tentative d’atteinte à la vie
privée par les utilisateurs. Il est vrai que les différents réseaux sociaux et messageries web proposent
des conditions d’utilisation très intrusives dans la vie privée des utilisateurs. Pour autant, ces derniers
les acceptent. A côté de cela, le fait que les administrateurs de l’entreprise aient accès aux données
déchiffrées choque ces mêmes utilisateurs peut prêter à sourire. Mais les utilisateurs ont une relation
plus directe avec les administrateurs de leur société. En effet, contrairement aux sites distants utilisés
par les salariés pour partager leurs informations, ils n’ont aucun contact avec les personnes gérant
leurs données sur ces sites. Ce n’est pas le cas pour le service informatique de leur entreprise, que
les utilisateurs sont amenés à joindre assez régulièrement ou à côtoyer quotidiennement pour diverses
raisons. Aussi, il faut se poser la question de savoir si ces personnes ne seront pas gênées à parler avec
des administrateurs qui peuvent potentiellement voir tous leurs échanges sur divers sites.

7.2

Une surveillance en trop ?

C’est la question que beaucoup d’utilisateurs peuvent se poser. En effet, de plus en plus de sites, notamment les réseaux sociaux, prônent le chiffrement et n’hésitent pas à publier des articles permettant
d’expliquer en quoi c’est nécessaire. L’interception TLS peut être vue comme un moyen de censurer ou
de détecter des comportements déviants, voir même un moyen de trouver des preuves pour licencier
des personnes. Ce genre de réaction est d’autant plus probable si de la prévention de perte de données
est mise en place, car c’est typiquement une technique permettant de censurer des données allant vers
Internet.
1. Ce chapitre sera très court car n’ayant pas de réelle étude pour accompagner les propos, juste quelques idées seront
évoquées.
2. L’impact sociologique ne concerne pas uniquement les techniques de sécurisation, mais nous ne traiterons que
celles-ci dans cet article pour rester dans le thème.

Edouard Petitjean — M2 MIAGE SIID

46

L’impact sociologique - La nécessité d’informer

De plus, il est probable que des salariés changent d’attitude suite à l’ajout d’une surveillance. Ce
qui est parfaitement naturel pour chacun d’entre nous. Autant, une surveillance supplémentaire peut
amener à stopper des utilisations frauduleuses qui sont faites du système d’informatique. Autant, il
est tout aussi possible que des utilisateurs qui utilisaient correctement le système changent leur façon
de travailler, croyant que leurs anciennes méthodes allaient contre les règles. Or, ces changements de
moyens de travailler peuvent entraîner une baisse de la productivité. Un article intitulé La surveillance
n’améliore pas la productivité 3 écrit par « Hubert Guillaud » 4 propose l’idée qu’une surveillance trop
importante est contre-productive pour une entreprise car restreignent trop les salariés.

7.3

La nécessité d’informer

L’impact social ne se limite pas uniquement à ce qui a été dit, c’est un domaine très complexe qui
demande beaucoup de réflexion car chaque personne peut réagir de façon propre. C’est pour cela qu’il
est difficile de prévoir tous les cas de figure, mais le meilleur moyen de limiter son impact est de passer
par une explication claire et précise des raisons de la mise en place de l’interception TLS. Que ce soit
par une note explicative qui désignera les personnes étant habilités à voir les données déchiffrées et
dans quels cas ils le pourront, ou part l’animation de séances en groupe pour expliquer mais surtout
répondre aux interrogations des utilisateurs.
Un rappel sur le secret professionnel afférant aux administrateurs et de l’impossibilité à toutes
personnes de demander des données personnelles peuvent aussi être une bonne chose pour rassurer les
utilisateurs.

3. http://internetactu.blog.lemonde.fr/2014/06/07/la-surveillance-nameliore-pas-la-productivite/
4. Journaliste français connu pour son travail au sein de la fondation internet nouvelle génération

Edouard Petitjean — M2 MIAGE SIID

47

Troisième partie

Quelques bonnes pratiques

Edouard Petitjean — M2 MIAGE SIID

48

Chapitre 8

Des réflexes à avoir
Dans cette partie, je vous propose une liste des bonnes pratiques lors de la mise en place de
l’interception TLS. Cette liste ne se serait être exhaustive car il existe beaucoup de solutions proposant
cette fonctionnalité et chacune de ces solutions peuvent avoir des spécificités.
Nous verrons d’abord quelques pratiques à prendre en compte pour la partie technique, puis dans
un second temps, les réflexes pour éviter les risques juridiques.

Edouard Petitjean — M2 MIAGE SIID

49


Aperçu du document Interception_SSL-TLS_Fonctionnement_Enjeux_Risques_Pratiques.pdf - page 1/62
 
Interception_SSL-TLS_Fonctionnement_Enjeux_Risques_Pratiques.pdf - page 2/62
Interception_SSL-TLS_Fonctionnement_Enjeux_Risques_Pratiques.pdf - page 3/62
Interception_SSL-TLS_Fonctionnement_Enjeux_Risques_Pratiques.pdf - page 4/62
Interception_SSL-TLS_Fonctionnement_Enjeux_Risques_Pratiques.pdf - page 5/62
Interception_SSL-TLS_Fonctionnement_Enjeux_Risques_Pratiques.pdf - page 6/62
 




Télécharger le fichier (PDF)


Interception_SSL-TLS_Fonctionnement_Enjeux_Risques_Pratiques.pdf (PDF, 1.1 Mo)

Télécharger
Formats alternatifs: ZIP



Documents similaires


interception ssl tls fonctionnement enjeux risques pratiques
archinet systeme
netasq v9 0 nafrgde firewalluserguide
ssl openssl appache carrette baud 2
ch853uo
administration de service ssh sous linux

Sur le même sujet..