2014_analyse_flux_https.pdf

(1672 KB) Pobierz
DAT-NT-19/ANSSI/SDE
PREMIER MINISTRE
Secrétariat général
de la défense
et de la sécurité nationale
Agence nationale de la sécurité
des systèmes d’information
Paris, le 1
er
octobre 2014
N
o
DAT-NT-19/ANSSI/SDE/NP
Nombre de pages du document
(y compris cette page) : 32
Note technique
Recommandations de sécurité concernant l’analyse
des flux HTTPS
Public visé:
Développeur
Administrateur
RSSI
DSI
Utilisateur
Informations
Avertissement
Ce document rédigé par l’ANSSI présente les
« Recommandations de sécurité con-
cernant l’analyse des flux HTTPS ».
Il est téléchargeable sur le site
www.ssi.gouv.fr.
Il
constitue une production originale de l’ANSSI. Il est à ce titre placé sous le régime de la « Li-
cence ouverte » publiée par la mission Etalab (www.etalab.gouv.fr). Il est par conséquent
diffusable sans restriction.
Ces recommandations sont livrées en l’état et adaptées aux menaces au jour de leur pub-
lication. Au regard de la diversité des systèmes d’information, l’ANSSI ne peut garantir que
ces informations puissent être reprises sans adaptation sur les systèmes d’information cibles.
Dans tous les cas, la pertinence de l’implémentation des éléments proposés par l’ANSSI doit
être soumise, au préalable, à la validation de l’administrateur du système et/ou des personnes
en charge de la sécurité des systèmes d’information.
Personnes ayant contribué à la rédaction de ce document:
Contributeurs
LRP, LAM, BAI,
MRR
Rédigé par
BSS
Approuvé par
SDE
Date
1
er
octobre 2014
Évolutions du document :
Version
1.0
Date
1
er
octobre 2014
Nature des modifications
Version initiale
Pour toute remarque:
Contact
Bureau Communication
de l’ANSSI
Adresse
51 bd de La
Tour-Maubourg
75700 Paris Cedex
07 SP
@mél
communication@ssi.gouv.fr
Téléphone
01 71 75 84 04
N
o
DAT-NT-19/ANSSI/SDE/NP du 1
er
octobre 2014
Page 1 sur
31
Table des matières
1
2
Préambule
Généralités
2.1
2.2
2.3
2.4
2.5
3
Rappels sur TLS
. . . . . . . .
Implémentation de TLS
. . . .
Référentiel Général de Sécurité
Protection des clés privées
. . .
Validité des certificats
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
4
6
6
6
7
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
9
10
12
12
12
13
15
16
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
19
20
20
21
22
22
23
23
25
26
26
31
Traitement des flux HTTPS sortants
3.1
3.2
Architecture
. . . . . . . . . . . . . . . . . . . . . . .
Traitement des flux HTTPS par déchiffrement
. . . .
3.2.1 Les enjeux du déchiffrement
. . . . . . . . . .
3.2.1.1 Génération des certificats
. . . . . .
3.2.1.2 Impact sur les performances
. . . . .
3.2.2 Bonnes pratiques
. . . . . . . . . . . . . . . .
3.2.2.1 Génération des certificats
. . . . . .
3.2.2.2 Renforcement de la sécurité de TLS
3.2.2.3 Protection de la vie privée
. . . . .
Traitement des flux HTTPS sans déchiffrement
. . .
3.3
4
Traitement des flux HTTPS entrants
4.1
4.2
Architecture
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traitement des flux HTTPS par déchiffrement
. . . . . . . . . . . . . . . . . . . . .
4.2.1 Les enjeux du déchiffrement
. . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Bonnes pratiques
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2.1 Génération des certificats
. . . . . . . . . . . . . . . . . . . . . . .
4.2.2.2 Sécurité TLS entre le reverse proxy et Internet (les clients)
. . . .
4.2.2.3 Sécurité du trafic interne (entre le reverse proxy et le serveur web)
4.2.2.4 Propagation de l’identité des clients
. . . . . . . . . . . . . . . . .
Traitement des flux HTTPS sans déchiffrement
. . . . . . . . . . . . . . . . . . . .
Sécurité web complémentaire
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
4.4
5
Validation des configurations
Annexes
A
B
Aspects juridiques
Suites cryptographiques acceptables
N
o
DAT-NT-19/ANSSI/SDE/NP du 1
er
octobre 2014
Page 2 sur
31
1 Préambule
Le protocole HTTPS correspond à la déclinaison sécurisée de HTTP encapsulé à l’aide d’un pro-
tocole de niveau inférieur nommé TLS
1
(anciennement SSL
2
). Ce protocole est conçu pour protéger
en confidentialité et en intégrité des communications de
bout en bout
(entre un client et un serveur). Il
apporte également des fonctions d’authentification du serveur, mais aussi optionnellement du client.
La protection de
bout en bout
qu’apporte TLS est a priori incompatible avec d’autres exigences
de sécurité complémentaires visant à inspecter le contenu des échanges. L’analyse d’un contenu (web
par exemple) sécurisé à l’aide de TLS, peut toutefois se justifier afin de s’assurer que les données
provenant d’un réseau non maîtrisé (Internet par exemple) ne représentent pas une menace pour le
système d’information interne. Les architectures visant à déchiffrer les flux TLS, pour permettre leur
analyse, « tordent » donc le modèle pour lequel ce protocole est conçu.
Pour pouvoir mettre en œuvre le déchiffrement de flux TLS de façon maîtrisée, il est nécessaire
de disposer, entre autres, d’un niveau de connaissance suffisant dans les deux domaines spécifiques et
évolutifs que sont les IGC
3
et la cryptographie.
Quel que soit le contexte, la mise en place de
mécanismes de déchiffrement HTTPS présente des risques dans la mesure où cette opéra-
tion entraîne la rupture d’un canal sécurisé et expose des données en clair au niveau
de l’équipement en charge de l’opération. Lorsqu’un tel déchiffrement est nécessaire, sa
mise en œuvre doit s’accompagner de beaucoup de précautions et se faire uniquement
après validation de la direction des systèmes d’information voire d’une autorité de niveau
supérieur.
Cette note présente donc les recommandations d’ordre technique à suivre lorsque l’analyse des flux
HTTPS échangés entre un système d’information maîtrisé et des réseaux externes est indispensable.
Deux scénarios sont présentés. Le premier, en théorie plus rare, détaille le cas où les flux HTTPS
sont déchiffrés après avoir été initiés par des clients présents sur le système d’information en direction
des sites web externes. Le second, plus fréquent, présente le cas où des clients externes souhaitent se
connecter à l’aide du protocole HTTPS à des sites web hébergés au sein d’un système d’information
maîtrisé. Ce document n’a pas pour objectif de décrire à nouveau en détail le fonctionnement du
protocole TLS ; la publication intitulée «
SSL/TLS : état des lieux et recommandations
4
» disponible
sur le site de l’ANSSI présente ce protocole et les problématiques associées. Par contre, certains aspects
juridiques relatifs au déchiffrement de flux HTTPS sont abordés à la fin de ce document.
1.
2.
3.
4.
Transport Layer Security.
Secure Socket Layer.
Infrastructure de Gestion de Clés.
http://www.ssi.gouv.fr/IMG/pdf/SSL_TLS_etat_des_lieux_et_recommandations.pdf.
N
o
DAT-NT-19/ANSSI/SDE/NP du 1
er
octobre 2014
Page 3 sur
31
2 Généralités
2.1 Rappels sur TLS
Voici un résumé de la séquence permettant l’établissement d’un tunnel TLS. Ce schéma illustre un
cas classique
5
; il a pour principal objectif de faire apparaître les éléments nécessaires à la compréhension
de ce document.
Figure
1 – Établissement d’une session TLS
Détail des échanges :
1. le client initie une requête en direction du serveur en envoyant un message de type
Client Hello.
Ce message contient en particulier les éléments suivants :
– les suites cryptographiques (ciphersuite) supportées par le client ;
– la version la plus élevée de SSL/TLS qu’il supporte ;
– les algorithmes de compression qu’il supporte ;
– optionnellement, les informations relatives aux extensions qu’il utilise
6
.
2. le serveur répond par un message de type
Server Hello.
Ce message contient en particulier les éléments suivants :
5. C’est-à-dire sans authentification du client, et en utilisant un mécanisme d’échange de clés par chiffrement
RSA.
6. Par exemple
SNI
(Server
Name Indication).
N
o
DAT-NT-19/ANSSI/SDE/NP du 1
er
octobre 2014
Page 4 sur
31

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin