DAT-NT-19/ANSSI/SDE

PREMIER MINISTRE

Secrtariat gnral Paris, le 1er octobre 2014

de la dfense
et de la scurit nationale No DAT-NT-19/ANSSI/SDE/NP

Agence nationale de la scurit Nombre de pages du document

des systmes dinformation (y compris cette page) : 32

Note technique

Recommandations de scurit concernant lanalyse

des flux HTTPS

Public vis:
Dveloppeur X
Administrateur X
RSSI X
DSI X
Utilisateur
 Informations

Avertissement

Ce document rdig par lANSSI prsente les Recommandations de scurit con-

cernant lanalyse des flux HTTPS . Il est tlchargeable sur le site www.ssi.gouv.fr. Il
constitue une production originale de lANSSI. Il est ce titre plac sous le rgime de la Li-
cence ouverte publie par la mission Etalab (www.etalab.gouv.fr). Il est par consquent
diffusable sans restriction.

Ces recommandations sont livres en ltat et adaptes aux menaces au jour de leur pub-
lication. Au regard de la diversit des systmes dinformation, lANSSI ne peut garantir que
ces informations puissent tre reprises sans adaptation sur les systmes dinformation cibles.
Dans tous les cas, la pertinence de limplmentation des lments proposs par lANSSI doit
tre soumise, au pralable, la validation de ladministrateur du systme et/ou des personnes
en charge de la scurit des systmes dinformation.

Personnes ayant contribu la rdaction de ce document:

Contributeurs Rdig par Approuv par Date

LRP, LAM, BAI,
BSS SDE 1er octobre 2014
MRR

volutions du document :

Version Date Nature des modifications

1.0 1 octobre 2014
er Version initiale

Pour toute remarque:

Contact Adresse @ml Tlphone

51 bd de La
Bureau Communication Tour-Maubourg
communication@ssi.gouv.fr 01 71 75 84 04
de lANSSI 75700 Paris Cedex
07 SP

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 1 sur 31

 Table des matires
1 Prambule 3

2 Gnralits 4
2.1 Rappels sur TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Implmentation de TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Rfrentiel Gnral de Scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Protection des cls prives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Validit des certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Traitement des flux HTTPS sortants 8

3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Traitement des flux HTTPS par dchiffrement . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Les enjeux du dchiffrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1.1 Gnration des certificats . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1.2 Impact sur les performances . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2.1 Gnration des certificats . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2.2 Renforcement de la scurit de TLS . . . . . . . . . . . . . . . . . . . 13
3.2.2.3 Protection de la vie prive . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Traitement des flux HTTPS sans dchiffrement . . . . . . . . . . . . . . . . . . . . . . 16

4 Traitement des flux HTTPS entrants 18

4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Traitement des flux HTTPS par dchiffrement . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1 Les enjeux du dchiffrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2 Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2.1 Gnration des certificats . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2.2 Scurit TLS entre le reverse proxy et Internet (les clients) . . . . . . 21
4.2.2.3 Scurit du trafic interne (entre le reverse proxy et le serveur web) . . 22
4.2.2.4 Propagation de lidentit des clients . . . . . . . . . . . . . . . . . . . 22
4.3 Traitement des flux HTTPS sans dchiffrement . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Scurit web complmentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Validation des configurations 25

Annexes 26

A Aspects juridiques 26

B Suites cryptographiques acceptables 31

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 2 sur 31

1 Prambule
Le protocole HTTPS correspond la dclinaison scurise de HTTP encapsul laide dun pro-
tocole de niveau infrieur nomm TLS 1 (anciennement SSL 2 ). Ce protocole est conu pour protger
en confidentialit et en intgrit des communications de bout en bout (entre un client et un serveur). Il
apporte galement des fonctions dauthentification du serveur, mais aussi optionnellement du client.

La protection de bout en bout quapporte TLS est a priori incompatible avec dautres exigences
de scurit complmentaires visant inspecter le contenu des changes. Lanalyse dun contenu (web
par exemple) scuris laide de TLS, peut toutefois se justifier afin de sassurer que les donnes
provenant dun rseau non matris (Internet par exemple) ne reprsentent pas une menace pour le
systme dinformation interne. Les architectures visant dchiffrer les flux TLS, pour permettre leur
analyse, tordent donc le modle pour lequel ce protocole est conu.

Pour pouvoir mettre en uvre le dchiffrement de flux TLS de faon matrise, il est ncessaire
de disposer, entre autres, dun niveau de connaissance suffisant dans les deux domaines spcifiques et
volutifs que sont les IGC 3 et la cryptographie. Quel que soit le contexte, la mise en place de
mcanismes de dchiffrement HTTPS prsente des risques dans la mesure o cette opra-
tion entrane la rupture dun canal scuris et expose des donnes en clair au niveau
de lquipement en charge de lopration. Lorsquun tel dchiffrement est ncessaire, sa
mise en uvre doit saccompagner de beaucoup de prcautions et se faire uniquement
aprs validation de la direction des systmes dinformation voire dune autorit de niveau
suprieur.

Cette note prsente donc les recommandations dordre technique suivre lorsque lanalyse des flux
HTTPS changs entre un systme dinformation matris et des rseaux externes est indispensable.
Deux scnarios sont prsents. Le premier, en thorie plus rare, dtaille le cas o les flux HTTPS
sont dchiffrs aprs avoir t initis par des clients prsents sur le systme dinformation en direction
des sites web externes. Le second, plus frquent, prsente le cas o des clients externes souhaitent se
connecter laide du protocole HTTPS des sites web hbergs au sein dun systme dinformation
matris. Ce document na pas pour objectif de dcrire nouveau en dtail le fonctionnement du
protocole TLS ; la publication intitule SSL/TLS : tat des lieux et recommandations 4 disponible
sur le site de lANSSI prsente ce protocole et les problmatiques associes. Par contre, certains aspects
juridiques relatifs au dchiffrement de flux HTTPS sont abords la fin de ce document.

1. Transport Layer Security.

2. Secure Socket Layer.
3. Infrastructure de Gestion de Cls.
4. http://www.ssi.gouv.fr/IMG/pdf/SSL_TLS_etat_des_lieux_et_recommandations.pdf.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 3 sur 31

2 Gnralits
2.1 Rappels sur TLS
Voici un rsum de la squence permettant ltablissement dun tunnel TLS. Ce schma illustre un
cas classique 5 ; il a pour principal objectif de faire apparatre les lments ncessaires la comprhension
de ce document.

Figure 1 tablissement dune session TLS

Dtail des changes :

1. le client initie une requte en direction du serveur en envoyant un message de type Client Hello.
Ce message contient en particulier les lments suivants :
les suites cryptographiques (ciphersuite) supportes par le client ;
la version la plus leve de SSL/TLS quil supporte ;
les algorithmes de compression quil supporte ;
optionnellement, les informations relatives aux extensions quil utilise 6 .
2. le serveur rpond par un message de type Server Hello.
Ce message contient en particulier les lments suivants :
5. Cest--dire sans authentification du client, et en utilisant un mcanisme dchange de cls par chiffrement RSA.
6. Par exemple SNI (Server Name Indication).

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 4 sur 31

 la suite cryptographique slectionne par le serveur parmi celles quil supporte et celles pro-
poses par le client ;
lalgorithme de compression slectionn par le serveur parmi ceux quil supporte et ceux pro-
poss par le client ;
les informations relatives aux extensions utilises par le client (acceptation ou non de ces
extensions).
3. le serveur envoie ensuite un message de type Server Certificate au client en lui fournissant son
certificat au format X.509 (contenant sa cl publique) pour que celui-ci puisse lauthentifier ;
4. le serveur envoie un message de type Server Hello Done pour signifier au client quil a termin
cette premire squence et quil est en attente dune rponse de sa part ;
5. aprs avoir valid le certificat du serveur, le client rpond par un message de type Client Key
Exchange ; celui-ci contient le Pre-master Secret chiffr laide de la cl publique du serveur. Ce
secret sera utilis par les deux parties pour gnrer le Master Secret qui permet dobtenir par
drivation les cls de session utilises pour scuriser les donnes changes aprs ltablissement
du tunnel TLS ;
6. le client poursuit par lenvoi dun message de type Change Cipher Spec chiffr laide de lal-
gorithme de chiffrement symtrique ngoci prcdemment. Ce message indique que les donnes
que le client transmettra par la suite au serveur seront galement chiffres ;
7. le client termine par un message de type Finished ;
8. le serveur rpond par lenvoi dun message de type Change Cipher Spec chiffr laide de lal-
gorithme de chiffrement symtrique ngoci prcdemment. Ce message indique que les donnes
que le serveur transmettra par la suite au client seront galement chiffres ;
9. le serveur termine par un message de type Finished.
la suite de cette squence, le trafic chang entre le client et le serveur sera protg laide du
protocole TLS configur en fonction des paramtres dfinis au cours de la squence de ngociation.

Attention : La squence dtablissement prsente pose problme car la confidentialit des cls de
session utilises pour protger les communications TLS dpend de la cl prive du serveur TLS. En
effet, si cette dernire est compromise par un attaquant, qui aurait galement captur le trafic TLS, il
sera en mesure dobtenir le Pre-master Secret, le Master Secret ainsi que lensemble des cls de session.
Pour viter ce problme, le mcanisme dchange de cls utilis lors de ltablissement de la session
TLS doit permettre la PFS (Perfect Forward Secrecy). Cette proprit permet de gnrer des cls de
session sans que la confidentialit de celles-ci ne dpende de la cl prive du serveur, cette dernire nest
alors utilise que pour authentifier le serveur vis--vis des clients. Dans cette configuration, la compro-
mission de la cl prive du serveur ne permet donc pas le dchiffrement de sessions TLS enregistres au
pralable, mais la cl peut nanmoins tre utilise pour usurper lidentit du serveur (attaque active
dite de lhomme du milieu ) dans le but de dchiffrer le trafic futur. Les suites cryptographiques qui
permettent la PFS reposent sur un change de cls de type Diffie-Hellman phmre (DHE ou ECDHE
figure dans le nom de la suite au format IANA 7 ) et utilisent un autre algorithme de signature (RSA
par exemple) pour raliser lauthentification des parties.

