L'interception SSL/TLS : le fonctionnement, entre enjeux et risques, les bonnes pratiques

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 » ¹, 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² 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.

Edouard Petitjean M2 MIAGE SIID 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 2

Sommaire

I	L'interception SSL		4
1	Quelle différence entre SSL et TLS?		5
	1.1	Historique du SSL et du TLS	5
	1.2	Obsolescence du SSL	5
	1.3	Un abus de langage historique	7
2	TLS : un protocole compliqué?		8
	2.1	Les objectifs du TLS	8
	2.2	Le positionnement du TLS dans le modèle TCP/IP	8
	2.3	Un protocole fortement évolutif	9
	2.4	Rappel cryptographique	9
		2.4.1 Chiffrement symétrique	9
		2.4.2 Chiffrement asymétrique	10
		2.4.3 Empreinte numérique	11
	2.5	Authentification: un principe de confiance	12
		2.5.1 Certificat X.509 : La carte d'identité numérique	13
		2.5.2 La relation de confiance	14
		2.5.3 PKI : La confiance via un tiers	15
	2.6	TLS : le protocole en détail	17
		2.6.1 Les messages d'extension	17
		2.6.2 TLS Record Protocol	17
		2.6.3 Handshake Protocol	19
		2.6.4 Alert Protocol	22
		2.6.5 Change Cipher Spec Protocol	22
3	L'interception TLS		23
	3.1	L'interception TLS sortante	24
		3.1.1 Le placement du proxy TLS	25
		3.1.2 Une autorité de certification interne	25
	3.2	L'interception TLS entrante	26
		3.2.1 Le placement du proxy TLS	27
		3.2.2 Hébergement des clefs privées	27

II Des Enjeux et Des Risques 28

4 L'origine du chiffrement des échanges 29

5 Aspect technique 31

5.1 Enjeux sécuritaires 31

5.1.1 Les pare-feux nouvelle génération: l'analyse poussée 31

5.1.2 Utilisation d'un proxy 32

5.1.3 Journalisation des connexions 32

5.2 Risques : les contraintes techniques 33

5.2.1 La performance 33

Edouard Petitjean M2 MIAGE SIID 3

			SOMMAIRE - SOMMAIRE
	5.3	5.2.2 L'interception 5.2.3 Les protections des clients 5.2.4 La protection des serveurs Récapitulatif	34 36 37 38
6	Une législation complexe		39
	6.1	Un chiffrement libre sous condition	39
	6.2	Les obligations légales	40
		6.2.1 Données personnelles : la protection quoiqu'il arrive	40
		6.2.2 L'interception TLS dans la protection des données	40
		6.2.3 La responsabilité en cas de crime ou délit	41
		6.2.4 L'obligation d'une journalisation	42
		6.2.5 La loi HADOPI	42
		6.2.6 Interception dans le cadre judiciaire	42
	6.3	La légalité de l'interception TLS	43
		6.3.1 Des atteintes aux secrets	43
		6.3.2 La sous-traitance	44
		6.3.3 Atteinte au STAD?	44
	6.4	Récapitulatif	44
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 49

9 La mise en oeuvre technique 50

9.1 L'interception sortante 50

9.1.1 Gestion de l'AC interne 50

9.1.2 Protection des clefs privées 50

9.1.3 Sécurité des connexions entre les clients internes et le proxy TLS 50

9.1.4 Sécurité des connexions entre le proxy TLS et les serveurs 51

9.1.5 Protection de la vie privée 51

9.2 L'interception entrante 51

9.2.1 Sécurisation entre les clients externes et le reverse proxy TLS 51

9.2.2 Protection des clefs privées 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 54

Edouard Petitjean M2 MIAGE SIID 4

Première partie

L'interception SSL

