premier ministre - ssi.gouv.fr · publicvisé: développeur x administrateur x rssi x dsi x...

Public vis:Dveloppeur XAdministrateur XRSSI XDSI XUtilisateur

DAT

-NT

-19/AN

SSI/S

DE

P R E M I E R M I N I S T R E

Secrtariat gnral Paris, le 9 octobre 2014de la dfenseet de la scurit nationale No DAT-NT-19/ANSSI/SDE/NP

Agence nationale de la scurit Nombre de pages du documentdes systmes dinformation (y compris cette page) : 32

Note technique

Recommandations de scurit concernant lanalysedes flux HTTPS

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. Ilconstitue 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 consquentdiffusable 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 queces informations puissent tre reprises sans adaptation sur les systmes dinformation cibles.Dans tous les cas, la pertinence de limplmentation des lments proposs par lANSSI doittre soumise, au pralable, la validation de ladministrateur du systme et/ou des personnesen charge de la scurit des systmes dinformation.

Personnes ayant contribu la rdaction de ce document:

Contributeurs Rdig par Approuv par DateLRP, LAM, BAI,MRR BSS SDE

9 octobre 2014

volutions du document :

Version Date Nature des modifications

1.0 1er octobre 2014 Version initiale

1.1 9 octobre 2014 Corrections mineures

Pour toute remarque:

Contact Adresse @ml Tlphone

Bureau Communicationde lANSSI

51 bd de LaTour-Maubourg75700 Paris Cedex

07 SP

[email protected] 01 71 75 84 04

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

http://www.ssi.gouv.fr/fr/bonnes-pratiques/recommandations-et-guides/www.etalab.gouv.fr

Table des matires

1 Prambule 3

2 Gnralits 4

2.1 Rappels sur TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Implmentation de TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Rfrentiel Gnral de Scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Protection des cls prives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Validit des certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Traitement des flux HTTPS sortants 8

3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Traitement des flux HTTPS par dchiffrement . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.1 Les enjeux du dchiffrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.1.1 Gnration des certificats . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1.2 Impact sur les performances . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.2 Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2.1 Gnration des certificats . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2.2 Renforcement de la scurit de TLS . . . . . . . . . . . . . . . . . . . 133.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Traitement des flux HTTPS par dchiffrement . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.1 Les enjeux du dchiffrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.2 Bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.2.1 Gnration des certificats . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.2.2 Scurit TLS entre le reverse proxy et Internet (les clients) . . . . . . 214.2.2.3 Scurit du trafic interne (entre le reverse proxy et le serveur web) . . 224.2.2.4 Propagation de lidentit des clients . . . . . . . . . . . . . . . . . . . 22

4.3 Traitement des flux HTTPS sans dchiffrement . . . . . . . . . . . . . . . . . . . . . . 234.4 Scurit web complmentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Validation des configurations 25

Annexes 26

A Aspects juridiques 26

B Suites cryptographiques acceptables 31


1 PrambuleLe 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 protgeren confidentialit et en intgrit des communications de bout en bout (entre un client et un serveur). Ilapporte 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 exigencesde scurit complmentaires visant inspecter le contenu des changes. Lanalyse dun contenu (webpar exemple) scuris laide de TLS, peut toutefois se justifier afin de sassurer que les donnesprovenant dun rseau non matris (Internet par exemple) ne reprsentent pas une menace pour lesystme dinformation interne. Les architectures visant dchiffrer les flux TLS, pour permettre leuranalyse, 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 ncessairede disposer, entre autres, dun niveau de connaissance suffisant dans les deux domaines spcifiques etvolutifs que sont les IGC 3 et la cryptographie. Quel que soit le contexte, la mise en place demcanismes 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 niveaude lquipement en charge de lopration. Lorsquun tel dchiffrement est ncessaire, samise en uvre doit saccompagner de beaucoup de prcautions et se faire uniquementaprs validation de la direction des systmes dinformation voire dune autorit de niveausuprieur.

Cette note prsente donc les recommandations dordre technique suivre lorsque lanalyse des fluxHTTPS 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 HTTPSsont dchiffrs aprs avoir t initis par des clients prsents sur le systme dinformation en directiondes sites web externes. Le second, plus frquent, prsente le cas o des clients externes souhaitent seconnecter laide du protocole HTTPS des sites web hbergs au sein dun systme dinformationmatris. Ce document na pas pour objectif de dcrire nouveau en dtail le fonctionnement duprotocole TLS ; la publication intitule SSL/TLS : tat des lieux et recommandations 4 disponiblesur le site de lANSSI prsente ce protocole et les problmatiques associes. Par contre, certains aspectsjuridiques 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.


http://www.ssi.gouv.fr/IMG/pdf/SSL_TLS_etat_des_lieux_et_recommandations.pdfhttp://www.ssi.gouv.fr/IMG/pdf/SSL_TLS_etat_des_lieux_et_recommandations.pdf