7. Internet Assigned Numbers Authority.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 5 sur 31

2.2 Implmentation de TLS
Les applicatifs TLS (clients et serveurs) sont gnralement dvelopps partir de bibliothques
TLS existantes. Certaines implmentations comme OpenSSL et NSS sont libres alors que dautres sont
propritaires. La bibliothque Schannel, par exemple, est dveloppe par Microsoft. Lorsquune vul-
nrabilit est dtecte dans une bibliothque, celle-ci affecte lensemble des applications bases sur une
des versions vulnrables du composant. La prsence dune vulnrabilit au sein dune bibliothque TLS
peut ainsi avoir des consquences extrmement importantes en termes de scurit. Cela peut conduire
laffaiblissement du niveau de protection quapporte TLS (divulgation dinformations, perte dintgrit,
usurpation didentit).

R1
Il est impratif dappliquer rapidement les correctifs de scurit associs une bi-
bliothque ou un applicatif TLS ds lors quils corrigent des vulnrabilits juges
importantes.

2.3 Rfrentiel Gnral de Scurit

Le Rfrentiel Gnral de Scurit (RGS), disponible sur le site de lANSSI 8 dfinit les rgles
respecter concernant la scurisation des changes lectroniques entre les usagers et les autorits
administratives et entre autorits administratives. Au-del de son primtre dapplicabilit strict, le
RGS fournit des recommandations et des mtriques qui font rfrence et qui sont utilisables dans un
contexte plus large. Deux annexes composant le RGS sont particulirement pertinentes lorsquil sagit
de mettre en uvre TLS :
lannexe B1 9 prcise les rgles et les recommandations respecter lorsque des mcanismes cry-
ptographiques sont employs ;
lannexe A4 10 rassemble les rgles relatives aux formats de certificats.

2.4 Protection des cls prives

Une mise en uvre scurise de TLS requiert lemploi dau moins un bi-cl ct serveur ; celui-ci est
compose dun couple certificat/cl prive. Le niveau de scurit dun canal TLS dpend donc en partie
des mesures de protection qui sont appliques la cl prive par lquipement qui lhberge. Si cette
cl tait compromise par une personne mal intentionne, celle-ci pourrait tre en mesure de dchiffrer
des changes enregistrs avant le vol de la cl (si la PFS nest pas active) ou dusurper lidentit du
serveur lgitime aprs le vol. Il est donc primordial de mettre en place des mcanismes de protection
logiciels ou matriels au niveau des quipements qui hbergent les bi-cls.

R2
Les cls prives associes aux certificats doivent tre correctement protges.