Edouard Petitjean M2 MIAGE SIID 5

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 ¹ et TLS ². 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³ (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⁴ 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⁵, de l'AES⁶ ou encore du SNI⁷.

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⁸, 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 ⁹ 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 6

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 7

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 ¹⁰ (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 8

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 ¹ 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² é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³ ». 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.

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







Edouard Petitjean M2 MIAGE SIID 9

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⁴ 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 10

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 11

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 12

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⁶.

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 = cBob_pub(m)

s = cAlice_pri(Hash(m))

Bob reçoit le message,

m = dBob_pri(e) h = Hash(m)

h' = dAlicep_ub(s)

Si h et h^' 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 13

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 . 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 14

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⁸ 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⁹ (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 ¹⁰ 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 15

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 ». Celui-ci 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¹¹) 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¹², 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 16

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

Certiica client final

Sujet: wwe .edouard.petitjean.com
E metteu r : petitj ean. interm ediaire

Certtica signé par

« petitjean. intermédiaire »



www.edouard.petitjean.com



3-- L'AC renvoi le certiftat sgné

--Le certificat est valide.
Bob peut établir une rely ion de
confiance avec

r www.edouard.petitjeancom

A -- Bob veut établir une con nation sécurisée avec

evvrw.edouard.petitjean.com e

2 --Le serveur envoi un CSR pour

saner son certifica

5-- Le serveur envoi son certificat et la

chaire de

certification

7 -- Bob demande l liste de révocaion auprés de rAC intermédiaire

AC intermédiaire :
petit jean.intermédiaire

Bob

8 - L'AC intermédiaire envoi sa liste de révocation

1 - Délégation de la gestion

des oertificetsé une ^AC Irrtermediaire	6 -- Le certificat reçu est signé par uneAC Intermédiaire dé pende nt ô un AC Racine. Bob va vérifier la signature de l'AC Racine avec celle de sa base de connaissances erti lccA sur sorti poste 1
	Base c rAC Racine de confiance

FIGURE 2.4 - Echange avec un serveur utilisant un certificat signé

Edouard Petitjean M2 MIAGE SIID 17

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 appli-catives 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 SecurityParame-ters(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 ser-ver_random seront utilisés pour générer six nouvelles clefs :

Edouard Petitjean M2 MIAGE SIID 18

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



uint8 enc_

key_length ;

length;

uint8 block_

iv_length ;

uint8 fixed_

uint8 record_

iv_length ;

MACAlgorithm mac_algorithm ;

uint8 mac_

uint8 mac_

CompressionMethod compression_algorithm ;

opaque master_secret [ 4 8 ] ;

opaque client_random [ 3 2 ] ;

opaque server_random [ 3 2 ] ;

} SecurityParameters ;

key_length ;

length;

struct {

ConnectionEnd entity;

PRFAlgorithm prf_algorithm ;

BulkCipherAlgorithm bulk_cipher_algorithm ;

CipherType cipher_type ;

FIGURE 2.5 - Définition de SecurityParameters dans la RFC5246

struct {

ContentType type;

ProtocolVersion version;

uint16 length;

opaque fragment [ TLSPlaintext . length];

} 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 19

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 2¹⁴, 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 2¹⁴ 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 2¹⁴ + 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 2¹⁴ 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 à 2¹⁴ + 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 20

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 1^er 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 21

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é¹⁴ 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 22

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 23

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 24

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', 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 25

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.site-sé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 26

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², 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 ³) 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 27

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.

Deuxième partie

Edouard Petitjean M2 MIAGE SIID 28

Des Enjeux et Des Risques

Edouard Petitjean M2 MIAGE SIID 29

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 XVI^iè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² ainsi que la machine Enigma³ 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 ⁴. 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 30

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⁶, 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 ⁷. 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⁸, mais surtout par la préconisation qu'en font la CNNum⁹(Conseil National du Numérique) et l'ANSSI ¹⁰(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 31

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 ¹ (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² 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 32

Aspect technique - Enjeux sécuritaires

base souvent sur une analyse basée sur la signature ³, 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⁴ 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 ⁵), 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⁶, 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 ⁷. 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 33

Aspect technique - Risques : les contraintes techniques

	HTTP	TLS	TLS intercepté
Temps de traitement global (en s)	132,552	171,716	772,082
Requêtes traitées par seconde	37,72	29,12	6,48
Requêtes échouées	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é⁸.

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⁹ 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 34

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 ¹⁰) 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 ¹². 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. Méthode permettant à deux tiers de générer une paire de clefs asymétriques sans avoir à les échanger.

11. Plateforme d'apprentissage en ligne.

12. La courbe elliptique est un cas particulier de courbe algébrique utilisée dans divers domaine dont la cryptographie pour trouver des nombres premiers très grands rapidement

Edouard Petitjean M2 MIAGE SIID 35

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 36

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¹⁵ 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 37

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 ¹⁶ (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¹⁷ 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, faut-il 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¹⁸, 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¹⁹ 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-cert-query.html

Edouard Petitjean M2 MIAGE SIID 38

Aspect technique - Récapitulatif

Enjeux	Risques
L'analyse protocolaire (reconnaissance des applica-Peut tions)	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 don- né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 pro- tocoles comme s'ils étaient en clairs	Authentification des clients TLS par certificats im-possibles
	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 outrepas-sables

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 39

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¹ 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 ². 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 40

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é ⁴. 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⁵ 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.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 ⁷. 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 41

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⁹.

L'information aux utilisateurs

Il est important que si la technique d'interception TLS est mise en pratique, les utilisateurs im-pacté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 42

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é¹⁰.

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 » ¹¹. 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 » ¹². 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 ¹⁴. 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¹⁶. Pour les entreprises, cette loi est un risque à prendre en compte puisqu'elle introduit une nouvelle notion : la négligence caractérisée ¹⁷. 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 ¹⁸, ou dans le cadre d'interception de sécurité ¹⁹ ou encore lors d'une enquête ou instruction²⁰.

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 43

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²¹, 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 or-ganisme²². 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²³.

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 ²⁴. 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²⁵. 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²⁶.

21. Article 226-15 du Code pénal

22. Cf. Données personnelles : la protection quoiqu'il arrive p.40

23. Articles 226-16 à 226-24 du Code pénal

24. Arrêt Nikon, le 2 octobre 2001

25. Article 226-1 à 226-7 du Code pénal

26. Article 226-3 du Code pénal

Edouard Petitjean M2 MIAGE SIID 44

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²⁷.

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²⁹ ?

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-novembre-2011/

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 45

Une législation complexe - Récapitulatif

Enjeux	Risques
Une cryptographie libre à condition de pouvoirAtteinte fournir des données en clair	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 ^êtreAtteinte responsables en cas de crimes ou délits commis	à 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 ^HA-Incertitude DOPI)	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 46

Chapitre 7

L'impact sociologique

Nous allons terminer cette partie en parlant un peu¹ 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² 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.

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é³ é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.

Edouard Petitjean M2 MIAGE SIID 47

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

Troisième partie

Edouard Petitjean M2 MIAGE SIID 48

Quelques bonnes pratiques

Edouard Petitjean M2 MIAGE SIID 49

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 50

Chapitre 9

La mise en oeuvre technique

Pour exposer les différentes pratiques, nous diviserons la partie technique en deux sections. L'une traitera de l'interception sortante, qui est plus complexe, la seconde portera sur l'interception entrante.

9.1 L'interception sortante

9.1.1 Gestion de l'AC interne

-- Utiliser une sous-autorité de certification dédiée à l'interception TLS dans le cas d'une utilisation d'une PKI.

-- Ne jamais utiliser les autorités de certification intégrées nativement dans les diverses solutions. C'est prendre le risque d'utiliser les mêmes clefs que les autres entités qui ont la même solution, ou utiliser un certificat obsolète.

-- Recenser toutes les solutions de navigation utilisées par les utilisateurs afin de prévoir un déploiement de certificat pour toutes ces solutions.

9.1.2 Protection des clefs privées

-- L'utilisation d'un HSM ¹ est fortement conseillée pour le stockage des clefs et leur utilisation. L'ANSSI propose une liste de solutions certifiées 2.

-- Revoir les droits systèmes liés aux fichiers contenant les clefs privées. Seul le service qui utilisera les clefs privées devrait avoir les droits de lecture sur ces clefs. Tous les autres accès provenant d'un autre service devront être prohibés.

9.1.3 Sécurité des connexions entre les clients internes et le proxy TLS

-- Limiter l'utilisation du TLS aux versions 1.2 et 1.1, en proposant un ordre décroissant des versions.

-- Lors de la génération du certificat de l'AC utilisé par le proxy TLS ainsi que les certificats générés à la volée, il est conseillé d'utiliser des suites cryptographiques robustes. L'ANSSI a publié une annexe (RGS B1 ³) pour savoir comment choisir les bonnes suites cryptographiques.

-- L'utilisation du PFS (Perfect Forward Secrecy) est importante. Il permet de protéger les connexions passées en cas de compromission de la clef privée.

-- La désactivation de la compression permet d'éviter les attaques CRIME⁴ et ses variantes. -- Limiter le cache TLS afin de se prémunir d'une absence de vérification trop longue.

1. Hardware Security Module, est un composant matériel permettant la génération, stockage et protection des clefs cryptographique. Il permet également une protection lors de calcul cryptographique.

2. https://www.ssi.gouv.fr/entreprise/qualifications/

3. https://www.ssi.gouv.fr/uploads/2015/09/RGS\_B\_1.pdf

4. Compression Ratio Info-leak Made Easy, est une attaque se basant sur une vulnérabilité qui apparaît pendant l'utilisation de l'algorithme de compression DEFLATE.

Edouard Petitjean M2 MIAGE SIID 51

La mise en oeuvre technique - L'interception entrante

9.1.4 Sécurité des connexions entre le proxy TLS et les serveurs

-- Si possible, limiter l'utilisation du TLS aux versions 1.2 et 1.1, en proposant un ordre décroissant des versions.

-- Si le point précédent bloque l'utilisation de certains sites distants, il faut utiliser une liste d'exception qui permettra un accès avec les versions TLS 1.0 ou SSL 3.0. Cela permet d'éviter d'autoriser ces versions à tout site alors que ces versions sont vulnérables.

-- Le comportement du proxy TLS en cas de présentation d'un certificat invalide par un serveur doit être personnalisable. A défaut, le proxy TLS devrait interdire toutes connexions utilisant des certificats invalides.

-- Il faut définir les suites cryptographiques utilisables ou non. A l'instar de la version du TLS, une liste d'exception devra pouvoir être définie pour autoriser des suites moins robustes.

-- La mise à jour régulière des suites cryptographiques est également importante pour faire face à l'évolution de la sécurité des sites distants.

-- Si la renégociation des sessions TLS est activée, elle doit être sécurisée⁵ afin d'éviter des attaques MITM

-- La désactivation de la compression permet d'éviter les attaques CRIME et ses variantes.

-- Vérifier lors de l'installation la liste des AC publiques connues par le proxy TLS. Il faut également pouvoir la mettre à jour quotidiennement.

9.1.5 Protection de la vie privée

-- Éviter de procéder au déchiffrement des sites personnels à moins que les conditions de sécurité ne l'exigent. Les sites relatifs à la gestion bancaire, médicale et à l'administration publique sont des sites qui ne devraient pas être interceptés au vu de la sensibilité des informations personnelles. Les messageries et les réseaux sociaux sont des sujets plus délicats. Leurs interceptions peuvent retourner de l'atteinte aux secrets des correspondances, mais ces sites restent les principales sources d'infections (téléchargement de fichier, mails malveillants) et de fuites de données (phishing), donc leurs interceptions peuvent se justifier dans une certaine mesure et dans un encadrement spécifique.

-- Si possible, éviter de déchiffrer les données qui sont explicitement identifiées comme personnelles, sans la présence de l'utilisateur, qui serait une atteinte à la vie privée.

-- La journalisation des flux déchiffrés doit rester cohérente avec la journalisation des flux non chiffrés. Seules les données nécessaires afin de garantir le bon fonctionnement du système et à l'identification des utilisateurs sont permises. La conservation des contenus des messages n'est pas autorisée.

-- Dans le cas d'une utilisation tierce d'analyse de flux (exemple : ICAP) qui recevrait le flux déchiffré, l'interconnexion entre ces deux éléments devra être sécurisée. Soit isolé physiquement en dédiant un lien direct entre le proxy TLS et la solution tierce, soit en prévoyant un chiffrement entre les deux équipements.

9.2 L'interception entrante

9.2.1 Sécurisation entre les clients externes et le reverse proxy TLS

-- Limiter l'utilisation du TLS aux versions 1.2 et 1.1, en proposant un ordre décroissant des versions.

-- Limiter l'utilisation des suites cryptographiques aux plus robustes. Les navigateurs évoluant plus vite, il ne seront pas bloqués par cette limitation cryptographique.

-- Si une renégociation des sessions TLS est nécessaire, le reverse proxy TLS ne doit accepter que celles qui sont sécurisées.

-- La désactivation de la compression permet d'éviter les attaques CRIME et ses variantes.

5. RFC 5746

Edouard Petitjean M2 MIAGE SIID 52

La mise en oeuvre technique - L'interception entrante

9.2.2 Protection des clefs privées

-- Un processus de gestion des certificats est nécessaire. Contrairement à l'interception sortante qui utilise un certificat d'autorité valable plusieurs années, les certificats serveur sont généralement valables un an. De plus, il faudra penser à la synchronisation du renouvellement des certificats sur les serveurs et le reverse proxy TLS.

-- L'utilisation d'un HSM est fortement conseillée pour le stockage des clefs et leur utilisation.

-- Revoir les droits systèmes liés aux fichiers contenant les clefs privées. Seul le service qui utilisera les clefs privées devrait avoir les droits de lecture sur ces clefs. Tous les autres accès provenant d'un autre service devront être prohibés.

Edouard Petitjean M2 MIAGE SIID 53

Chapitre 10

Informations et obligations légales

10.1 Vis à vis des utilisateurs

-- L'employeur a un devoir de transparence et loyauté envers ses salariés. Pour cela, le comité d'entreprise doit être « informé et consulté, préalablement à la décision de mise en oeuvre dans l'entreprise, sur les moyens ou les techniques permettant un contrôle de l'activité des salariés » 1.

-- Le contexte précis (finalités, moyens, populations ciblées, etc...) de l'interception TLS doit être inscrit dans une charte informatique. Celle-ci doit être imposable aux salariés.

-- Il est important que l'interception TLS soit nécessaire et proportionnelle au but recherché comme la sécurité du réseau².

-- Pour les déclarations auprès de la CNIL, l'interception TLS n'est pas une finalité mais un moyen. Par conséquent, il n'y a pas de déclaration spécifique à faire. Néanmoins, toutes les déclarations précédentes où l'interception TLS va agir (journalisation, dispositif de sécurité, etc...) devront être refaites pour être mises à jour.

-- Prévoir la gestion des accès aux outils de chiffrement (qui? comment? quand?) et les contrôles qui en découlent ainsi qu'une journalisation de ces accès et contrôles.

10.2 Rappel sur l'obligation des administrateurs

-- Dans leurs missions, les administrateurs sont susceptibles d'accéder à des informations confidentielles et/ou personnelles. Par conséquent, ils sont soumis à une obligation de confidentialité sur les informations dont ils auraient pu prendre connaissance dans le cadre de leurs fonctions. Il est par conséquent interdit de dévoiler toute information, ni même de les fournir sur demande de la hiérarchie.

-- Néanmoins, l'accès à ces informations est uniquement valable dans les cas suivants:

· Nécessité de maintenir le bon fonctionnement du réseau

· Assurer la sécurité du réseau

· Il n'a pas été possible d'assurer les deux points précédents sans avoir eu recours à un moyen moins intrusif

· Si dans les données portées à la connaissance de l'administrateur, certaines sont explicitement identifiées comme personnelles, alors l'auteur de ces données doit être appelé et présent pendant le traitement de ses données³.

-- Pour les fonctionnaires et agents publics contractuels, si dans le cadre de ses fonctions, un administrateur détecte un comportement délictueux d'un utilisateur, il est dans l'obligation de dénoncer ce comportement 4.

1. Article L2323-32 du Code du travail

2. Article L1121-1 du Code du travail

3. Cass, Soc., 17 juin 2009, n^° pourvoi 08-40274 et Cass, Soc., 17 mai 2005, n^° pourvoi 03-40017

4. Article 40-2 du Code de la procédure pénale

Edouard Petitjean M2 MIAGE SIID 54

Chapitre 11

Conclusion

Pour conclure, l'interception TLS va devenir une pratique de plus en plus courante au fil du temps. Le chiffrement devient une pratique courante pour les sites web, même pour ceux qui ne proposent pas d'informations sensibles. Néanmoins, le chiffrement permet de rendre très complexe le suivi des contenus des échanges des utilisateurs. Pour cela, il est nécessaire pour tous les organismes de procéder au déchiffrement des flux sortants avec leurs connexions Internet. Il est primordial pour eux de pouvoir sécuriser leurs réseaux des diverses attaques, ainsi que de toute utilisation malveillante qui pourrait en être faite.

Pour l'instant, il existe encore une incertitude juridique concernant la mise en place de l'interception TLS car elle n'est pas encadrée par la loi. Même si la technique n'est pas récente, son utilisation l'est. Et le fait qu'il n'existe encore aucune jurisprudence concernant la technique montre qu'elle est très jeune dans le monde juridique. Il est plus que probable qu'à l'avenir, il existera un réel statut concernant le déchiffrement encadré, comme c'est le cas pour le chiffrement. En attendant, il convient de prendre la meilleure décision possible pour sa structure et d'en assumer le risque.

Edouard Petitjean M2 MIAGE SIID 55

Liste des tableaux

5.1 Comparaison traitement des requêtes 33

5.2 Récapitulatif de l'aspect technique 38

6.1 Récapitulatif de la législation française 45

Edouard Petitjean M2 MIAGE SIID 56

Liste des figures

1.1	Evolution d'utilisation des protocoles entre 2014 et 2016	6
2.1	SSL sur le modèle TCP/IP	9
2.2	Structure d'un certificat X.509	13
2.3	Echange avec un serveur utilisant un certificat non signé	14
2.4	Echange avec un serveur utilisant un certificat signé	16
2.5	Définition de SecurityParameters dans la RFC5246	18
2.6	Définition de TLSPlaintext dans la RFC5246	18
2.7	Echange TLS Handshake Protocol	20
3.1	Man In The Middle	23
3.2	Différence entre connexion entrante et sortante	24
3.3	Interception TLS sortante	25
3.4	Interception TLS Entrante	26
5.1	Comparaison traitement des requêtes	34

Références

Présentation du TLS

https://fr.wikipedia.org/wiki/Transport\_Layer\_Security https://fr.wikipedia.org/wiki/Pretty_Good_Privacy https://tools.ietf.org/html/rfc5246

http://www.authsecu.com/ssl-tls/ssl-tls.php https://www.trustworthyinternet.org/ssl-pulse/ https://www.w3counter.com/globalstats.php?year=2015&month=3 http://gs.statcounter.com/browser-market-share/all/worldwide/2015 http://www.cert.ssi.gouv.fr/site/CERTA-2005-REC-001/

https://developer.mozilla.org/fr/docs/Introduction\_\%C3\%A0\_la\_cryptographie\ _\%C3\%A0\_clef\_publique/Certificats\_et\_authentification

https://fr.wikipedia.org/wiki/X.509

https://tools.ietf.org/html/rfc5280

http://cryptosec.lautre.net/?Certificats-X509-v3

https://www.certeurope.fr/les-dossiers-certeurope/autorite-de-certification http://nicolasbroisin.fr/blog/etude-infrastructure-pki/

Interception TLS

http://www.silicon.fr/5-questions-comprendre-dechiffrement-ssl-100250.html https://www.ssi.gouv.fr/uploads/IMG/pdf/NP\_TLS\_NoteTech.pdf

Législation

https://www.legifrance.gouv.fr/

https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions

https://www.cnil.fr/sites/default/files/typo/document/Guide\_employeurs\_salaries. pdf.pdf

https://www.ssi.gouv.fr/uploads/IMG/pdf/NP\_TLS\_NoteTech.pdf http://www.lexagone.fr/Jurisprudence-CNIL

https://www.legalis.net/

https://www.jurisexpert.net/quelle\_responsabilit\_en\_mati\_re\_de\_s\_cur/

https://www.olfeo.com/proteger-votre-entreprise/maitriser-les-enjeux/maitriser-les-enjeux-juridiques

Enjeux

https://www.cnil.fr/fr/analyse-de-flux-https-bonnes-pratiques-et-questions https://www.ssi.gouv.fr/uploads/IMG/pdf/NP\_TLS\_NoteTech.pdf Histoire du chiffrement

https://fr.wikipedia.org/wiki/Histoire\_de\_la\_cryptologie

https://www.ssi.gouv.fr/administration/reglementation/controle-reglementaire-sur-la-cryptographie/

Edouard Petitjean M2 MIAGE SIID 57

Edouard Petitjean M2 MIAGE SIID 58

LISTE DES FIGURES - LISTE DES FIGURES

http://www2.droit.parisdescartes.fr/warusfel/articles/reglcrypto\_warusfel.pdf http://strategique.free.fr/analyses/cryptographie.pdf Protection des clients contre l'interception TLS

https://www.certificate-transparency.org

https://jhalderm.com/pub/papers/interception-ndss17.pdf https://tools.ietf.org/html/rfc7469

https://checkmyhttps.net/info.php

https://jlospinoso.github.io/node/javascript/security/cryptography/privacy/2017/ 02/20/snuckme-cert-query.html

Autres

https://www.theguardian.com/us-news/prism https://cnnumerique.fr/cp-chiffrement/

https://fr.scribd.com/document/319975624/Note-de-l-Anssi-sur-le-chiffrement\#download\ &from\_embed

http://internetactu.blog.lemonde.fr/2014/06/07/la-surveillance-nameliore-pas-la-productivite/

https://www.ssi.gouv.fr/entreprise/qualifications/ https://www.ssi.gouv.fr/uploads/2015/09/RGS\_B\_1.pdf

Edouard Petitjean M2 MIAGE SIID 59

Lexique

A

AC : Autorité de Certification, une entité de la PKI ayant pour rôle la gestion (création, signature, publication, révocation) des certificats.

AE : Autorité d'Enregistrement, une entité de la PKI ayant pour rôle la vérification des identités des entités finales utilisant les certificats.

AES : Advanced Encryption Standard, protocole de chiffrement symétrique créé en 1999.

ALPN : Application Layer Protocol Negotiation, extension TLS permettant d'annoncer le protocole transporté par TLS.

Analyse basée sur la signature : se repose sur une base locale, mise à jour régulièrement, contenant des signatures de malwares.

Analyse heuristique : 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.

ANSSI : Agence Nationale de la Sécurité des Systèmes d'Information : assure la mission d'autorité nationale en matière de sécurité des systèmes d'information.

Autorité de dépôt : une entité de la PKI ayant pour rôle le stockage des certificats ainsi que des listes de révocations.

Autorité de séquestre : une entité de la PKI ayant le stockage sécurisé des clefs privées liées aux certificats. Cette entité est surtout utilisée en entreprise pour garder une copie des clefs de chiffrement en cas de perte par un utilisateur et pouvoir déchiffrer les données de l'utilisateur. Cette entité n'est pas définie par l'IETF mais son utilisation ou non n'impacte pas le fonctionnement de la PKI.

B

BEAST : Browser Exploit Against SSL/TLS, attaque via injection de cookie pour détourner une session SSL/TLS.

C

Certificat X.509 : certificat qui base sa validité sur une autorité centralisée hiérarchisée. Cela permet aux clients de vérifier rapidement la validité des certificats en se basant sur des acteurs de confiance reconnus. De plus, cette centralisation permet aux autorités de publier les révocations de certificats expirés et/ou douteux rapidement.

Client-Serveur : modèle basé sur un tiers mettant à disposition des ressources, et une multitude de tiers venant accéder ces ressources.

CN : 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.

CNNum : Conseil National du Numérique: organisme consultatif ayant pour mission de formuler de manière indépendante et de rendre publics des avis et des recommandations sur toute question relative à l'impact du numérique sur la société et l'économie.

CRIME : Compression Ratio Info-leak Made Easy: est une attaque se basant sur une vulnérabilité qui apparaît pendant l'utilisation de l'algorithme de compression DEFLATE.

cryptanalyse : science de déchiffrer un message sans en posséder la clef.

Edouard Petitjean M2 MIAGE SIID 60

Lexique - Lexique

Cryptographie : Pratique ayant pour but de rendre un message incompréhensible à toutes personnes ne possédant les connaissances suffisantes à sa lecture.

CSR : Certificate Signing Request, requête envoyée à une AC pour signer un certificat. L'AC renvoie un nouveau certificat avec sa signature.

D

Diffie-Hellman : méthode permettant à deux tiers de générer une paire de clefs asymétriques sans avoir à les échanger.

DN : 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.

E

EE : End Entity, une entité de la PKI qui représente l'entité utilisatrice d'un certificat qui lui est lié. G

GPO : Group Policy Object : est un ensemble de paramétrages de postes Windows, récupéré depuis un serveur, qui sont appliqués à divers moments selon des critères précis.

H

Hash : Algorithme de chiffrement irréversible permettant de définir une empreinte numérique à une donnée.

HSM : est un composant matériel permettant la génération, stockage et protection des clefs cryptographique. Il permet également une protection lors de calcul cryptographique.

HSTS : 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.

I

IDS/IPS : Intrusion Detection/Prevention System : Système d'analyse de données permettant de détecter ou prévenir des attaques connues.

IETF : Internet Engineering Task Force, regroupement informel de personnes travaillant à l'élabora-tion des standards Internet.

K

Kerberos : Protocole permettant l'authentification et la gestion des autorisations des utilisateurs. Sa particularité est de se baser sur des clefs symétriques et des jetons, permettant d'éviter l'envoi de mot de passe sur le réseau.

M

Malware : terme généraliste pour désigner les divers programmes nuisibles (virus, spywares, chevaux de Troie, vers, backdoors, rootkits, keyloggers, publiciels, etc...

P

Peer-to-peer : est un modèle de réseaux informatiques basé sur le client-serveur mais dans lequel tous les clients sont serveurs et inversement.

Phishing : 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...

PKI : Public Key Infrastructure, système composé de plusieurs éléments qui a pour but de gérer le cycle de vie des certificats et la relation de confiance entre les clients et les certificats.

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

Proxy : est un équipement mandataire permettant de faire le lien entre deux réseaux pour des protocoles spécifiques pour des raisons de performance et/ou sécurité. 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 61

Lexique - Lexique

PSF : Perfect Forward Secrecy : est une propriété en cryptographie qui garantit que la découverte par un adversaire de la clé privée d'un correspondant (secret à long terme) ne compromet pas la confidentialité des communications passées.

R

RFC : Request for comments, document officiel décrivant des aspects techniques. Une RFC n'est pas forcément un standard.

S

Sandbox : est un environnement d'exécution de programme isolé pour inspecter leur comportement.

SNI : Server Name Indication, extension TLS permettant d'annoncer le CommonName du certificat à demander. Utile lorsqu'un même serveur Web héberge plusieurs sites utilisant des certificats différents.

SSL : Secure Socket Layer, protocole permettant de créer un canal d'échange sécurisé entre un client et un serveur.

STAD : 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é.

T

TLS : Transport Layer Security, protocole permettant de créer un canal d'échange sécurisé entre un client et un serveur. Successeur du SSL.