2 Gnralits2.1 Rappels sur TLS

Voici un rsum de la squence permettant ltablissement dun tunnel TLS. Ce schma illustre uncas classique 5 ; il a pour principal objectif de faire apparatre les lments ncessaires la comprhensionde 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).


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 cesextensions).

3. le serveur envoie ensuite un message de type Server Certificate au client en lui fournissant soncertificat 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 termincette 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 KeyExchange ; celui-ci contient le Pre-master Secret chiffr laide de la cl publique du serveur. Cesecret sera utilis par les deux parties pour gnrer le Master Secret qui permet dobtenir pardrivation les cls de session utilises pour scuriser les donnes changes aprs ltablissementdu 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 donnesque 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 donnesque 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 duprotocole 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 desession utilises pour protger les communications TLS dpend de la cl prive du serveur TLS. Eneffet, si cette dernire est compromise par un attaquant, qui aurait galement captur le trafic TLS, ilsera 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 sessionTLS doit permettre la PFS (Perfect Forward Secrecy). Cette proprit permet de gnrer des cls desession sans que la confidentialit de celles-ci ne dpende de la cl prive du serveur, cette dernire nestalors 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 aupralable, mais la cl peut nanmoins tre utilise pour usurper lidentit du serveur (attaque activedite de lhomme du milieu ) dans le but de dchiffrer le trafic futur. Les suites cryptographiques quipermettent la PFS reposent sur un change de cls de type Diffie-Hellman phmre (DHE ou ECDHEfigure dans le nom de la suite au format IANA 7) et utilisent un autre algorithme de signature (RSApar exemple) pour raliser lauthentification des parties.

7. Internet Assigned Numbers Authority.


2.2 Implmentation de TLS

Les applicatifs TLS (clients et serveurs) sont gnralement dvelopps partir de bibliothquesTLS existantes. Certaines implmentations comme OpenSSL et NSS sont libres alors que dautres sontpropritaires. 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 unedes versions vulnrables du composant. La prsence dune vulnrabilit au sein dune bibliothque TLSpeut 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 jugesimportantes.

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 autoritsadministratives et entre autorits administratives. Au-del de son primtre dapplicabilit strict, leRGS fournit des recommandations et des mtriques qui font rfrence et qui sont utilisables dans uncontexte plus large. Deux annexes composant le RGS sont particulirement pertinentes lorsquil sagitde 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 estcompose dun couple certificat/cl prive. Le niveau de scurit dun canal TLS dpend donc en partiedes mesures de protection qui sont appliques la cl prive par lquipement qui lhberge. Si cettecl tait compromise par une personne mal intentionne, celle-ci pourrait tre en mesure de dchiffrerdes changes enregistrs avant le vol de la cl (si la PFS nest pas active) ou dusurper lidentit duserveur lgitime aprs le vol. Il est donc primordial de mettre en place des mcanismes de protectionlogiciels 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 composantmatriel 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/.


http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/http://www.ssi.gouv.fr/IMG/pdf/RGS_v-2-0_B1.pdfhttp://www.ssi.gouv.fr/IMG/pdf/RGS_v-2-0_A4.pdfhttp://www.ssi.gouv.fr/fr/produits-et-prestataires/

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 vrificationautomatiques doivent tre mis en place afin de sassurer que les certificats employssont 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 doitassurer une IGC. Lemplacement de la CRL associe une AC doit tre renseign dans le champCRLDP 13 de chaque certificat mis par cette AC ;

OCSP 14 : le protocole OCSP fonctionne en mode client-serveur. Il permet un client de vrifieren 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 trerenseign dans le champ AIA 15 de chaque certificat mis par lAC.

Dautres solutions plus rcentes existent, elles visent essentiellement amliorer lefficacit de cesdeux 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 .


3 Traitement des flux HTTPS sortantsCette 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 sontdestines 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 contrleunique pour pouvoir accder des sites web hbergs sur dautres rseaux. Cest gnralement au niveaude ce type dquipement que sont analyss les flux HTTPS sortants, si la solution de proxy employedispose des fonctionnalits permettant lanalyse de ce type de flux. Un proxy web peut tre positionnde plusieurs faons vis--vis de ses clients ; la description des architectures les plus rpandues dpassele 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 leclient et le serveur web cible. Cela est possible lorsque le proxy peut duper le client en interceptantla connexion TLS quil initie en direction du serveur web cible. Le proxy doit pour cela intgrer unserveur TLS pour pouvoir tre le point de terminaison des sessions HTTPS. Le proxy joue ensuite lerle de client vis--vis du serveur cible avec lequel il tablit un autre tunnel TLS pour scuriser leschanges qui transitent sur Internet. Ce double rle permet ainsi au proxy de disposer du trafic HTTPnon chiffr entre les deux tunnels TLS tablis.

Figure 3 Traitement des flux HTTPS sortants par dchiffrement


Le proxy jouant le rle de serveur TLS pour les clients, il doit sauthentifier auprs de ces derniersen leur prsentant un certificat valide lorsquils initient une connexion HTTPS. Le serveur web cibledevra de la mme faon sauthentifier auprs du proxy en lui prsentant son propre certificat. Une foisles 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 deslments transmis par le serveur externe (certificat, paramtres TLS, etc.) ncessaires ltablissementdu 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 serveurweb cible : contenus inappropris, fichiers malveillants, etc. ;

il est possible de contrler le contenu des donnes changes entre le client et le serveur afin desassurer que les flux HTTPS ne sont pas utiliss pour faire sortir du systme dinformation desdonnes confidentielles. Lanalyse doit tre ralise en limitant autant que possible lexpositiondes 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 lesflux HTTP non scuriss. La journalisation doit tre ralise en accord avec le respect de la vieprive 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 quisouhaitent 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 dialoguepas directement en TLS avec le site web ; il ne reoit donc pas les demandes dauthentificationpar certificat formules par ce dernier. Les sites qui requirent une authentification par certificatdoivent 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 dunavigateur 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 laPFS, etc.). La scurisation des tunnels TLS tablis avec le monde extrieur repose uniquementsur les possibilits offertes par le proxy en tant que client, celui-ci tant potentiellement pluslaxiste 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 changesentre 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 typedquipement devient ainsi trs critique. Sa mise en uvre doit donc tre ralise en respectant lesrecommandations mentionnes dans la suite de ce document.


3.2.1.1 Gnration des certificats

Les certificats prsents par le proxy pour sauthentifier auprs de ses clients sont particuliers. Eneffet, ils sont gnrs spcifiquement pour les besoins de dchiffrement et doivent tre valides vis--visdes clients pour que lopration soit transparente. Mme si ces certificats respectent les rgles prsentesci-dessous ainsi que les recommandations dictes par le RGS, leur existence mme est incompatibleavec 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 systmedinformation) doit tre utilise pour signer les certificats que le proxy prsente sesclients.

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 ilssont associs. Le vol des cls prives associes ces certificats pourrait permettre une personne malintentionne de dchiffrer le trafic HTTPS de clients prsents sur Internet sans que ceux-ci ne puissentsen apercevoir (puisque leur navigateur validerait le certificat sans provoquer derreur). Afin de dtecterces certificats illgitimes , les versions rcentes des navigateurs (les plus rpandus) implmentent desfonctionnalits spcifiques permettant des vrifications avances. Chrome et Firefox intgrent le Cer-tificate Pinning 17. Internet Explorer dispose de SmartScreen Filter 18. Ces fonctionnalits permettentde vrifier que le certificat prsent par un site web est sign par lAC publique quil a dclare commetant celle lgitime pour signer son certificat. Si lAC qui a sign le certificat prsent au client par lesite web ne correspond pas celle dont le navigateur a connaissance pour ce site web, le navigateur peutalerter lutilisateur, voire lui interdire laccs au site (possibilit dattaque active dite de lhommedu milieu ). Lalerte peut mme tre remonte automatiquement la socit qui dite le navigateurafin 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 lusagedAC 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 dchiffrementdes flux HTTPS : en effet, la configuration des postes clients est obligatoire pour que le dchiffrementpuisse seffectuer sans que les navigateurs web ne lvent dalerte de scurit.

noter quil existe dautres mcanismes permettant certains navigateurs de vrifier la lgitimitdes 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 certificatsprsents par le proxy ses clients doit tre place dans le magasin des autorits deconfiance utilis par le navigateur des clients. La confiance accorde cette chanepar le navigateur doit tre limite lauthentification des sites web (si lAC internenest 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.


http://tools.ietf.org/html/draft-ietf-websec-key-pinninghttp://blogs.technet.com/b/pki/http://www.certificate-transparency.org

La prsence de cette chane dans ce magasin va permettre au client de vrifier que le certificatque 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 scuritlorsquil tentera de se connecter au site web cible. Le message indiquera lutilisateur que le certificatprsent est sign par une AC inconnue. Si celui-ci choisit malgr tout daccorder sa confiance cetteautorit 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 lACinterne doit donc tre place au pralable dans le magasin de certificats par une personne disposantdes 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 disposentnormalement 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 ellerespecte 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. Lorsquunnavigateur 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 quidtient lEV certificate. Cela permet dindiquer lutilisateur quil accde un site web qui disposedun niveau de confiance important ; cest--dire qui prsente un certificat qui a t sign par une ACspcifique qui dispose du droit de signer des EV Certificates. Les versions rcentes des navigateurssont en mesure deffectuer cette vrification car ils embarquent directement dans leur code source, defaon statique, les informations relatives aux AC publiques qui ont lautorisation dmettre des EVCertificates 22. Lorsquun proxy dchiffre les flux HTTPS, il prsente lutilisateur un certificat signpar une AC interne qui nest pas reconnue par le navigateur comme tant une autorit en mesure dedlivrer des EV Certificate. Le certificat prsent est bien valide, le navigateur naffiche pas dalertede scurit, mais il ne teinte pas sa barre dadresse en vert. Lutilisateur est ainsi priv dindicationsvisuelles 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 pourmettre des EV Certificate. Pour plus dinformations : http://technet.microsoft.com/en-us/library/dd759060.aspx.


https://cabforum.org/extended-validation/https://cabforum.org/extended-validation/http://technet.microsoft.com/en-us/library/dd759060.aspx

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 correctementpour pouvoir supporter les tunnels TLS de lensemble des clients pour lesquels le trafic HTTPS estdchiffr (en partie ou en totalit).

3.2.2 Bonnes pratiques


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 certificatsprsents par le proxy ses clients.

R7

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

R8

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

R9

Les certificats prsents par le proxy ses clients doivent tre gnrs en utilisantdes gabarits qui respectent les recommandations mentionnes dans les annexes duRGS (se reporter au 2.3).


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 deconfiance, le trafic HTTPS interne doit tre correctement scuris afin dviter toute exposition inutiledes donnes protger. Cela est dautant plus ais mettre en uvre que les deux entits (les clientset 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 versionsde 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) doittre dsactiv au niveau du serveur TLS du proxy car les navigateurs rcents supportent a minimaTLS v1.0.

R11

Le proxy ne doit offrir ses clients que des suites cryptographiques robustes (sereporter 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 TLSavec le client doit tre la plus robuste parmi celles proposes par son navigateur (cette suite nest pasncessairement celle qui a la prfrence du client).

R12

Les suites cryptographiques les plus robustes offertes par le proxy doivent permettrela PFS.

Le renforcement du niveau de scurit de TLS laide de la proprit PFS permet de se prmunircontre 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 quelsmcanismes 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).


http://www.cvedetails.com/cve/CVE-2011-3389http://www.cvedetails.com/cve/CVE-2012-4929http://www.cvedetails.com/cve/CVE-2012-4930http://www.cvedetails.com/cve/CVE-2012-4930

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 ncessairede sassurer que ces informations ne sont pas conserves abusivement par le serveur TLS. Idalementces donnes ne doivent tre stockes quen mmoire et durant un laps de temps dfini, de prfrenceconfigurable.

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 doitdonc tre scuris au maximum afin dviter toute compromission des donnes protger. Cela estdautant 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 webcible :

R15

Le comportement du proxy en tant que client TLS doit tre vrifi afin de sassurerque celui-ci nintroduise pas de faiblesses lors de ltablissement des tunnels TLS. Ilest par exemple ncessaire de valider le fonctionnement du proxy lorsquun serveurlui 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 transitivitles clients 27. Le fonctionnement des mcanismes de rvocation supports par le proxy doivent tretests 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 meilleurniveau de scurit lorsque les sites web visits supportent ces versions rcentes duprotocole.

R17

Les suites cryptographiques supportes par le proxy doivent tre proposes au serveurweb selon un ordre pr-tabli. Les suites les plus robustes (incluant la PFS ) doiventtre 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).


http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/http://www.cvedetails.com/cve/CVE-2009-3555

R19

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