La solution la plus scurise consiste stocker les donnes cryptographiques dans un composant
matriel de type HSM 11 pouvant dialoguer de faon scurise ( laide de lAPI PKCS#11 par exemple)
avec lquipement qui termine les tunnels TLS.

8. http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/.
9. http://www.ssi.gouv.fr/IMG/pdf/RGS_v-2-0_B1.pdf.
10. http://www.ssi.gouv.fr/IMG/pdf/RGS_v-2-0_A4.pdf.
11. Hardware Security Module. La liste des HSM certifis par lANSSI est disponible ladresse :
http://www.ssi.gouv.fr/fr/produits-et-prestataires/.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 6 sur 31

2.5 Validit des certificats
Lacceptation de certificats invalides (date de validit chue, certificat rvoqu, etc.) est un prob-
lme de scurit ouvrant la voie des attaques pouvant compromettre la scurit des communications.

R3
Quel que soit le contexte de mise en uvre de TLS, des mcanismes de vrification
automatiques doivent tre mis en place afin de sassurer que les certificats employs
sont bien valides.

Voici un aperu des deux principaux mcanismes de vrification automatiques de rvocation :

CRL 12 : une CRL est un fichier contenant la liste des certificats rvoqus par une autorit de
certification (ou AC). Le maintien en ligne dune CRL jour fait partie des fonctions que doit
assurer une IGC. Lemplacement de la CRL associe une AC doit tre renseign dans le champ
CRLDP 13 de chaque certificat mis par cette AC ;
OCSP 14 : le protocole OCSP fonctionne en mode client-serveur. Il permet un client de vrifier
en ligne la validit dun certificat en interrogeant des serveurs OCSP (appels rpondeurs ).
Si une IGC met disposition un service OCSP, lemplacement des rpondeurs associs doit tre
renseign dans le champ AIA 15 de chaque certificat mis par lAC.

Dautres solutions plus rcentes existent, elles visent essentiellement amliorer lefficacit de ces
deux mcanismes, cest le cas notamment de OCSP Stapling 16 ou de CRLSets (initiative de Google).

12. Certificate Revocation List ou liste de rvocation de certificats .

13. CRL Distribution Point ou point de distribution de la CRL .
14. Online Certificate Status Protocol ou protocole de vrification en ligne de certificat .
15. Authority Information Access ou accs aux informations de lautorit .
16. Littralement agrafage OCSP .

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 7 sur 31

3 Traitement des flux HTTPS sortants
Cette section a pour objectif de prsenter les possibilits de traitement des flux HTTPS dont les
requtes sont inities partir de clients se trouvant sur un systme dinformation matris et qui sont
destines tablir un canal scuris avec des serveurs web externes (situs sur Internet par exemple).

3.1 Architecture
Lusage de serveurs mandataires (ou proxy) HTTP est une bonne pratique darchitecture permet-
tant de sassurer que lensemble des clients dun systme dinformation passent par un point de contrle
unique pour pouvoir accder des sites web hbergs sur dautres rseaux. Cest gnralement au niveau
de ce type dquipement que sont analyss les flux HTTPS sortants, si la solution de proxy employe
dispose des fonctionnalits permettant lanalyse de ce type de flux. Un proxy web peut tre positionn
de plusieurs faons vis--vis de ses clients ; la description des architectures les plus rpandues dpasse
le cadre de ce document.

Figure 2 Schma gnral dun proxy HTTP

3.2 Traitement des flux HTTPS par dchiffrement

Ce paragaphe dtaille le cas o le proxy est en mesure de disposer du trafic en clair chang entre le
client et le serveur web cible. Cela est possible lorsque le proxy peut duper le client en interceptant
la connexion TLS quil initie en direction du serveur web cible. Le proxy doit pour cela intgrer un
serveur TLS pour pouvoir tre le point de terminaison des sessions HTTPS. Le proxy joue ensuite le
rle de client vis--vis du serveur cible avec lequel il tablit un autre tunnel TLS pour scuriser les
changes qui transitent sur Internet. Ce double rle permet ainsi au proxy de disposer du trafic HTTP
non chiffr entre les deux tunnels TLS tablis.

Figure 3 Traitement des flux HTTPS sortants par dchiffrement

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 8 sur 31

 Le proxy jouant le rle de serveur TLS pour les clients, il doit sauthentifier auprs de ces derniers
en leur prsentant un certificat valide lorsquils initient une connexion HTTPS. Le serveur web cible
devra de la mme faon sauthentifier auprs du proxy en lui prsentant son propre certificat. Une fois
les deux tunnels TLS tablis, le proxy relaie au serveur cible les demandes quil reoit de ses clients.
Le dchiffrement HTTPS dporte ainsi au niveau du client TLS intgr au proxy les vrifications des
lments transmis par le serveur externe (certificat, paramtres TLS, etc.) ncessaires ltablissement
du tunnel TLS.

3.2.1 Les enjeux du dchiffrement

Avant de mettre en place des mcanismes de dchiffrement au niveau dun proxy web, il est nces-
saire de bien comprendre les avantages, les inconvnients et les problmatiques que cela induit.

La possibilit de disposer du trafic HTTP en clair au niveau dun proxy web procure plusieurs avan-
tages :
il est possible danalyser le trafic HTTP afin de protger le client de menaces manant du serveur
web cible : contenus inappropris, fichiers malveillants, etc. ;
il est possible de contrler le contenu des donnes changes entre le client et le serveur afin de
sassurer que les flux HTTPS ne sont pas utiliss pour faire sortir du systme dinformation des
donnes confidentielles. Lanalyse doit tre ralise en limitant autant que possible lexposition
des donnes caractre personnel des clients (se reporter au 3.2.2.3) ;
il est possible dappliquer la mme politique de journalisation que celle mise en uvre pour les
flux HTTP non scuriss. La journalisation doit tre ralise en accord avec le respect de la vie
prive des clients (se reporter au 3.2.2.3) ;
le proxy a la possibilit de mettre en cache du contenu quil peut resservir plusieurs clients qui
souhaitent accder au mme serveur cible.

Cependant, le dchiffrement prsente plusieurs inconvnients :

des donnes normalement chiffres sont prsentes en clair au niveau du proxy. Si ce dernier est
compromis, des informations sensibles peuvent tre exposes ;
lauthentification du client laide dun certificat nest plus possible auprs dun site web qui re-
querrait ce mode dauthentification. En effet, le proxy tant plac en coupure, le client ne dialogue
pas directement en TLS avec le site web ; il ne reoit donc pas les demandes dauthentification
par certificat formules par ce dernier. Les sites qui requirent une authentification par certificat
doivent donc tre placs dans une liste blanche pour laquelle le dchiffrement nest pas effectu ;
le niveau de scurit du tunnel TLS tabli sur Internet avec le serveur cible ne dpend plus du
navigateur web du client. Celui-ci nest donc pas en mesure de connatre les risques quil prend
(validit du certificat serveur, suite cryptographique employe, version de TLS, utilisation de la
PFS, etc.). La scurisation des tunnels TLS tablis avec le monde extrieur repose uniquement
sur les possibilits offertes par le proxy en tant que client, celui-ci tant potentiellement plus
laxiste au niveau TLS que les navigateurs web les plus rcents ;
une AC interne doit tre employe pour gnrer les certificats que le proxy prsente ses clients
(se reporter au 3.2.1.1).

En rsum, si le dchiffrement des flux HTTPS permet un meilleur contrle des donnes changes
entre un systme dinformation et le monde extrieur, ce processus complexifie larchitecture daccs
Internet et dporte la scurisation du canal de communication avec lextrieur sur le proxy. Ce type
dquipement devient ainsi trs critique. Sa mise en uvre doit donc tre ralise en respectant les
recommandations mentionnes dans la suite de ce document.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 9 sur 31

3.2.1.1 Gnration des certificats
Les certificats prsents par le proxy pour sauthentifier auprs de ses clients sont particuliers. En
effet, ils sont gnrs spcifiquement pour les besoins de dchiffrement et doivent tre valides vis--vis
des clients pour que lopration soit transparente. Mme si ces certificats respectent les rgles prsentes
ci-dessous ainsi que les recommandations dictes par le RGS, leur existence mme est incompatible
avec ce rfrentiel dans la mesure o ils sont gnrs pour usurper lidentit de sites web appartenant
des tiers.

Plusieurs contraintes doivent tre respectes lors de la gnration de ces certificats.

R4
Seule une AC non publique (dont la confiance nest pas reconnue au del du systme
dinformation) doit tre utilise pour signer les certificats que le proxy prsente ses
clients.

Si cette rgle nest pas respecte, cela peut conduire la gnration de certificats valides publique-
ment (hors du systme dinformation) mais qui ne sont pas lgitimes vis--vis des sites web auxquels ils
sont associs. Le vol des cls prives associes ces certificats pourrait permettre une personne mal
intentionne de dchiffrer le trafic HTTPS de clients prsents sur Internet sans que ceux-ci ne puissent
sen apercevoir (puisque leur navigateur validerait le certificat sans provoquer derreur). Afin de dtecter
ces certificats illgitimes , les versions rcentes des navigateurs (les plus rpandus) implmentent des
fonctionnalits spcifiques permettant des vrifications avances. Chrome et Firefox intgrent le Cer-
tificate Pinning 17 . Internet Explorer dispose de SmartScreen Filter 18 . Ces fonctionnalits permettent
de vrifier que le certificat prsent par un site web est sign par lAC publique quil a dclare comme
tant celle lgitime pour signer son certificat. Si lAC qui a sign le certificat prsent au client par le
site web ne correspond pas celle dont le navigateur a connaissance pour ce site web, le navigateur peut
alerter lutilisateur, voire lui interdire laccs au site (possibilit dattaque active dite de lhomme
du milieu ). Lalerte peut mme tre remonte automatiquement la socit qui dite le navigateur
afin que celle-ci soit informe du mauvais usage dune AC dont la confiance est reconnue publiquement.

Les fonctionnalits de Certificate Pinning/SmartScreen Filter ninterdisent cependant pas lusage

dAC internes (dont la confiance nest pas reconnue publiquement) pour signer des certificats associs
des sites web publics. Cette pratique est considre comme un cas dusage lgitime de dchiffrement
des flux HTTPS : en effet, la configuration des postes clients est obligatoire pour que le dchiffrement
puisse seffectuer sans que les navigateurs web ne lvent dalerte de scurit.

noter quil existe dautres mcanismes permettant certains navigateurs de vrifier la lgitimit
des certificats serveurs, cest par exemple le cas du projet Certificate Transparency 19 initi par Google.

R5
La chane de confiance associe au certificat de lAC interne qui a sign les certificats
prsents par le proxy ses clients doit tre place dans le magasin des autorits de
confiance utilis par le navigateur des clients. La confiance accorde cette chane
par le navigateur doit tre limite lauthentification des sites web (si lAC interne
nest utilise que pour signer des certificats serveurs).
17. Littralement : pinglage de certificats . Cette fonctionnalit est dcrite dans une RFC (brouillon) :
http://tools.ietf.org/html/draft-ietf-websec-key-pinning.
18. Cest partir de la version 11 dInternet Explorer que SmartScreen Filter vrifie les informations prsentes dans
les certificats. Pour plus dinformations : http://blogs.technet.com/b/pki/ (publication du 21 fvrier 2014).
19. http://www.certificate-transparency.org.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 10 sur 31

 La prsence de cette chane dans ce magasin va permettre au client de vrifier que le certificat
que lui prsente le proxy est sign par une AC dont la confiance est garantie au pralable. Si le naviga-
teur nest pas en mesure deffectuer cette vrification, celui-ci affichera au client une alerte de scurit
lorsquil tentera de se connecter au site web cible. Le message indiquera lutilisateur que le certificat
prsent est sign par une AC inconnue. Si celui-ci choisit malgr tout daccorder sa confiance cette
autorit et se connecte au site web il prend un risque important (dchiffrement du trafic par un tiers
son insu).

Pour assurer un fonctionnement transparent et sans alerte, la chane de confiance associe lAC
interne doit donc tre place au pralable dans le magasin de certificats par une personne disposant
des droits dadministration sur lapplication cliente ou le systme.

Cas des EV Certificates 20 : Lutilisation dune AC interne pour signer les certificats de sites web pu-
blics pose problme au niveau du navigateur du client lorsque celui-ci accde des sites qui disposent
normalement de certificats de type Extented Validation Certificate (ou EV Certificate). Pour rappel,
ce type de certificat, dun niveau de confiance lev, peut tre dlivr par une AC uniquement si elle
respecte une procdure prcise 21 . Une entit qui fait une demande dEV Certificate une AC au-
torise en dlivrer doit par exemple apporter la preuve de son existence physique et lgale. Lorsquun
navigateur accde un site qui lui prsente un EV Certificate sa barre dadresse se teinte en vert ;
celle-ci peut galement afficher (en fonction des navigateurs) des informations relatives lentit qui
dtient lEV certificate. Cela permet dindiquer lutilisateur quil accde un site web qui dispose
dun niveau de confiance important ; cest--dire qui prsente un certificat qui a t sign par une AC
spcifique qui dispose du droit de signer des EV Certificates. Les versions rcentes des navigateurs
sont en mesure deffectuer cette vrification car ils embarquent directement dans leur code source, de
faon statique, les informations relatives aux AC publiques qui ont lautorisation dmettre des EV
Certificates 22 . Lorsquun proxy dchiffre les flux HTTPS, il prsente lutilisateur un certificat sign
par une AC interne qui nest pas reconnue par le navigateur comme tant une autorit en mesure de
dlivrer des EV Certificate. Le certificat prsent est bien valide, le navigateur naffiche pas dalerte
de scurit, mais il ne teinte pas sa barre dadresse en vert. Lutilisateur est ainsi priv dindications
visuelles prvues lorigine pour renforcer le crdit quil accorde certains sites web.

Figure 4 Barre dadresse du navigateur Firefox lorsquun EV Certificate lui est prsent.
20. Extented Validation Certificate : littralement certificat validation tendue .
21. Procdure intitule EV SSL Certificate Guidelines publie par le CA/Browser Forum :
https://cabforum.org/extended-validation/.
22. Internet Explorer est le seul navigateur qui permet de passer outre la liste des autorits reconnues publiquement
aptes dlivrer des EV Certificate. Il permet ladministrateur dajouter des AC internes comme tant lgitimes pour
mettre des EV Certificate. Pour plus dinformations : http://technet.microsoft.com/en-us/library/dd759060.aspx.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 11 sur 31

3.2.1.2 Impact sur les performances
Les oprations cryptographiques ralises par le proxy pour dchiffrer le trafic HTTPS sont co-
teuses en ressources. Lquipement qui porte la fonction proxy doit donc tre dimensionn correctement
pour pouvoir supporter les tunnels TLS de lensemble des clients pour lesquels le trafic HTTPS est
dchiffr (en partie ou en totalit).

3.2.2 Bonnes pratiques

3.2.2.1 Gnration des certificats
Voici quelques recommandations concernant la gnration des certificats prsents par le proxy
ses clients :

R6
Une AC intermdiaire interne (sous-AC) doit tre ddie la signature des certificats
prsents par le proxy ses clients.

R7
Si la solution de proxy intgre nativement une AC (pr-configure en amont par
lditeur ou initialise linstallation), celle-ci ne doit pas tre utilise pour signer
de certificats. Lusage de ce type dAC prsente des risques : autorit identique sur
diffrents quipements, utilisation de gabarits non appropris, etc.

R8
Les cls prives associes aux certificats prsents par le proxy ses clients doivent
tre protges par des mcanismes adapts (se reporter au 2.4).

R9
Les certificats prsents par le proxy ses clients doivent tre gnrs en utilisant
des gabarits qui respectent les recommandations mentionnes dans les annexes du
RGS (se reporter au 2.3).

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 12 sur 31

3.2.2.2 Renforcement de la scurit de TLS
3.2.2.2.1 Scurit TLS entre les clients et le proxy
Bien que les rseaux qui sparent les clients du proxy sont gnralement considrs comme tant de
confiance, le trafic HTTPS interne doit tre correctement scuris afin dviter toute exposition inutile
des donnes protger. Cela est dautant plus ais mettre en uvre que les deux entits (les clients
et le proxy) sont matrises.

Voici quelques recommandations visant renforcer la scurit TLS entre les clients et le proxy.

R10
Le proxy ne doit permettre ltablissement de tunnels TLS quen utilisant les versions
de TLS les plus rcentes supportes par les navigateurs web des clients.

Lusage de TLS v1.1 (et versions suprieures) permet dviter dexposer les tunnels HTTPS
des attaques rcentes (BEAST 23 par exemple). Lensemble des versions de SSL (v2.0 et v3.0) doit
tre dsactiv au niveau du serveur TLS du proxy car les navigateurs rcents supportent a minima
TLS v1.0.

R11
Le proxy ne doit offrir ses clients que des suites cryptographiques robustes (se
reporter lannexe B de ce document).

Il est ncessaire de vrifier la compatibilit des suites retenues avec celles que supporte les na-
vigateurs web utiliss par les clients. La suite slectionne par le proxy pour tablir le tunnel TLS
avec le client doit tre la plus robuste parmi celles proposes par son navigateur (cette suite nest pas
ncessairement celle qui a la prfrence du client).

R12
Les suites cryptographiques les plus robustes offertes par le proxy doivent permettre
la PFS.

Le renforcement du niveau de scurit de TLS laide de la proprit PFS permet de se prmunir

contre des attaques internes dont le but serait de capturer du trafic afin de le dchiffrer ultrieurement.

R13
La compression TLS doit tre dsactive au niveau du serveur TLS du proxy.

Lusage de la compression TLS rend vulnrable le flux HTTPS lattaque CRIME 24 .

R14
Si le proxy supporte la reprise des sessions TLS, il est ncessaire de vrifier quels
mcanismes il implmente et comment ces derniers fonctionnent.

23. Browser Exploit Against SSL/TLS : Cette attaque publie en 2011 concerne les versions de TLS infrieures 1.1.
Elle est rfrence sous la CVE 2011-3389 (http://www.cvedetails.com/cve/CVE-2011-3389).
24. Compression Ratio Info-leak Made Easy : Cette attaque a t publie en 2012, elle est rfrence sous les
CVE 2012-4929 (http://www.cvedetails.com/cve/CVE-2012-4929) et 2012-4930 (http://www.cvedetails.com/cve/
CVE-2012-4930).

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 13 sur 31

 La reprise de sessions TLS peut seffectuer en utilisant des identifiants de session (session ID 25 )
ou des tickets de session (session ticket 26 ). Dans les deux cas, les informations sensibles relatives
ltat des sessions en cours sont manipules par le serveur TLS. Si ces donnes venaient tre compro-
mises, les sessions TLS pourraient tre dchiffres (mme si la PFS est active). Il est donc ncessaire
de sassurer que ces informations ne sont pas conserves abusivement par le serveur TLS. Idalement
ces donnes ne doivent tre stockes quen mmoire et durant un laps de temps dfini, de prfrence
configurable.

3.2.2.2.2 Scurit TLS entre le proxy et Internet

Les rseaux qui sparent le proxy du serveur web cible ne sont pas matriss. Le trafic HTTPS doit
donc tre scuris au maximum afin dviter toute compromission des donnes protger. Cela est
dautant plus difficile mettre en uvre que lune des deux entits (le serveur web) nest pas matrise.

Voici quelques recommandations visant renforcer la scurit TLS entre le proxy et le serveur web
cible :

R15
Le comportement du proxy en tant que client TLS doit tre vrifi afin de sassurer
que celui-ci nintroduise pas de faiblesses lors de ltablissement des tunnels TLS. Il
est par exemple ncessaire de valider le fonctionnement du proxy lorsquun serveur
lui prsente un certificat qui nest plus valide.

Certaines solutions de proxy ne vrifient pas correctement les caractristiques des certificats prsen-
ts par les serveurs web (dure de validit, chane de certification, etc.), ce qui expose par transitivit
les clients 27 . Le fonctionnement des mcanismes de rvocation supports par le proxy doivent tre
tests afin de dterminer le comportement exact du proxy lorsque celui-ci reoit un certificat rvoqu.

R16
Le client TLS du proxy doit supporter TLS v1.1 et v1.2 afin de disposer du meilleur
niveau de scurit lorsque les sites web visits supportent ces versions rcentes du
protocole.

R17
Les suites cryptographiques supportes par le proxy doivent tre proposes au serveur
web selon un ordre pr-tabli. Les suites les plus robustes (incluant la PFS ) doivent
tre prfres.

R18
Si le client du proxy supporte la rengociation TLS, celle-ci doit tre scurise 28 .

Le support de la rengociation scurise permet dviter de rendre vulnrable le canal de com-

munication certaines attaques actives dites de lhomme du milieu 29 .
25. RFC 5246.
26. RFC 5077.
27. Pour plus de dtails : http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/.
28. RFC 5746.
29. Vulnrabilit rfrence sous la CVE 2009-3555 (http://www.cvedetails.com/cve/CVE-2009-3555).

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 14 sur 31

 R19
Sauf ce que ce soit expressment valid, lorsquun serveur web slectionne une suite
cryptographique qui nest pas assez robuste, le proxy doit refuser ltablissement du
tunnel TLS. Le proxy peut informer le client lorigine de la demande et lui indiquer
que le site quil cherche joindre ne fournit pas un niveau de scurit suffisant au
regard des exigences qui lui sont fixes.

Si un serveur web retient une suite cryptographique trop faible, cela signifie quelle fait partie
de celles proposes par le proxy. Ce dernier peut tre amen supporter des suites cryptographiques
qui ne sont pas robustes (au sens RGS du terme) pour des questions de compatibilit. Cependant, le
proxy peut tre configur pour interdire lusage de ces suites lorsque le site web demand par le client
appartient une catgorie qui exige un niveau de scurit lev (compatible avec les exigences du RGS
par exemple).

R20
La compression TLS doit tre dsactive au niveau du client TLS du proxy.

Lusage de la compression TLS rend vulnrable le flux HTTPS lattaque CRIME.

R21
La liste des AC publiques de confiance intgres la solution de proxy doit tre
vrifie linstallation et doit tre revue de faon rgulire.

Les AC publiques intgres la solution de proxy ont t juges de confiance par lditeur. Il
a donc choisi dintgrer les chanes de confiance associes dans le magasin de ses proxys. Cette liste
nest pas ncessairement la mme que celle prsente dans le magasin des navigateurs web des clients
du proxy. Il est possible que lquipement accorde sa confiance des autorits qui ont t retires du
magasin des versions rcentes des navigateurs, par exemple suite des incidents de scurit rendus
publics. Cest la raison pour laquelle le magasin du proxy doit tre vrifi et maintenu jour par les
personnes en charge de son exploitation. Il est possible que ce magasin soit modifi lors des mises jour
logicielles du proxy (les notes de version doivent tre consultes pour le vrifier) ou par lintermdiaire
dun mcanisme automatique spcifique la solution de proxy employe.

3.2.2.3 Protection de la vie prive

Voici quelques recommandations visant limiter au maximum le traitement de donnes caractre
personnel au niveau dun proxy :

R22
Ne pas procder au dchiffrement de certains types de sites web identifis comme
tant destins un usage strictement personnel (certains sites bancaires par exem-
ple).

La dcision de ne pas dchiffrer le trafic HTTPS chang avec certains sites web doit tre prise
par le proxy avant ltablissement complet du tunnel TLS. Plusieurs possibilits existent mais elles
dpendent de la solution de proxy employe. Elles sont dtailles dans le paragraphe 3.3. Le dchiffre-
ment slectif prsente galement lavantage de diminuer la consommation de ressources au niveau du
proxy.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 15 sur 31

 R23
La journalisation des flux dchiffrs doit tre quivalente celle configure pour les
flux HTTP standards traits par le proxy. Elle ne doit pas permettre denregistrer
davantage dinformations.

R24
Si le proxy transmet dautres quipements le contenu dchiffr des flux HTTPS,
les liens sur lesquels transitent ces informations doivent tre protgs logiquement et
physiquement pour viter tout accs illgitime aux donnes.

Le proxy peut par exemple transmettre le contenu dchiffr dautres quipements laide du
protocole ICAP 30 qui nest pas ncessairement scuris. Des proxys peuvent galement schanger des
donnes issues du traffic dchiffr lorsquils sont dploys en grappe.

3.3 Traitement des flux HTTPS sans dchiffrement

Ce paragraphe dtaille le cas o le proxy web ne dchiffre pas le trafic HTTPS. Dans cette con-
figuration les possibilits daction du proxy sont beaucoup plus limites.

Figure 5 Traitement des flux HTTPS sans dchiffrement

Sans procder au dchiffrement du trafic HTTPS, il nest pas possible dinspecter le contenu des
changes HTTP. Cependant, il peut tre envisageable de raliser un filtrage lmentaire en procdant
lanalyse du contenu de certains flux transmis en clair avant ltablissement du tunnel TLS.

Il est par exemple possible danalyser le contenu de la demande de connexion HTTPS initiale
pour obtenir des informations concernant le site web demand. Lorsque les clients accdent un proxy
HTTP configur en mode explicite, la premire requte HTTPS utilise la mthode HTTP CONNECT
et contient en argument le FQDN 31 associ la premire URL demande par le client.

Lanalyse de la squence de ngociation TLS, qui dbute une fois le client connect au serveur,
permet galement dobtenir des informations concernant le site web demand quel que soit le mode
dans lequel le proxy est configur.
Voici les lments qui circulent en clair et quil est possible danalyser pour obtenir le domaine ou le
FQDN du site :
30. Internet Content Adaptation Protocol.
31. Full Qualified Domain Name ou nom dhte pleinnement qualifi (ex : www.ssi.gouv.fr).

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 16 sur 31

 le champ Common Name, contenu dans le certificat prsent par le serveur, peut contenir un
FQDN (voire un domaine) pour lequel le certificat est valide ;
le champ Subject Alternative Name, contenu dans le certificat prsent par le serveur, peut con-
tenir plusieurs FQDN (voire des domaines) pour lesquels le certificat est valide ;
le champ Server Name de lextension TLS Server Name Indication (SNI) contient le FQDN
du site web lorsque cette extension est utilise par le navigateur du client. Cette extension est
employe par certains navigateurs pour formuler explicitement, au moment de linitiation du
tunnel TLS, le FQDN du site web auquel le client souhaite accder. Si plusieurs sites web sont
accessibles par une mme adresse IP, le serveur web peut, grce ce mcanisme, tre en mesure
de prsenter au client le certificat correspondant au site quil cherche joindre.

Linspection du contenu de la squence de ngociation TLS permet galement de vrifier certains

paramtres qui dterminent le niveau de scurit du canal de communication (version de TLS, suites
cryptographiques, certificats, etc.). Si certaines exigences ne sont pas satisfaites, le proxy peut choisir
dempcher ltablissement du tunnel TLS.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 17 sur 31

4 Traitement des flux HTTPS entrants
Cette section a pour objectif de prsenter les possibilits de traitement des flux HTTPS qui sont
initis partir de clients externes (Internet par exemple) et destines des serveurs web hbergs au
sein dun systme dinformation matris .

4.1 Architecture
Lusage de serveurs mandataires inverses HTTP (ou reverse proxy HTTP) est une bonne pratique
darchitecture permettant de sassurer que lensemble des clients passent par un point de contrle unique
pour pouvoir accder des sites web hbergs sur des rseaux matriss. Cest donc au niveau du reverse
proxy que sont gnralement analyss les flux HTTPS entrants, si celui-ci dispose des fonctionnalits
permettant lanalyse de ce type de flux.

Figure 6 Reverse proxy HTTP

Remarque : Il nest pas recommand de procder lanalyse des flux HTTPS entrants laide dquipe-
ments qui ne se positionnent pas en coupure des sessions TLS (ex : sonde passive ). En effet, dans
ce type darchitecture, lquipement en charge de lanalyse ne peut procder au dchiffrement des flux
HTTPS que si les deux conditions suivantes sont remplies :
1. lquipement dispose dune copie des cls prives des sites web ;
2. les suites cryptographiques proposes par les serveurs web ne permettent pas la PFS. En effet,
lquipement en charge du dchiffrement doit tre en mesure de dterminer les cls de session
en utilisant uniquement les cls prives des serveurs web, ce qui nest pas possible avec la PFS.
Cette contrainte dgrade ainsi fortement le niveau de scurit des tunnels TLS tablis entre les
clients et les serveurs.
Ces architectures spcifiques ne seront pas traites dans la suite de ce document, nous considrerons
que le traitement des flux HTTPS est ralis par un quipement positionn en coupure des sessions
TLS et qui assure la fonction de reverse proxy.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 18 sur 31

4.2 Traitement des flux HTTPS par dchiffrement
Ce paragraphe dtaille le cas o le reverse proxy est le point de terminaison des sessions HTTPS
inities par les clients qui souhaitent accder au site web hberg en interne. Dans cette configuration le
reverse proxy peut ensuite se connecter au serveur web cible en HTTP ou en HTTPS, cela va dpendre
des choix raliss au niveau de larchitecture interne (se rfrer au 4.2.2.3).

Figure 7 Traitement des flux HTTPS entrants par dchiffrement

4.2.1 Les enjeux du dchiffrement

Avant de mettre en place des mcanismes de dchiffrement au niveau dun reverse proxy web, il
est ncessaire de bien comprendre les avantages, les inconvnients et les problmatiques que cela induit.

Le fait de terminer les tunnels TLS au niveau du reverse proxy procure plusieurs avantages :
il est possible danalyser le contenu HTTP afin de protger les serveurs web internes contre des
menaces manant des clients : attaque au niveau applicatif, envoi de fichiers malveillants, etc. ;
il est possible dagir sur le contenu HTTP dlivr : mise en cache, rcriture, etc. ;
il est possible de configurer de faon homogne et centralise la politique de journalisation des
accs aux sites web, au mme titre que pour les flux HTTP non scuriss ;
la centralisation des configurations TLS de lensemble des sites web accessibles publiquement
permet dassurer une cohrence et une homognit au niveau du paramtrage TLS de chacun
dentre eux ;
la protection des cls prives associes aux certificats publics peut tre homogne et peut tre
plus facilement renforce (usage de HSM par exemple). Celle-ci ne dpend plus des mcanismes
de protection mis en uvre par les serveurs qui hbergent les sites web internes ;
il est possible de dcharger les serveurs web internes. Lorsque ces derniers sont accds laide
du protocole HTTP par le reverse proxy (se rfrer au 4.2.2.3), ils nont pas excuter les
oprations cryptographiques ncessaires ltablissement et au maintien de tunnels TLS.

Cependant, le dchiffrement prsente quelques inconvnients :

des donnes normalement chiffres jusquau serveur web sont prsentes en clair au niveau du
reverse proxy ;
la concentration de lensemble des bi-cls au niveau du reverse proxy accrot la criticit de ce
composant ;
si une authentification du client laide dun certificat doit tre mise en place, cest le reverse
proxy qui porte cette fonction. Une fois le client correctement authentifi, le reverse proxy doit

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 19 sur 31

 ensuite employer des mcanismes scuriss pour propager lidentit du client jusquau serveur
web cible (se reporter au 4.2.2.4).

En rsum, si le dchiffrement des flux HTTPS au niveau dun reverse proxy prsente quelques
inconvnients, ce choix darchitecture est particulierement pertinent pour exercer un contrle des don-
nes changes avec lextrieur. Ce type darchitecture permet galement dassurer lhomognit dun
ensemble dlments de configuration contribuant renforcer la scurit des tunnels TLS tablis avec
des clients non matriss.

4.2.2 Bonnes pratiques

4.2.2.1 Gnration des certificats
Les certificats prsents aux clients par le reverse proxy doivent tre gnrs partir dune AC dont
la confiance est reconnue publiquement (dont la chane de confiance associe est prsente dans le ma-
gasin des navigateurs). Cette condition est ncessaire pour quaucun message derreur ne soit prsent
aux clients lorsquils cherchent accder au serveur web hberg au sein du systme dinformation
interne. Le choix du PSCE 32 en charge de fournir les certificats publics est un lment structurant qui
contribue amliorer le niveau de scurit dun service HTTPS accessible depuis Internet.

Les PSCE qualifis par lANSSI sont rfrencs sur le site web du LSTI 33 . Certaines recomman-
dations mentionnes dans le guide ANSSI relatif lexternalisation 34 peuvent galement aider la
slection dun PSCE.

Les critres suivants peuvent galement permettre de slectionner un PSCE :

R25
Utiliser une AC opre sur le territoire national.

R26
Utiliser une AC qui propose des certificats compatibles avec les exigences formules
par le RGS.

R27
Utiliser une AC reconnue comme tant de confiance par une large majorit des na-
vigateurs web du march.

R28
Choisir un prestataire qui est en mesure dapporter des lments prouvant son
srieux : accs scuris au service client, engagements du support technique, cer-
tification 35 , dlivrance dEV Certificate, etc.
32. Prestataire de Service de Certification lectronique.
33. LSTI : Laboratoire en Sciences et Technologies de lInformation. La liste des PSCE qualifis est dtaille ladresse
http://www.lsti-certification.fr/images/liste_entreprise/ListePSCe.pdf.
34. http://www.ssi.gouv.fr/IMG/pdf/2010-12-03_Guide_externalisation.pdf.
35. Certification WebTrust For CA par exemple : http://www.webtrust.org.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 20 sur 31

4.2.2.2 Scurit TLS entre le reverse proxy et Internet (les clients)
Les rseaux qui sparent les clients et le reverse proxy ne sont pas matriss. Le trafic HTTPS doit
donc tre scuris au maximum afin dviter toute compromission des donnes protger. Cela est
dautant plus difficile mettre en uvre que lune des deux entits (le client) nest pas matrise.

Les recommandations suivantes visent renforcer la scurit TLS entre le reverse proxy et Inter-
net :

R29
Le reverse proxy ne doit permettre ltablissement de tunnels TLS quen utilisant les
versions rcentes de ce protocole.

Lusage de TLS v1.1 (et versions suprieures) permet dviter dexposer les tunnels HTTPS
des attaques rcentes (BEAST par exemple). Lensemble des versions de SSL (v2.0 et v3.0) doit tre
dsactiv. Par contre, pour des questions de compatibilit, il est encore ncessaire de supporter TLS
v1.0. Nanmoins, si cette version est active, il est ncessaire de vrifier que la solution de reverse
proxy employe implmente correctement les contre mesures corrigeant certaines vulnrabilits propres
cette version du protocole.

R30
Le reverse proxy ne doit proposer que des suites cryptographiques dont le niveau de
scurit est acceptable (se reporter lannexe B de ce document). Il doit slectionner
en priorit les suites les plus robustes (incluant la PFS ) parmi celles proposes par
le client.

R31
Seule une rengociation scurise peut tre autorise par le reverse proxy.

R32
Si le reverse proxy supporte la reprise de sessions TLS, il est ncessaire de dterminer
quels mcanismes il implmente et comment ces derniers fonctionnent.

La reprise de sessions TLS peut seffectuer en utilisant des identifiants de session (session ID)
ou des tickets de session (session ticket). Dans les deux cas, les informations sensibles relatives ltat
des sessions en cours sont manipules par le serveur TLS. Si ces donnes venaient tre compromises,
les sessions TLS pourraient tre dchiffres (mme si la PFS est active). Il est donc ncessaire de
sassurer que ces informations ne sont pas conserves abusivement par le reverse proxy. Idalement
ces donnes ne doivent tre stockes quen mmoire et durant un laps de temps dfini, de prfrence
configurable.

R33
La compression TLS doit tre dsactive au niveau du reverse proxy.

Lusage de la compression TLS rend vulnrable le flux HTTPS lattaque CRIME.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 21 sur 31

4.2.2.3 Scurit du trafic interne (entre le reverse proxy et le serveur web)
Deux choix sont possibles concernant le trafic web qui circule entre le reverse proxy et le serveur
web interne :
1. le protocole HTTPS peut tre utilis par le reverse proxy pour accder au serveur web. Dans ce
cas, les donnes qui circulent sur les rseaux internes sont protges. Dans cette configuration,
le serveur web doit disposer de bi-cls (couples certificat/cl prive) qui lui sont propres. Les
certificats prsents sur le serveur web doivent tre signs par une AC non publique. Seul le
reverse proxy aura connaissance de ces certificats. Il ne sera jamais visible par les clients (qui
nont connaissance que des certificats prsents par le reverse proxy). Le reverse proxy doit
galement disposer dans son magasin de la chane de confiance associe lAC interne pour
valider le certificat prsent par le serveur Web ;
2. le protocole HTTP peut tre utilis par le reverse proxy pour accder au serveur web. Dans ce cas,
les donnes qui circulent sur les rseaux internes ne sont pas protges. Dans cette configuration,
le serveur cible nhberge pas de bi-cl.

Le choix de larchitecture dpend :

du niveau de confidentialit du contenu : il est ncessaire de dterminer si larchitecture rseau
interne permet de garantir une protection suffisante pour autoriser la circulation en clair de
donnes qui sont protges lorsquelles circulent sur Internet ;
du besoin en intgrit : il est ncessaire de dterminer si la contrainte en intgrit est forte sur
les donnes. Par exemple, lorsque le reverse proxy transmet au serveur web cible des informations
relatives aux utilisateurs quil a pralablement authentifis (se reporter au 4.2.2.4) ;
du dimensionnement des serveurs web : il est ncessaire de dterminer si les serveurs qui hber-
gent les sites web internes disposent des ressources matrielles suffisantes pour pouvoir supporter
les oprations cryptographiques ncessaires ltablissement et au maintien de sessions HTTPS ;
du cot dexploitation : lemploi du procotole HTTPS au niveau des serveurs web implique la
gestion de certificats internes en plus de ceux hbergs par le reverse proxy.

4.2.2.4 Propagation de lidentit des clients

Les architectures ncessitant le dport de la premire authentification des clients au niveau du
reverse proxy (usage de certificats clients par exemple) pose la problmatique de la propagation des
informations didentification jusquau site web cible. En effet, le reverse proxy doit tre en mesure
de communiquer au site les informations relatives aux utilisateurs quil a correctement authentifis.
Une solution simple (parmi dautres) consiste configurer le reverse proxy pour quil inscrive dans les
en-ttes HTTP les informations relatives lidentit des utilisateurs authentifis. Le contenu de ces
en-ttes est ensuite pris en compte par le site web cible qui peut ainsi diffrencier ses traitements en
fonction des informations didentification quil reoit.

Lajout dinformations dans les en-ttes HTTP par un reverse proxy nest pas un mcanisme utilis
exclusivement pour propager des informations didentification, il peut par exemple tre employ pour
transmettre au serveur web cible ladresse IP originelle du client (en-tte X-Forwarded-For ).

Quel que soit le cas dusage, lajout dinformations dans les en-ttes HTTP peut prsenter un risque
si les clients sont en mesure de forger ces en-ttes en amont dans le but de tromper le serveur cible.
Pour viter cela, le reverse proxy doit vrifier au pralable les en-ttes des requtes HTTP quil reoit
des clients et doit procder leur nettoyage si ncessaire.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 22 sur 31

Attention : Lacceptation du client ne doit pas se baser uniquement sur la validit des informations
dauthentification quil prsente. Un client peut sauthentifier correctement sans pour autant tre au-
toris accder la ressource quil demande. En consquence, la solution mise en oeuvre doit galement
permettre de vrifier que lutilisateur dispose des droits daccs au site web demand, charge au reverse
proxy ou au seveur web de raliser cette vrification.

4.3 Traitement des flux HTTPS sans dchiffrement

Ce paragraphe prsente le cas o le reverse proxy nest pas le point de terminaison des sessions
HTTPS inities par les clients qui souhaient accder au site web hberg sur le systme dinformation
interne. Dans cette configuration, le reverse proxy ne fait que transfrer les donnes chiffres entre le
client et le serveur web cible. Il nhberge alors aucun bi-cl.

Figure 8 Traitement des flux HTTPS entrants sans dchiffrement

La mise en uvre de ce type darchitecture ne prsente pas de rel intrt dans la mesure o elle ne
permet pas au reverse proxy daccder au contenu HTTP. Ce dernier peut simplement sassurer que les
serveurs web internes tablissent les tunnels TLS en respectant les exigences de scurit auxquelles ils
sont normalement assujettis (suites cryptographiques, version de TLS, etc.). Ce type de configuration
oblige galement les serveurs web hberger leurs cls prives accompagnes de leurs certificats signs
par une AC dont la confiance est reconnue publiquement.

4.4 Scurit web complmentaire

Lusage de TLS est fondamental pour assurer la scurisation de flux HTTP mais lemploi de ce
protocole nest pas suffisant. Dautres mesures complmentaires doivent tre mises en uvre au niveau
des serveurs web pour ne pas exposer les informations protger.

Voici une liste non exhaustive de bonnes pratiques de scurisation qui viennent en complment
de lusage du protocole HTTPS. Ces recommandations sont applicables directement au niveau de la
configuration des sites web hbergs.

R34
Ne pas activer le protocole de compression HTTP nomm SPDY 36 lorsquun site
web est accessible laide du protocole HTTPS.

Cette mesure est ncessaire afin de se prmunir contre lattaque CRIME mentionne prcdem-
ment. Cette dernire fonctionne non seulement lorsque la compression TLS est active mais galement
36. SPDY (se prononce speedy ) : Protocole de compression permettant lacclration du chargement du contenu
HTTP.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 23 sur 31

lors de lemploi combin du protocole HTTPS et de SPDY.

R35
Ne pas inclure de liens HTTP dans une page web accessible laide du protocole
HTTPS (problme dit de mixed content 37 ) .

Le fait dinclure du contenu non scuris dans une page accessible laide du protocole HTTPS
rend vulnrable le site web des attaques actives dites de lhomme du milieu ralises laide
de scripts malveillants. Certains navigateurs alertent lutilisateur lorsque des contenus de diffrentes
natures sont prsents dans une page web.

R36
Renforcer la scurit des cookies laide des attributs Secure et HttpOnly.

Lattribut Secure indique que le cookie ne peut tre transmis par le serveur que par lintermdiaire du
protocole HTTPS. Cela vite son envoi sans protection. Lattribut HttpOnly interdit laccs au cookie
par des scripts excuts par le navigateur du client. Cela rduit le risque dattaques de type XSS 38 .

R37
Utiliser les en-ttes HTTP HSTS 39 et CSP 40 pour renforcer la scurit de laccs et
du contenu des sites web.

Len-tte HSTS indique au navigateur du client (sil est compatible) que le site web doit tre ac-
cd uniquement laide du protocole HTTPS. Len-tte CSP permet de restreindre lorigine des
contenus (image, script, etc.) inclus dans une page. Cela permet de se prmunir contre les attaques
de type XSS en restreignant les domaines de provenance des contenus tiers prsents dans une page web.

La note technique ANSSI intitule Recommandations pour la scurisation des sites web 41 d-
taille plus largement les mesures de scurisation dun site web, quil soit accessible laide du protocole
HTTPS ou non.

37. https://developer.mozilla.org/en-US/docs/Security/MixedContent.
38. Cross-site scripting ou injection de code indirecte .
39. HTTP Strict Transport Security.
40. Content Security Policy.
41. http://www.ssi.gouv.fr/IMG/pdf/NP_Securite_Web_NoteTech.pdf.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 24 sur 31

5 Validation des configurations
La configuration TLS dun proxy ou dun reverse proxy doit tre valide afin de sassurer que
celle-ci est correctement scurise. Elle peut tre teste laide doutils, voire de services, spcifiques
disponibles sur Internet.

Voici quelques exemples doutils 42 permettant de tester le paramtrage dun serveur TLS :

client OpenSSL : OpenSSL 43 est une implmentation de SSL/TLS en source ouverte. Cette bote
outils inclut en particulier un client SSL/TLS en ligne de commande : openssl s_client. Cet
outil offre des fonctionnalits tendues permettant dinterroger un serveur TLS et dinvestiguer
en dtail dventuels problmes de configuration. TLS v1.2 nest support qu partir de la version
1.0.1 dOpenSSL ;
SSLScan : cet outil repose sur OpenSSL. Il permet de tester un service SSL/TLS et offre en
particulier la possibilit de lister les suites cryptographiques supportes par le serveur. noter
que TLS v1.1 et v1.2 ne sont supports qu partir de la version 1.10.0 44 de SSLScan ;
SSLyze : cet outil est galement un scanner SSL/TLS qui repose aussi sur OpenSSL. TLS v1.2
nest support qu partir de la version 0.4 de SSLyze 45 .

Pour les services en ligne, le site https ://www.ssllabs.com (qui appartient lditeur de solutions
de scurit Qualys) met disposition gratuitement de nombreuses ressources concernant TLS (bonnes
pratiques, tableaux de bord, etc.). Il fournit en particulier des services permettant dvaluer en ligne
la configuration TLS dun client ou dun serveur.

42. Les outils et services sont donns titre indicatif sans garantie de lANSSI sur la confiance leur accorder.
43. http://www.openssl.org.
44. https://github.com/dinotools/sslscan.
45. https://github.com/isecpartners/sslyze.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 25 sur 31

 Annexes
A Aspects juridiques
Cette annexe prsente les aspects juridiques lis au dchiffrement de flux dans un but informatif et
de manire non-exhaustive. En particulier, elle se limite aux problmatiques lies aux flux entrants et
sortants depuis les postes de travail de salaris quils soient fixes ou nomades.

La question du dchiffrement dun contenu implique ncessairement celle du chiffrement de celui-ci en

amont. Or les deux oprations comportent des risques juridiques qui peuvent apparatre antinomiques.
En effet, un contenu chiffr peut tre source de comportement dlictueux donnant lieu la mise en jeu
de la responsabilit de lentit. Le dchiffrement, qui rend visible un contenu destin tre confiden-
tiel, permet de se prmunir contre ce risque mais parfois au prix des risques censs tre couverts par le
chiffrement.

Le chiffrement tant reli une technologie laquelle peuvent correspondre plusieurs usages, la prsente
note se limite au fait quil rpond au seul besoin de garantir la confidentialit des changes de donnes
lectroniques, lexclusion du chiffrement usage de signature ou dauthentification.

En tout tat de cause, le lecteur qui souhaite obtenir des informations plus dtailles est invit
se faire assister par un conseil.

De faon synthtique, si la mise en place doutils de chiffrement est autorise et soumise un

rgime juridique particulier, elle nen est pas moins susceptible dentraner un risque non ngligeable
de mise en cause de la responsabilit de lentit qui en bnficie, et ce sur plusieurs fondements. Pour
se prserver, lemployeur peut effectivement tre amen mettre en place un systme de dchiffrement
et de contrle des changes dinformation raliss par ses salaris sur les systmes dinformation quil
met leur disposition qui, sil nest pas strictement encadr, peut conduire lemployeur engager sa
responsabilit sur dautres fondements.

Le rgime juridique du chiffrement

Lutilisation des moyens de cryptologie est libre en France 46 . En revanche, la fourniture, le transfert
depuis ou vers un tat membre de la Communaut europenne ainsi que limportation et lexportation
de ces moyens sont rglements lorsquils nassurent pas exclusivement des fonctions dauthentification
ou de contrle dintgrit. En sont donc, par nature exclus, les outils de contrle daccs et les passe-
ports. Ces oprations doivent alors faire lobjet dune dclaration pralable ou dune autorisation de
lANSSI 47 .

La mise en place doutils de chiffrement est soumise des dispositions lgales relatives
la cryptologie dont la violation peut tre sanctionne sur le plan administratif, civil et
pnal 48 .

46. Loi n 2004-575 du 21 juin 2004 pour la confiance dans lconomie numrique (LCEN), art. 30 ; dcret n 2007-663
du 2 mai 2007 pris pour lapplication des articles 30,31 et 36 de la loi n 2004-575 du 21 juin 2004 pour la confiance dans
lconomie numrique et relatif aux moyens et aux prestations de cryptologie.
47. Informations complmentaires disponibles sur : http ://www.ssi.gouv.fr/fr/reglementation-ssi/cryptologie/ . Con-
tact : controle [at] ssi.gouv.fr.
48. En cas de non-respect de ces dispositions, des sanctions administratives telles linterdiction de mise en circulation
du moyen de cryptologie (art. 34 LCEN), des sanctions pnale assorties, le cas chant, de peines complmentaires telles

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 26 sur 31

Les risques juridiques lis au chiffrement
Lutilisation de moyens de chiffrement peut tre source de responsabilit de lemployeur, notam-
ment, lorsque le chiffrement a permis ou facilit la commission dinfractions ou a conduit au non-respect
des obligations de scurit sa charge. Les fondements sont multiples, savoir :
selon larticle 1384 alina 5 du Code civil, lemployeur est responsable de lagissement de ses
salaris 49 notamment sur les rseaux informatiques 50 . Un employeur peut tre tenu responsable
si lemploy commet des infractions sur son lieu de travail et avec les outils professionnels mis
sa disposition sauf si lemployeur dmontre que le salari a agi sans autorisation et en dehors de
ces attributions 51 ;
lemployeur peut tre soumis certaines obligations prcises larticle 6-I-7 de la LCEN (no-
tamment la conservation des lments de journalisation relatifs aux changes) sil est considr
comme un fournisseur daccs Internet 52 au sens de larticle 6-I de la LCEN 53 ;
en tant que responsable du traitement des donnes caractre personnel qui est soumis aux
obligations de scurit et de notification de la violation des donnes caractre personnel imposes
par la loi Informatique et Liberts 54 ;
le titulaire dun accs des services de communications au public en ligne est responsable de la
scurisation de cet accs selon les articles L. 336-3 et R. 335-5 du code de proprit intellectuelle.

Lutilisation de moyens de chiffrement nentrane pas, par elle-mme, la responsabilit de

lemployeur ds lors quelle est libre.
En revanche, sa responsabilit peut tre engage soit :
en raison dagissements dlictueux qui pourraient tre commis par les salaris grce
aux moyens quil leur a fournis (matriels, accs internet, etc.) et dissimuls grce au
chiffrement ;
en raison du non-respect dobligations lies la scurit (des donnes, de laccs
Internet, etc.).

En consquence, lemployeur est lgitime dchiffrer les contenus de flux chiffrs transi-
tant sur les postes de travail de ses salaris, mais uniquement de faon encadre en raison
des risques juridiques lis au dchiffrement.

la confiscation, la fermeture dtablissement et lexclusion des marchs publics peuvent tre appliques. Dans ce dernier
cas, les articles 35, 36 et 37 de la LCEN prvoient notamment un an demprisonnement et 15.000 euros damende en cas
de non dclaration ou de communication dinformations et jusqu deux ans demprisonnement et 30.000 euros damende
en cas de non obtention dautorisation.
49. CA Paris, 4 mai 2007 : il est en outre impossible de se prvaloir de la faute contractuelle du cocontractant du fait
des comportements fautifs de ses propres salaris.
50. TGI Marseille, 11 juin 2003, D. 2003, le TGI avait jug solidairement responsable une socit qui avait fourni un
accs internet lun de ses salaris qui avait diffus des contenus prjudiciables sur internet par lintermdiaire de pages
personnelles.
51. Cass. Ass.pln., 19 mai 1988, n87682.654 et CA Versailles 5me ch. du 31 mars 2011 Michal P.C./Mireille B.-P.
illustrent la validation du licenciement pour faute grave dun salari ayant tlcharg illgalement des fichiers musicaux
sur son poste de travail.
52. Un arrt de la Cour dappel de Paris du 4 fvrier 2005 a pu jeter le doute sur lapplication du rgime juridique des
FAI aux employeurs mettant disposition de leurs salaris un accs Internet.
53. Cette interprtation est prsente de manire dtaille dans la note technique Recomman-
dations de scurit pour la mise en ouvre dun systme de journalisation rdige par lANSSI :
http ://www.ssi.gouv.fr/IMG/pdf/NP_Journalisation_NoteTech.pdf
54. Articles 34 et 34 bis de la loi n78-17 du 6 janvier 1978 relative linformatique, aux fichiers et aux liberts.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 27 sur 31

Lidentification et la qualification des risques juridiques lis au dchiffrement
titre de rappel, les articles 100 et suivants du code de la procdure pnale imposent une obligation
lgale de dchiffrement dans le cadre des interceptions judiciaires, les articles L 241-1 L 245-3 du
code de la scurit intrieure dans le cadre des interceptions de scurit et larticle 230-1 du code de
procdure pnale dans le cadre dune enqute ou dune instruction 55 .

En dehors de ces hypothses, le dchiffrement dun flux chiffr, en particulier lorsquil concerne la
sphre personnelle, sur le lieu de travail pourrait notamment porter atteinte :
au secret des correspondances prives 56 ;
la protection des donnes caractre personnel 57 ;
la vie prive 58 des utilisateurs en dehors et dans le cadre du travail ;
la sensibilit des informations (dchiffrement de donnes protges par le secret professionnel,
par une rglementation telle la rglementation relative la protection du patrimoine scientifique
et technique de la nation 59 ou le secret de la dfense nationale 60 ).

Le dchiffrement soulve galement des risques juridiques dans le cadre de lintervention de tiers sur les
systmes dinformation (sous-traitance, audit des systmes dcouvrant des vulnrabilits contenant des
donnes caractre personnel, etc.). Afin de prvenir ces risques, il est primordial dencadrer juridique-
ment cette possibilit dans le contrat dexternalisation, notamment en soumettant le sous-traitant
des obligations identiques celles auxquelles se soumet lemployeur pour prserver sa responsabilit 61 .

Le dchiffrement dun flux chiffr peut porter atteinte aux liberts individuelles et engager
la responsabilit de lemployeur qui naurait pas prvu les mesures destines prserver
celles-ci.

55. Larticle 434-15-2 du code pnal prvoit galement trois ans demprisonnement et 45.000 euros damende si le dten-
teur des cls de dchiffrement de donnes chiffres ne les fournit pas lautorit judiciaire et aux services dinvestigation
qui peuvent en avoir besoin dans le cadre dune enqute pnale.
56. Article 226-15 du code pnal.
57. Articles 226-16 226-24 du code pnal.
58. Articles 226-1 226-7 du code pnal.
59. La protection du potentiel scientifique et technique de la nation est dfinie par le dcret n2011-1425 du 2 novembre
2011 portant application de larticle 413-7 du code pnal et relatif la protection du potentiel scientifique et technique de
la nation et par larrt du Premier ministre du 3 juillet 2012 relatif la protection du potentiel scientifique et technique
de la nation.
60. Instruction gnrale interministrielle n1300/SGDSN/PSE/PSD du 30 novembre 2011 sur la protection du secret
de la dfense nationale.
61. titre dexemple, T. Corr Nanterre, 10 novembre 2011 : la responsabilit pnale de lentreprise est retenue du fait
des infractions commises par son sous-traitant sur le systme dinformations dune autre entit. Il est donc primordial
dencadrer le contenu des contrats des sous-traitants et surtout le primtre de leurs interventions pour ne pas risquer
de contrevenir aux lgislations prcises dans la note. En outre, la mise en place de procdures de contrle internes
pour viter toute ingrence dun sous-traitant est recommande (sous-traitant en charge de dchiffrer les contenus, par
exemple, qui devra respecter les obligations mises la charge dun administrateur.).

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 28 sur 31

Encadrement juridique du dchiffrement
Gnralits
La mise en place par une entit dun mcanisme de dchiffrement des flux doit saccompagner du
respect des principes gnraux suivants 62 :
transparence et loyaut de lemployeur vis--vis de ses salaris en les informant sur la nature des
mesures informatiques prises sur le rseau informatique de lentit et en recueillant leur consen-
tement individuel sur la charte informatique ainsi quen consultant les instances reprsentatives
du personnel 63 ;
ncessit et proportionnalit 64 de la mise en place dun outil de dchiffrement par rapport aux
finalits annonces par lemployeur (telles la scurit du rseau, la protection des donnes sensibles
de lentit) qui imposent que les mesures prises soient justifies par la nature de la tche et
proportionnes la finalit ;
la protection des donnes caractre personnel et notamment la vrification que les formalits
accomplies auprs de la Commission nationale de linformatique et des liberts (CNIL) couvrent
les traitements et les donnes opres par de tels mcanismes ;
le contrle de laccs aux outils de dchiffrement (logiciels de dchiffrement, cls de chiffrement
des matriels ou des utilisateurs) en particulier lorsquune mauvaise utilisation peut engager
la responsabilit dun tiers (salari notamment). Les accs aux cls de chiffrement notamment
lorsquil sagit dun accs au squestre des cls des utilisateurs doivent tre journaliss et tre
prvu dans la charte informatique de lentit.

Le dchiffrement ne doit pas tre mis en place sans avoir satisfait des formalits lgales et
sans avoir anticip sa mise en place pour assurer son opposabilit aux salaris de lentit.

Encadrement juridique de la fonction dadministrateur de rseau ou de parc informatique en matire

de dchiffrement
Ladministrateur a pour mission dassurer le fonctionnement normal et la scurit des rseaux et
systmes dont il a la charge. En consquence de cette mission, ladministrateur est tenu par une obli-
gation de confidentialit et ne doit donc pas divulguer des informations dont il a eu connaissance dans
le cadre de ses fonctions.

Selon la jurisprudence 65 , ladministrateur peut, dans le cadre de ses fonctions et en particulier pour
garantir la scurit du rseau, de manire intentionnelle ou non, avoir accs des informations relevant
de la vie prive et des correspondances prives des utilisateurs. Laccs de telles donnes ne peut tre
justifi que dans les cas o le bon fonctionnement et le maintien en condition de scurit du rseau des
systmes informatiques ne peuvent tre assurs par dautres moyens moins intrusifs. Lutilisateur doit
tre prsent, ou dment appel 66 , en cas de lecture de contenus identifis comme personnels ou
privs 67 .

62. Ces principes gnraux sont les principes retenus dans les jurisprudences relatives au droit du travail et dont
lapprciation du respect reste soumise lapprciation souveraine des juges.
63. Article 2323-32 du code du travail.
64. Article 1121-1 du code du travail.
65. CA de Paris, 11me chambre, 17 dcembre 2001 : [i]l est dans la fonction des administrateurs de rseaux dassurer
le fonctionnement normal de ceux-ci ainsi que leur scurit ce qui entrane entre autre, quils aient accs aux messageries
et leur contenu [. . . ]. Par contre, la divulgation du contenu des messages, et notamment du dernier qui concernait le
conflit latent dont le laboratoire tait le cadre, ne relevait pas de cet objectif .
66. Cass, Soc., 17 juin 2009, n pourvoi 08-40274.
67. Cass, Soc., 17 mai 2005, n pourvoi 03-40017.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 29 sur 31

Ladministrateur, fonctionnaire ou tout agent public contractuel, est tenu par une obligation de dnon-
ciation de porte gnrale, qui est de nature le dlier de son obligation de secret professionnel y
compris en cas de dlit commis par un membre de sa hirarchie dans lexercice de ses fonctions 68 .

Ladministrateur peut dans le cadre de ses missions dchiffrer des donnes tout en restant
soumis une obligation de confidentialit.

En conclusion, la mise en place dun dispositif de dchiffrement par lentit doit tre
encadre juridiquement :
par la charte dutilisation des moyens informatiques et de communications lectroniques
rdige par lemployeur et annexe au rglement intrieur de lentit, aprs consultation
des instances reprsentatives du personnel. Celle-ci devra prvoir, notamment, les rgles
dutilisation des moyens mis disposition par lemployeur, les modalits daccs aux
donnes et aux quipements, lhypothse, les sanctions en cas de non-respect, etc. ;
par la mise en place dun administrateur expressment autoris accder aux contenus
dchiffrs moyennant le respect dune obligation de confidentialit qui le lie, y compris
lgard de lemployeur ;
par la politique de scurit des systmes dinformation de lentit qui devra envisager
cette hypothse, et ventuellement le cas des sous-traitants ;
par les dclarations adaptes la CNIL en considrant avec soin les finalits pour
lesquelles le dchiffrement est envisag.

68. Article 40 alina 2 du code de procdure pnale.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 30 sur 31

B Suites cryptographiques acceptables
Lensemble des suites cryptographiques quil est possible demployer avec TLS sont rfrences sur
le site de lIANA 69 . Il en existe plus de 300.
Chaque suite cryptographique est identifie par un code hexadcimal ainsi que par une description
qui obit la convention de nommage suivante :

Cl_[Auth]_Sym_Hach

Dtail des champs :

Cl : mcanisme dchange de cls (ex : ECDHE) ;
Auth : algorithme (facultatif) utilis pour lauthentification des parties (ex : RSA) ;
Sym : algorithme de chiffrement symtrique utilis pour chiffrer les donnes ; il est accompagn
de la taille de cl en bits ainsi que du mode utilis (ex : AES_128_GCM) ;
Hach : fonction de hachage utilise pour protger en intgrit les changes (ex : SHA256).

Il est souvent trs difficile de restreindre la liste des suites cryptographiques en se basant uniquement
sur les exigences listes dans le RGS. Cela conduit en effet la dfinition dune liste trs rduite ne
permettant pas dassurer une compatibilit suffisante pour pouvoir tre utilise dans un environnement
de production htrogne. Cependant les suites privilgier doivent permettre la PFS et doivent em-
ployer des algorithmes et des tailles de cls robustes au sens RGS du terme.

Les suites cryptographiques quil est possible de considrer comme acceptables 70 , pour TLS unique-
ment (v1.0, 1.1 et 1.2), doivent respecter les recommandations suivantes :
lusage de suites dont lune des composantes est NULL est proscrire ;
lusage de suites permettant une authentification anonyme (anon) est proscrire ;
moins quelles ne soient explicitement souhaites, les suites reposant sur lun des mcanismes
dchange de cls suivant sont proscrire : PSK, SRP, KRB5 ;
lusage de suites utilisant MD5 comme fonction de hachage est proscrire ;
lusage de suites utilisant un des algorithmes de chiffrement symtrique suivant est proscrire :
DES, RC2, RC4 ;
lusage de suites utilisant un mcanisme dchange de cls bas sur DSS est proscrire ;
lusage de suites utilisant SHA1 comme fonction de hachage est tolr, mais il est conseill de
privilgier des fonctions plus robustes telles que SHA256 ;
lusage de suites utilisant 3DES comme algorithme de chiffrement symtrique est tolr en dernier
recours, mais il est conseill dutiliser des algorithmes robustes tels que AES128 ;
si TLS v1.0 est activ, il est ncessaire de sassurer que limplmentation du composant utilis
(client ou serveur TLS) inclut les contre mesures permettant de rendre inoprante lattaque
BEAST sur le mode CBC des algorithmes concerns (CVE 2011-3389 71 ).

69. La liste de lensemble des suites : http://iana.org/assignments/tls-parameters/tls-parameters.xhtml.

70. la date de rdaction de ce document.
71. http://www.cvedetails.com/cve/CVE-2011-3389.

No DAT-NT-19/ANSSI/SDE/NP du 1er octobre 2014 Page 31 sur 31