Si un serveur web retient une suite cryptographique trop faible, cela signifie quelle fait partiede celles proposes par le proxy. Ce dernier peut tre amen supporter des suites cryptographiquesqui ne sont pas robustes (au sens RGS du terme) pour des questions de compatibilit. Cependant, leproxy peut tre configur pour interdire lusage de ces suites lorsque le site web demand par le clientappartient une catgorie qui exige un niveau de scurit lev (compatible avec les exigences du RGSpar 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 trevrifie linstallation et doit tre revue de faon rgulire.

Les AC publiques intgres la solution de proxy ont t juges de confiance par lditeur. Ila donc choisi dintgrer les chanes de confiance associes dans le magasin de ses proxys. Cette listenest pas ncessairement la mme que celle prsente dans le magasin des navigateurs web des clientsdu proxy. Il est possible que lquipement accorde sa confiance des autorits qui ont t retires dumagasin des versions rcentes des navigateurs, par exemple suite des incidents de scurit renduspublics. Cest la raison pour laquelle le magasin du proxy doit tre vrifi et maintenu jour par lespersonnes en charge de son exploitation. Il est possible que ce magasin soit modifi lors des mises jourlogicielles du proxy (les notes de version doivent tre consultes pour le vrifier) ou par lintermdiairedun 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 caractrepersonnel au niveau dun proxy :

R22

Ne pas procder au dchiffrement de certains types de sites web identifis commetant 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 prisepar le proxy avant ltablissement complet du tunnel TLS. Plusieurs possibilits existent mais ellesdpendent 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 duproxy.


R23

La journalisation des flux dchiffrs doit tre quivalente celle configure pour lesflux HTTP standards traits par le proxy. Elle ne doit pas permettre denregistrerdavantage 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 etphysiquement pour viter tout accs illgitime aux donnes.

Le proxy peut par exemple transmettre le contenu dchiffr dautres quipements laide duprotocole ICAP 30 qui nest pas ncessairement scuris. Des proxys peuvent galement schanger desdonnes 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 deschanges 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 initialepour obtenir des informations concernant le site web demand. Lorsque les clients accdent un proxyHTTP configur en mode explicite, la premire requte HTTPS utilise la mthode HTTP CONNECTet 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 modedans lequel le proxy est configur.Voici les lments qui circulent en clair et quil est possible danalyser pour obtenir le domaine ou leFQDN du site :

30. Internet Content Adaptation Protocol.31. Full Qualified Domain Name ou nom dhte pleinnement qualifi (ex : www.ssi.gouv.fr).


le champ Common Name, contenu dans le certificat prsent par le serveur, peut contenir unFQDN (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 FQDNdu site web lorsque cette extension est utilise par le navigateur du client. Cette extension estemploye par certains navigateurs pour formuler explicitement, au moment de linitiation dutunnel TLS, le FQDN du site web auquel le client souhaite accder. Si plusieurs sites web sontaccessibles par une mme adresse IP, le serveur web peut, grce ce mcanisme, tre en mesurede prsenter au client le certificat correspondant au site quil cherche joindre.

Linspection du contenu de la squence de ngociation TLS permet galement de vrifier certainsparamtres qui dterminent le niveau de scurit du canal de communication (version de TLS, suitescryptographiques, certificats, etc.). Si certaines exigences ne sont pas satisfaites, le proxy peut choisirdempcher ltablissement du tunnel TLS.


4 Traitement des flux HTTPS entrantsCette 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 ausein dun systme dinformation matris .

4.1 Architecture

Lusage de serveurs mandataires inverses HTTP (ou reverse proxy HTTP) est une bonne pratiquedarchitecture permettant de sassurer que lensemble des clients passent par un point de contrle uniquepour pouvoir accder des sites web hbergs sur des rseaux matriss. Cest donc au niveau du reverseproxy que sont gnralement analyss les flux HTTPS entrants, si celui-ci dispose des fonctionnalitspermettant 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, dansce type darchitecture, lquipement en charge de lanalyse ne peut procder au dchiffrement des fluxHTTPS 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 sessionen 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 lesclients et les serveurs.

Ces architectures spcifiques ne seront pas traites dans la suite de ce document, nous considreronsque le traitement des flux HTTPS est ralis par un quipement positionn en coupure des sessionsTLS et qui assure la fonction de reverse proxy.


4.2 Traitement des flux HTTPS par dchiffrement

Ce paragraphe dtaille le cas o le reverse proxy est le point de terminaison des sessions HTTPSinities par les clients qui souhaitent accder au site web hberg en interne. Dans cette configuration lereverse proxy peut ensuite se connecter au serveur web cible en HTTP ou en HTTPS, cela va dpendredes 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, ilest 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 chacundentre eux ;

la protection des cls prives associes aux certificats publics peut tre homogne et peut treplus facilement renforce (usage de HSM par exemple). Celle-ci ne dpend plus des mcanismesde 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 laidedu protocole HTTP par le reverse proxy (se rfrer au 4.2.2.3), ils nont pas excuter lesoprations 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


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

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

4.2.2 Bonnes pratiques


Les certificats prsents aux clients par le reverse proxy doivent tre gnrs partir dune AC dontla 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 prsentaux clients lorsquils cherchent accder au serveur web hberg au sein du systme dinformationinterne. Le choix du PSCE 32 en charge de fournir les certificats publics est un lment structurant quicontribue 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 laslection 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 formulespar 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 sonsrieux : 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/Liste PSCe.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.


http://www.lsti-certification.fr/images/liste_entreprise/Liste PSCe.pdfhttp://www.ssi.gouv.fr/IMG/pdf/2010-12-03_Guide_externalisation.pdfhttp://www.webtrust.org

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 doitdonc tre scuris au maximum afin dviter toute compromission des donnes protger. Cela estdautant 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 lesversions 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 tredsactiv. Par contre, pour des questions de compatibilit, il est encore ncessaire de supporter TLSv1.0. Nanmoins, si cette version est active, il est ncessaire de vrifier que la solution de reverseproxy 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 descurit est acceptable (se reporter lannexe B de ce document). Il doit slectionneren priorit les suites les plus robustes (incluant la PFS ) parmi celles proposes parle 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 dterminerquels 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 ltatdes 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 desassurer que ces informations ne sont pas conserves abusivement par le reverse proxy. Idalementces donnes ne doivent tre stockes quen mmoire et durant un laps de temps dfini, de prfrenceconfigurable.

R33

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

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


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 serveurweb interne :

1. le protocole HTTPS peut tre utilis par le reverse proxy pour accder au serveur web. Dans cecas, 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. Lescertificats prsents sur le serveur web doivent tre signs par une AC non publique. Seul lereverse proxy aura connaissance de ces certificats. Il ne sera jamais visible par les clients (quinont connaissance que des certificats prsents par le reverse proxy). Le reverse proxy doitgalement disposer dans son magasin de la chane de confiance associe lAC interne pourvalider 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 dedonnes qui sont protges lorsquelles circulent sur Internet ;

du besoin en intgrit : il est ncessaire de dterminer si la contrainte en intgrit est forte surles donnes. Par exemple, lorsque le reverse proxy transmet au serveur web cible des informationsrelatives 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 supporterles oprations cryptographiques ncessaires ltablissement et au maintien de sessions HTTPS ;

du cot dexploitation : lemploi du procotole HTTPS au niveau des serveurs web implique lagestion 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 dureverse proxy (usage de certificats clients par exemple) pose la problmatique de la propagation desinformations didentification jusquau site web cible. En effet, le reverse proxy doit tre en mesurede 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 lesen-ttes HTTP les informations relatives lidentit des utilisateurs authentifis. Le contenu de cesen-ttes est ensuite pris en compte par le site web cible qui peut ainsi diffrencier ses traitements enfonction des informations didentification quil reoit.

Lajout dinformations dans les en-ttes HTTP par un reverse proxy nest pas un mcanisme utilisexclusivement pour propager des informations didentification, il peut par exemple tre employ pourtransmettre 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 risquesi 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 reoitdes clients et doit procder leur nettoyage si ncessaire.


Attention : Lacceptation du client ne doit pas se baser uniquement sur la validit des informationsdauthentification 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 galementpermettre de vrifier que lutilisateur dispose des droits daccs au site web demand, charge au reverseproxy 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 sessionsHTTPS inities par les clients qui souhaient accder au site web hberg sur le systme dinformationinterne. Dans cette configuration, le reverse proxy ne fait que transfrer les donnes chiffres entre leclient 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 nepermet pas au reverse proxy daccder au contenu HTTP. Ce dernier peut simplement sassurer que lesserveurs web internes tablissent les tunnels TLS en respectant les exigences de scurit auxquelles ilssont normalement assujettis (suites cryptographiques, version de TLS, etc.). Ce type de configurationoblige galement les serveurs web hberger leurs cls prives accompagnes de leurs certificats signspar 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 ceprotocole nest pas suffisant. Dautres mesures complmentaires doivent tre mises en uvre au niveaudes serveurs web pour ne pas exposer les informations protger.

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

R34

Ne pas activer le protocole de compression HTTP nomm SPDY 36 lorsquun siteweb 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 contenuHTTP.


lors de lemploi combin du protocole HTTPS et de SPDY.

R35

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

Le fait dinclure du contenu non scuris dans une page accessible laide du protocole HTTPSrend vulnrable le site web des attaques actives dites de lhomme du milieu ralises laidede scripts malveillants. Certains navigateurs alertent lutilisateur lorsque des contenus de diffrentesnatures 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 duprotocole HTTPS. Cela vite son envoi sans protection. Lattribut HttpOnly interdit laccs au cookiepar 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 etdu 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 descontenus (image, script, etc.) inclus dans une page. Cela permet de se prmunir contre les attaquesde 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 protocoleHTTPS 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.


http://www.ssi.gouv.fr/IMG/pdf/NP_Securite_Web_NoteTech.pdfhttps://developer.mozilla.org/en-US/docs/Security/MixedContenthttp://www.ssi.gouv.fr/IMG/pdf/NP_Securite_Web_NoteTech.pdf

5 Validation des configurations

La configuration TLS dun proxy ou dun reverse proxy doit tre valide afin de sassurer quecelle-ci est correctement scurise. Elle peut tre teste laide doutils, voire de services, spcifiquesdisponibles 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. Cetoutil offre des fonctionnalits tendues permettant dinterroger un serveur TLS et dinvestigueren dtail dventuels problmes de configuration. TLS v1.2 nest support qu partir de la version1.0.1 dOpenSSL ;

SSLScan : cet outil repose sur OpenSSL. Il permet de tester un service SSL/TLS et offre enparticulier la possibilit de lister les suites cryptographiques supportes par le serveur. noterque 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.2nest 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 solutionsde scurit Qualys) met disposition gratuitement de nombreuses ressources concernant TLS (bonnespratiques, tableaux de bord, etc.). Il fournit en particulier des services permettant dvaluer en lignela 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.


https: //www.ssllabs.comhttp://www.openssl.orghttps://github.com/dinotools/sslscanhttps://github.com/isecpartners/sslyze

Annexes

A Aspects juridiques

Cette annexe prsente les aspects juridiques lis au dchiffrement de flux dans un but informatif etde manire non-exhaustive. En particulier, elle se limite aux problmatiques lies aux flux entrants etsortants 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 enamont. 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 jeude 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 lechiffrement.

Le chiffrement tant reli une technologie laquelle peuvent correspondre plusieurs usages, la prsentenote se limite au fait quil rpond au seul besoin de garantir la confidentialit des changes de donneslectroniques, 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 unrgime juridique particulier, elle nen est pas moins susceptible dentraner un risque non ngligeablede mise en cause de la responsabilit de lentit qui en bnficie, et ce sur plusieurs fondements. Pourse prserver, lemployeur peut effectivement tre amen mettre en place un systme de dchiffrementet de contrle des changes dinformation raliss par ses salaris sur les systmes dinformation quilmet leur disposition qui, sil nest pas strictement encadr, peut conduire lemployeur engager saresponsabilit sur dautres fondements.

Le rgime juridique du chiffrement

Lutilisation des moyens de cryptologie est libre en France 46. En revanche, la fourniture, le transfertdepuis ou vers un tat membre de la Communaut europenne ainsi que limportation et lexportationde ces moyens sont rglements lorsquils nassurent pas exclusivement des fonctions dauthentificationou 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 delANSSI 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 etpnal 48.

46. Loi n 2004-575 du 21 juin 2004 pour la confiance dans lconomie numrique (LCEN), art. 30 ; dcret n 2007-663du 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 danslconomie 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


http://www.ssi.gouv.fr/fr/reglementation-ssi/cryptologie/

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-respectdes obligations de scurit sa charge. Les fondements sont multiples, savoir :

selon larticle 1384 alina 5 du Code civil, lemployeur est responsable de lagissement de sessalaris 49 notamment sur les rseaux informatiques 50. Un employeur peut tre tenu responsablesi 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 deces 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 considrcomme 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 auxobligations de scurit et de notification de la violation des donnes caractre personnel imposespar la loi Informatique et Liberts 54 ;

le titulaire dun accs des services de communications au public en ligne est responsable de lascurisation 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 delemployeur ds lors quelle est libre.En revanche, sa responsabilit peut tre engage soit : en raison dagissements dlictueux qui pourraient tre commis par les salaris grceaux moyens quil leur a fournis (matriels, accs internet, etc.) et dissimuls grce auchiffrement ;

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 raisondes risques juridiques lis au dchiffrement.

la confiscation, la fermeture dtablissement et lexclusion des marchs publics peuvent tre appliques. Dans ce derniercas, les articles 35, 36 et 37 de la LCEN prvoient notamment un an demprisonnement et 15.000 euros damende en casde non dclaration ou de communication dinformations et jusqu deux ans demprisonnement et 30.000 euros damendeen 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 pagespersonnelles.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 musicauxsur 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.pdf54. Articles 34 et 34 bis de la loi n78-17 du 6 janvier 1978 relative linformatique, aux fichiers et aux liberts.


http://www.ssi.gouv.fr/IMG/pdf/NP_Journalisation_NoteTech.pdfhttp://www.ssi.gouv.fr/IMG/pdf/NP_Journalisation_NoteTech.pdfhttp://www.ssi.gouv.fr/IMG/pdf/NP_Journalisation_NoteTech.pdf

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 obligationlgale de dchiffrement dans le cadre des interceptions judiciaires, les articles L 241-1 L 245-3 ducode de la scurit intrieure dans le cadre des interceptions de scurit et larticle 230-1 du code deprocdure pnale dans le cadre dune enqute ou dune instruction 55.

En dehors de ces hypothses, le dchiffrement dun flux chiffr, en particulier lorsquil concerne lasphre 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 scientifiqueet 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 lessystmes dinformation (sous-traitance, audit des systmes dcouvrant des vulnrabilits contenant desdonnes 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 engagerla responsabilit de lemployeur qui naurait pas prvu les mesures destines prservercelles-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 dinvestigationqui 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 dela nation et par larrt du Premier ministre du 3 juillet 2012 relatif la protection du potentiel scientifique et techniquede 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 primordialdencadrer le contenu des contrats des sous-traitants et surtout le primtre de leurs interventions pour ne pas risquerde contrevenir aux lgislations prcises dans la note. En outre, la mise en place de procdures de contrle internespour viter toute ingrence dun sous-traitant est recommande (sous-traitant en charge de dchiffrer les contenus, parexemple, qui devra respecter les obligations mises la charge dun administrateur.).


Encadrement juridique du dchiffrement

Gnralits

La mise en place par une entit dun mcanisme de dchiffrement des flux doit saccompagner durespect des principes gnraux suivants 62 :

transparence et loyaut de lemployeur vis--vis de ses salaris en les informant sur la nature desmesures informatiques prises sur le rseau informatique de lentit et en recueillant leur consen-tement individuel sur la charte informatique ainsi quen consultant les instances reprsentativesdu personnel 63 ;

ncessit et proportionnalit 64 de la mise en place dun outil de dchiffrement par rapport auxfinalits annonces par lemployeur (telles la scurit du rseau, la protection des donnes sensiblesde lentit) qui imposent que les mesures prises soient justifies par la nature de la tche etproportionnes la finalit ;

la protection des donnes caractre personnel et notamment la vrification que les formalitsaccomplies auprs de la Commission nationale de linformatique et des liberts (CNIL) couvrentles traitements et les donnes opres par de tels mcanismes ;

le contrle de laccs aux outils de dchiffrement (logiciels de dchiffrement, cls de chiffrementdes matriels ou des utilisateurs) en particulier lorsquune mauvaise utilisation peut engagerla responsabilit dun tiers (salari notamment). Les accs aux cls de chiffrement notammentlorsquil sagit dun accs au squestre des cls des utilisateurs doivent tre journaliss et treprvu dans la charte informatique de lentit.

Le dchiffrement ne doit pas tre mis en place sans avoir satisfait des formalits lgales etsans 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 matirede dchiffrement

Ladministrateur a pour mission dassurer le fonctionnement normal et la scurit des rseaux etsystmes 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 dansle cadre de ses fonctions.

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

62. Ces principes gnraux sont les principes retenus dans les jurisprudences relatives au droit du travail et dontlapprciation 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 messagerieset leur contenu [. . . ]. Par contre, la divulgation du contenu des messages, et notamment du dernier qui concernait leconflit 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.


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 ycompris 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 restantsoumis une obligation de confidentialit.

En conclusion, la mise en place dun dispositif de dchiffrement par lentit doit treencadre juridiquement : par la charte dutilisation des moyens informatiques et de communications lectroniquesrdige par lemployeur et annexe au rglement intrieur de lentit, aprs consultationdes instances reprsentatives du personnel. Celle-ci devra prvoir, notamment, les rglesdutilisation des moyens mis disposition par lemployeur, les modalits daccs auxdonnes et aux quipements, lhypothse, les sanctions en cas de non-respect, etc. ;

par la mise en place dun administrateur expressment autoris accder aux contenusdchiffrs 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 envisagercette hypothse, et ventuellement le cas des sous-traitants ;

par les dclarations adaptes la CNIL en considrant avec soin les finalits pourlesquelles le dchiffrement est envisag.

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


B Suites cryptographiques acceptables

Lensemble des suites cryptographiques quil est possible demployer avec TLS sont rfrences surle site de lIANA 69. Il en existe plus de 300.

Chaque suite cryptographique est identifie par un code hexadcimal ainsi que par une descriptionqui 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 uniquementsur les exigences listes dans le RGS. Cela conduit en effet la dfinition dune liste trs rduite nepermettant pas dassurer une compatibilit suffisante pour pouvoir tre utilise dans un environnementde 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 lattaqueBEAST 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.


http://iana.org/assignments/tls-parameters/tls-parameters.xhtmlhttp://www.cvedetails.com/cve/CVE-2011-3389

PrambuleGnralitsRappels sur TLSImplmentation de TLSRfrentiel Gnral de ScuritProtection des cls privesValidit des certificats

Traitement des flux HTTPS sortantsArchitectureTraitement des flux HTTPS par dchiffrementLes enjeux du dchiffrementGnration des certificatsImpact sur les performances

Bonnes pratiquesGnration des certificatsRenforcement de la scurit de TLSProtection de la vie prive

Traitement des flux HTTPS sans dchiffrement

Traitement des flux HTTPS entrantsArchitectureTraitement des flux HTTPS par dchiffrementLes enjeux du dchiffrementBonnes pratiquesGnration des certificatsScurit TLS entre le reverse proxy et Internet (les clients)Scurit du trafic interne (entre le reverse proxy et le serveur web)Propagation de l'identit des clients

Traitement des flux HTTPS sans dchiffrementScurit web complmentaire

Validation des configurationsAnnexesAspects juridiquesSuites cryptographiques acceptables

premier ministre - ssi.gouv.fr · publicvisé: développeur x administrateur x rssi x dsi x...

Documents