----

-title: 'Confidentialité, intégrité et disponibilité'

-slug: Apprendre/Confidentialité_intégrité_et_disponibilité

-tags:

- - Beginner

- - Security

- - Tutorial

-translation_of: 'Archive/Security/Confidentiality,_Integrity,_and_Availability'

----

-<div>{{IncludeSubnav("/fr/Apprendre")}}</div>

-<div class="summary">

-<p>Cet article aborde les objectifs majeurs qu'on retrouve en sécurité : la confidentialité, l'intégrité et la disponibilité.</p>

-</div>

-

-<table class="learn-box standard-table">

- <tbody>

- <tr>

- <th scope="row">Prérequis :</th>

- <td>Il n'y a pas de prérequis pour cet article.</td>

- </tr>

- <tr>

- <th scope="row">Objectifs :</th>

- <td>Vous apprendrez les concepts de confidentialité, d'intégrité et de disponibilité et comment ceux-ci peuvent affecter les données et les systèmes.</td>

- </tr>

- </tbody>

-</table>

-

-<p>En sécurité de l'information, le modèle classique définit trois objectifs : maintenir la confidentialité, l'intégrité et la disponibilité des données. Chacun de ces objectifs porte sur un aspect différent de protection des informations.</p>

-

-<h2 id="Pédagogie_active">Pédagogie active</h2>

-

-<p><em>Il n'y a, pour le moment, pas d'éléments de pédagogie active pour cette section. <a href="/fr/docs/MDN/D%C3%A9buter_sur_MDN">Vous pouvez néanmoins contribuer</a>.</em></p>

-

-<h2 id="Aller_plus_loin">Aller plus loin</h2>

-

-<h3 id="La_confidentialité">La confidentialité</h3>

-

-<p><em>La confidentialité</em> correspond à la protection des informations afin que celles-ci ne soient pas accessibles pour des personnes ou entités non-autorisées. Autrement dit, seules les personnes autorisées doivent pouvoir accéder aux données sensibles. Prenons par exemple les données de votre compte bancaire. Vous devriez pouvoir y accéder, cela ne fait aucun doute, les employés de la banque qui traitent avec vous ont également besoin d'y accéder mais en dehors de ces personnes, nul autre ne devrait pouvoir y accéder. Échouer à conserver cettte confidentialité signifie que quelqu'un qui n'aurait pas du accéder aux données a réussi à le faire. Cet accès peut avoir été accidentel ou intentionnel. Un tel échec est généralement appelé « faille » ou « brêche » et, généralement, il n'existe pas de solution pour empêcher à l'intrus de consulter les données auxquelles il a eu accès. Une fois qu'un secret a été révélé, il n'est plus possible de le cacher à nouveau. Si les informations de votre compte en banque sont publiées sur un site web public, tout le monde pourra avoir accès à ces données et il sera impossible d'effacer ce qui aura été consulté de la mémoire des personnes, de notes écrites, de captures d'écrans… De nos jours, la plupart des incidents de sécurités rapportés dans les médias sont dus à des échecs en termes de confidentialité.</p>

-

-<p>Pour résumer, une faille dans la confidentialité signifique que quelqu'un a eu accès à des informations alors qu'il n'aurait pas du pouvoir y accéder.</p>

-

-<h3 id="L'intégrité">L'intégrité</h3>

-

-<p><em>L'intégrité</em> correspond au fait de s'assurer de l'authenticité des informations auxquelles on accède :  les informations ne doivent pas avoir été modifiées et doivent provenir d'une source sûre. Prenons l'exemple d'un site web sur lequel vous vendez des produits. Si un attaquant peut acheter des produits sur votre site et modifier les prix des produits, il pourra acheter n'importe quoi à n'importe quel prix. Il y aurait donc une faille d'intégrité car les informations (ici le prix d'un produit) ont été modifiées sans votre autorisation. Un autre scénario où on peut observer une telle faille d'intégrité peut être le suivant : vous essayez de vous connecter à un site web et un attaquant malveillant intercepte les communications entre vous et le « vrai » site pour vous rediriger vers un autre site web. Dans ce cas, c'est la source d'information qui n'est pas sûre et c'est pour cette raison qu'on a une faille d'intégrité.</p>

-

-<h3 id="La_disponibilité">La disponibilité</h3>

-

-<p><em>La disponibilité</em> signifie que les informations peuvent être consultées par les utilisateurs autorisés.</p>

-

-<h2 id="Prochaines_étapes">Prochaines étapes</h2>

-

-<ul>

- <li><a href="/fr/Apprendre/Vulnérabilités">Les vulnérabilités</a></li>

-</ul>

----

-title: Contrôles de sécurité

-slug: Apprendre/Contrôles_de_sécurité

-tags:

- - Beginner

- - Security

- - Tutorial

-translation_of: Archive/Security/Controls

----

-<p>{{draft}}</p>

-

-<div class="summary">

-<p>Cet article aborde les contrôles de sécurité : leurs différentes catégories, pourquoi ils sont toujours pertinents ainsi que leurs différentes faiblesses.</p>

-</div>

-

-<table class="learn-box standard-table">

- <tbody>

- <tr>

- <th scope="row">Prérequis :</th>

- <td>Vous devez au préalable connaître <a href="/fr/Apprendre/Confidentialité_intégrité_et_disponibilité">les objectifs majeurs en termes de sécurité</a>, <a href="/fr/Apprendre/Les_vulnérabilités">ce qu'est une vulnérabilité</a> et <a href="/fr/Apprendre/Les_menaces">ce qu'est une menace</a>.</td>

- </tr>

- <tr>

- <th scope="row">Objectifs :</th>

- <td>Apprendre ce qu'est un contrôle de sécurité et comment une combinaison de contrôles de sécurité permet de protéger des données et des systèmes.</td>

- </tr>

- </tbody>

-</table>

-

-<p>Les données sensibles doivent être protégées afin qu'elles ne souffrent pas d'un défaut de confidentialité, d'integrité ou de disponibilité. Les mesures de protection (aussi appelées « contrôles de sécurité ») se distinguent en deux catégories. Tout d'abord, les faiblesses d'un système doivent être corrigées. Si un système possède une faille connue qu'un attaquant peut exploiter, le système doit être mis à jour afin que la vulnérabilité soit retirée ou réduite. Ensuite, le système ne doit offrir que les fonctionnalités nécessaires à chaque utilisateur autorisé, personne ne doit pouvoir utiliser des fonctionnalités dont il n'a pas besoin. C'est ce qu'on appelle <em>les moindres privilèges</em>.  Limiter les fonctionnalités accessibles et résoudre les failles connues visent un même but : fournir le minimum de chances à un attaquant pour entrer dans un système.</p>

-

-<h2 id="Pédagogie_active">Pédagogie active</h2>

-

-<p><em>Il n'y a pas encore de matériau interactif pour cet article. <a href="/fr/docs/MDN/Débuter_sur_MDN">N'hésitez pas à contribuer</a>.</em></p>

-

-<h2 id="Aller_plus_loin">Aller plus loin</h2>

-

-<p>Il existe trois types de contrôles de sécurité :</p>

-

-<ul>

- <li><em>Les contrôles de gestion </em>: Ces contrôles portent sur la gestion du risque et sur la gestion de la sécurité du système d'informations.</li>

- <li><em>Les contrôles opérationnels </em>: ces contrôles sont implémentés et utilisés par les personnes (et non par les systèmes).</li>

- <li><em>Les contrôles techniques </em>: ces contrôles sont principalement implémentés et utilisés par les systèmes (matériels ou logiciels).</li>

-</ul>

-

-<p>Ces trois types de contrôles sont nécessaires afin d'obtenir une sécurité robuste. Ainsi, une règle de sécurité relève d'un contrôle de gestion mais est implémentée par des personnes (contrôle opérationnel) et des systèmes (contrôle technique). Prenons l'exemple du hameçonnage. Une entreprise peut décider d'avoir des règles afin que les utilisateurs ne visitent pas de sites web malveillants. Les contrôles de sécurité contre le hameçonnage incluent : des contrôles de gestion pour définir la règle à suivre, des contrôles techniques pour surveiller le contenu des <em>e-mails</em> et des sites web visités et des contrôles opérationnels en formant les utilisateurs afin que ceux-ci réalisent quand ils font face à une tentative de hameçonnage.</p>

-

-<p>La mise en place de contrôles de sécurité a généralement un inconvénient : les systèmes soumis aux contrôles sont moins pratiques voire plus difficiles à utiliser. Lorsque l'utilisabilité pose problème, de nombreux utilisateurs contourneront les contrôles de sécurité. Par exemple, si les mots de passe doivent être longs et complexes, les utilisateurs pourraient être amenés à les écrire sur des notes. Trouver le bon équilibre entre sécurité, utilisabilité et fonctionnalité est un défi complexe à relever mais qu'il est nécessaire de résoudre convenablement.</p>

-

-<p>Un autre principe fondamental des contrôles de sécurité consiste à utiliser plusieurs couches de sécurité. Des données sensibles peuvent par exemple être stockées sur un serveur protégé par différents contrôles : un pare-feu réseau, un pare-feu interne et des correctifs liés au système d'exploitation. Avoir plusieurs couches de sécurité permet de  parer au cas où une couche ne fonctionne pas ou ne permet pas de contrevenir à une menace donnée. Généralement, c'est une bonne idée que d'utiliser une combinaison de contre-mesures entre le réseau et le serveur et de contre-mesures internes au serveur.</p>

----

-title: Threats

-slug: Apprendre/Les_menaces

-tags:

- - Beginner

- - Learn

- - Security

- - Tutorial

-translation_of: Archive/Security/Threats

----

-<p>{{draft}}</p>

-

-<div class="summary">

-<p>Cet article aborde les menaces en sécurité informatique, il explique ce qu'elles sont et comment elles peuvent affecter le trafic réseau.</p>

-</div>

-

-<table class="learn-box standard-table">

- <tbody>

- <tr>

- <th scope="row">Prérequis :</th>

- <td>Vous devez au préalable connaître <a href="/en-US/Learn/Confidentiality,_Integrity,_and_Availability">les objectifs majeurs en termes de sécurité</a> et savoir <a href="/en-US/Learn/Vulnerabilities">ce qu'est une vulnérabilité</a>.</td>

- </tr>

- <tr>

- <th scope="row">Objectifs :</th>

- <td>Apprendre ce qu'est une menace au sens informatique et comment les menaces peuvent affecter le trafic réseau.</td>

- </tr>

- </tbody>

-</table>

-

-<p>Une<em> menace</em> correspond à toute circonstance ou événement qui peut impacter négativement des données ou des systèmes à cause d'un accès non-autorisé, d'une destruction (partielle ou totale), d'une divulgation ou de la modification d'informations. Cela peut aussi être un déni de service. Les menaces peuvent impliquer des acteurs intentionnels (par exemple un attaquant qui souhaite accéder à des informations sur un serveur) ou accidentels  (par exemple un administrateur qui oublie de désactiver le compte d'un ancien employé).  Les menaces peuvent être locales (un employé mécontent par exemple) ou éloignées (un attaquant à distance sur un autre continent).</p>

-

-<h2 id="Pédagogie_active" style="margin: 0px 0px 12px; padding: 0px; border: 0px; font-weight: 700; font-family: 'Open Sans', sans-serif; line-height: 30px; font-size: 2.14285714285714rem; letter-spacing: -1px; color: rgb(77, 78, 83); font-style: normal; font-variant: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; background-color: rgb(255, 255, 255);">Pédagogie active</h2>

-

-<p style="margin: 0px 0px 24px; padding: 0px; border: 0px; color: rgb(77, 78, 83); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 21px; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; background-color: rgb(255, 255, 255);"><em>Il n'existe pas encore de matériau interactif pour cet article. <a href="/fr/docs/MDN/Débuter_sur_MDN" style="margin: 0px; padding: 0px; border: 0px; color: rgb(0, 149, 221); text-decoration: none;">N'hésitez pas à contribuer</a>.</em></p>

-

-<h2 id="Aller_plus_loin">Aller plus loin</h2>

-

-<p><em>La source d'une menace</em> est la cause d'une menace : cela peut être une attaque physique ou informatique, une erreur humaine, un dysfonctionnement d'un matériel ou d'un logiciel de l'entreprise ou un dysfonctionnement extérieur à l'entreprise.<em> Un événement de menace</em> correspond à un événement ou a une situation initiée ou causée par la source et qui peut potentiellement entraîner un impact dommageable.</p>

-

-<p>De nombreuses menaces sont rendues possibles à causes d'erreurs : des bugs dans des systèmes d'exploitation ou dans des applications ou encore des erreurs causées par les acteurs humains qui utilisent les systèmes.</p>

-

-<p>Le trafic réseau transite par de nombreux ordinateurs intermédiaires : des routeurs, d'autres réseaux non sécurisés comme des points d'accés WiFi. Pour ces raisons, le trafic réseau peut parfois être intercepté par un tiers. Les menaces qui visent le trafic réseau peuvent prendre l'une des formes suivantes :</p>

-

-<ul>

- <li><strong>La mise sur écoute.</strong> Les informations qui passent sur le réseau restent intactes mais la confidentialité est compromise. Quelqu'un pourrait par exemple découvrir votre numéro de carte bleue, enregistrer des conversations importantes ou intercepter des informations confidentielles.</li>

- <li><strong>La falsification.</strong> Les informations qui passent sur le réseau sont modifiées ou remplacées avant d'être envoyées au destinataire. Quelqu'un pourrait par exemple modifier une commande passée en ligne ou altérer le CV d'une personne.</li>

- <li><strong>Le mensonge d'identité. </strong>Les informations sont envoyées à une personne qui se fait passer pour le destinataire légitime. Cela peut se décliner de deux façons différentes :

- <ul>

- <li><strong>L'imposture (<em>spoofing</em>).</strong> Une personne prétend en être une autre. Par exemple, une personne prétend avoir l'adresse <code>jbiche@exemple.fr</code> ou un ordinateur prétend avoir un site intitulé <code>www.exemple.fr</code> alors que ce n'est pas vrai.</li>

- <li><strong>Le détournement.</strong> Une personne ou une organisation prétend fournir un service qu'elle ne fournit pas malgré la présentation. Par exemple, le site <code>www.exemple.fr</code> prétend être un site de vente de mobiliers alors qu'il ne fait qu'enregistrer les paiements mais n'envoie jamais aucun meuble.</li>

- </ul>

- </li>

-</ul>

-

-<h2 id="Prochaines_étapes">Prochaines étapes</h2>

-

-<ul>

- <li><a href="/en-US/Learn/Security_Controls">Les contrôles de sécurité</a></li>

-</ul>

----

-title: Les vulnérabilités

-slug: Apprendre/Les_vulnérabilités

-tags:

- - Beginner

- - Learn

- - Security

-translation_of: Archive/Security/Vulnerabilities

----

-<p>{{draft}}</p>

-

-<div class="summary">

-<p>Dans cet article, nous abordons les vulnérabilités : ce qu'elles sont et pourquoi elles sont présentes dans chaque système.</p>

-</div>

-

-<table class="learn-box standard-table">

- <tbody>

- <tr>

- <th scope="row">Prérequis :</th>

- <td>Vous devriez connaître au préalable <a href="/fr/Apprendre/Confidentialité_intégrité_et_disponibilité">les trois objectifs majeurs de la sécurité</a>.</td>

- </tr>

- <tr>

- <th scope="row">Objectifs :</th>

- <td>Apprendre ce qu'est une vulnérabilité et comment elle peut affecter des données et/ou des systèmes.</td>

- </tr>

- </tbody>

-</table>

-

-<p>Une vulnérabilité est une faiblesse d'un système qui peut être exploitée de façon négative pour compromettre la confidentialité, l'intégrité ou la disponibilité d'un système et/ou de des données. Il existe de nombreuses méthodes pour catégoriser les vulnérabilités. Dans cet article, nous les classerons dans trois grands groupes : les erreurs logicielles, les erreurs de configuration des systèmes de sécurité et la mauvaise utilisation d'une fonctionnalité d'un logiciel. Ces catégories sont décrites ci-après.</p>

-

-<h2 id="Pédagogie_active">Pédagogie active</h2>

-

-<p><em>Il n'y a, pour le moment, pas d'élément de pédagogie active pour cette section. <a href="https://developer.mozilla.org/fr/docs/MDN/D%C3%A9buter_sur_MDN">Vous pouvez néanmoins contribuer</a>.</em></p>

-

-<h2 id="Aller_plus_loin">Aller plus loin</h2>

-

-<h3 id="Les_différentes_catégories_de_vulnérabilités">Les différentes catégories de vulnérabilités</h3>

-

-<p><em>Une vulnérabilité liée à une erreur logicielle</em> est causée par une erreur, non-intentionnelle, lors de la conception ou du développement du logiciel. Par exemple, cela peut être une erreur de validation lorsqu'un utilisateur saisit quelque chose à entrer dans le logiciel, dans ce cas, un utilisateur mal-intentionné pourrait concevoir des chaînes de caractères ou des valeurs spécifiques pour attaquer le système. Un autre exemple peut être une <a href="https://fr.wikipedia.org/wiki/Situation_de_comp%C3%A9tition">situation de compétition</a> qui permettrait à un attaquant d'effectuer une action avec des privilèges qu'il n'aurait pas dû avoir.</p>

-

-<p><em>Une vulnérabilité liée à une erreur de configuration des éléments de sécurité</em> est un cas où la sécurité d'un logiciel est compromise à cause du logiciel lui-même. Par exemple, un système d'exploitation peut permettre à un utilisateur de contrôler qui peut accéder à quels fichiers en fonction de ses privilèges, généralement le système d'exploitation fournira donc une application qui permet d'activer ou de désactiver certains privilèges ou certains contrôles. Une vulnérabilité de ce type apparaît quand un des réglages de la configuration impacte négativement la sécurité du logiciel.</p>

-

-<p><em>Une vulnérabilité liée à une mauvaise utilisation d'une fonctionnalité logicielle</em> apparaît quand un logoiciel offre une certaine méthode permettant de compromettre la sécurité d'un système. Ces vulnérabilités proviennent généralement d'une hypothèse de confiance, prise lors du développement du logiciel, qui peut être mise à défaut lors de l'utilisation du logiciel. Par exemple, un client de courrier électronique peut disposer d'une fonctionnalité pour afficher les e-mails qui contiennent du HTML. Un attaquant pourrait donc créer un courrier électronique qui contient des liens qui soient tout à fait « sains » en apparence mais qui redirigent en fait vers un site mal intentionné. Ici, l'hypothèse de confiance consiste à penser qu'avec cette fonctionnalité de rendu HTML, un utilisateur ne recevra pas d'e-mails mal intentionnés ou qu'il ne cliquera pas sur ces liens.</p>

-

-<p>Ces vulnérabilités liées à l'utilisation du logiciel apparaissent lors de la conception du logiciel ou d'un de ses composants. Les hypothèses de confiance peuvent avoir été explicites (par exemple, un concepteur est conscient de telle faiblesse en termes de sécurité et estime qu'une option séparée sera plus efficace). Cependant, la plupart du temps, ces hypothèses sont implicites : créer une fonctionnalité sans évaluer les risques que celle-ci introduit, l'évolution du logiciel ou d'un protocole au cours du temps... Le protocole <em>Address Resolution Protocol</em> (ARP en anglais ou protocole de résolution des adresses) fait par exemple « confiance » au sens où il ne vérifie pas que l'association fourni dans les réponses reçues entre l'adresse <em>Media Access Control</em> (MAC) et l'adresse <em>Internet Protocol</em> (IP). L'ARP garde en cache ces informations pour fournir un service qui permettra aux différents appareils d'un réseau local de s'envoyer des données. Toutefois, un attaquant pourrait générer de faux messages ARP afin d'« empoisonner » les tableaux ARP d'un système et ainsi déclencher un déni de service ou une attaque « de l'homme du milieu ». Le protocole ARP a été standardisé 25 ans auparavant, les menaces ont grandement évolué depuis et c'est pourquoi les hypothèses de confiance sur lesquelles le protocole a été conçu ne seraient plus d'actualité aujourd'hui.</p>

-

-<p>Cela peut s'avérer difficile de différencier les vulnérabilités de ce dernier type au regard des deux premiers. Une faille d'un logiciel et une mauvaise utilisation d'un logiciel peuvent tous les deux provenir d'erreurs lors de la conception du logiciel. Cependant, les failles logicielles ont un impact purement négatif alors que les vulnérabilités liées à la mauvaise utilisation d'un logiciel proviennent de fonctionnalités supplémentaires.</p>

-

-<p>On peut également parfois confondre cette dernière catégorie avec la seconde. La différence principale est qu'une vulnérabilité liée à une mauvaise utilisation du logiciel aura un réglage qui active/désactive une fonctionnalité entière et ne concerne pas uniquement la sécurité. En revanche, pour une vulnérabilité liée à la configuration, un réglage équivalent n'impactera que la sécurité du logiciel. Si on dispose par exemple d'un réglage permettant de désactiver l'affichage HTML des e-mails, cela aura un impact sur la sécurité et sur une fonctionnalité du client mail : une vulnérabilité liée à ce réglage serait donc une vulnérabilité liée à une mauvaise utilisation du logiciel. En revanche, une vulnérabilité liée à un réglage qui permet de désactiver la sécurité anti-hameçonnage (quelque chose qui ne concerne que la sécurité) serait une vulnérabilité liée à un défaut de configuration.</p>

-

-<h3 id="La_présence_de_vulnérabilités">La présence de vulnérabilités</h3>

-

-<p><strong>Aucun système n'est parfaitement sécurisé</strong>. Chaque système possède des vulnérabilités. À un instant donné, un système peut éventuellement être épargné de failles de sécurité logicielles connues mais les problèmes de configuration ou de mauvaise utilisation sont toujours présents. La mauvaise utilisation de fonctionnalités est inhérente au logiciel car chaque fonctionnalité repose sur des hypothèses de confiance qui peuvent être mises en défaut. Les défauts de configuration sont également inévitables pour deux raisons. Premièrement, la plupart des réglages de sécurité permettent d'augmenter la sécurité mais réduisent d'autres fonctionnalités : utiliser les réglages les plus stricts en termes de sécurité conduiraient donc parfois à un logiciel peu (voire pas du tout) utilisable. Deuxièmement, de nombreux réglages de sécurité ont un impact à la fois positif et négatif sur la sécurité. On peut ici prendre l'exemple du nombre d'essais maximum pour saisir un mot de passe avant de verrouiller le compte utilisateur. Si on fixe ce seuil à 1, on obtient une sécurité maximale contre les attaques qui consistent à essayer différents mots de passe mais les utilisateurs légitimes n'auraient pas le droit à l'erreur. Cela pourrait également permettre à un attaquant de mener une attaque de déni de serveice contre certains utilisateurs en effectuant une tentative de connexion sur leurs comptes.</p>

-

-<p>La somme de toutes ces vulnérabilités potentielles, qu'elles soient liées à des défauts de configuration, à une mauvaise utilisation du logiciel ou à des failles techniques dans son code, font donc qu'on peut avoir des dizaines (voire centaines) de vulnérabilités pour un système donné à un instant donné. Il est probable que les caractéristiques de ces vulnérabilités varient grandement : certaines seront faciles à exploiter tandis que d'autres ne pourront être exploitées que si une conjonction de conditions très improbables se produit. Une vulnérabilité peut fournir un accès administrateur à un système alors qu'une autre pourrait ne donner qu'un accès en lecture à un fichier sans importance. En fin de compte, une organisation a besoin de savoir :</p>

-

-<ul>

- <li>la difficulté d'exploiter chaque vulnérabilité connue ;</li>

- <li>l'impact d'une exploitation potentielle d'une vulnérabilité (connue ou non).</li>

-</ul>

----

-title: SSL et TLS

-slug: Apprendre/SSL_et_TLS

-tags:

- - Security

- - Tutorial

-translation_of: Archive/Security/SSL_and_TLS

----

-<p>{{draft}}</p>

-

-<p>Les protocoles <em>Secure Sockets Layer</em> (SSL) (ou Couche de sockets sécurisée) et <em>Transport Layer Security</em> (TLS) (ou Couche de transport sécurisée) sont des protocoles universellement acceptés pour l'établissement de communications authentifiées et chiffrées entre des clients d'une part et des serveurs d'autre part. L'authentification liée au serveur et celle liée au client utilisent toutes les deux SSL/TLS.</p>

-

-<p>SSL/TLS utilise un système de combinaison entre une clé publique et un chiffrement à clé symétrique. Le chiffrement par clé symétrique est beaucoup plus rapide qu'un chiffrement par clé publique mais le chiffrement par clé publique permet d'utiliser de meilleures techniques d'authentification Une « session » SSL/TLS commence donc toujours par un échange de message qu'on appellera l'établissement de liaison (<em>handshake</em> est le terme communément employé en anglais). Cet établissement de liaison permet au serveur de s'authentifier envers le client en utilisant des techniques basées sur des algorithmes à clé publique, cela permet ensuite au client et au serveur de coopérer pour créer des clés symétriques afin de chiffrer/déchiffrer rapidement les messages échangées pendant la session.</p>

-

-<p>Ces deux protocoles supportent différents algorithmes de chiffrement pour différentes opérations : l'authentification entre le serveur et le client, la transmission de certificats, l'établissement de clés de sessions. Les clients et serveurs peuvent supporter différents algorithmes de chiffrement. Une des fonctionnalités de l'établissement de liaison est la détermination du meilleur algorithme de chiffrement, supporté par le serveur et par le  client. C'est cet algorithme qui sera ensuite utilisé pour les opérations listées juste avant.</p>

-

-<p>Les algorithmes utilisés pour échanger des clés, comme RSA ou la cryptographie sur courbes elliptiques (ECC pour <em>Elliptic Curve Cryptography</em> en anglais) déterminent la façon dont le client et le serveur calculent les clés symétriques à utiliser pendant la session SSL/TLS. Le protocole SSL repose principalement sur des ensembles d'algorithmes qui incluent RSA alors que TLS, plus moderne supporte à la fois RSA et des algorithmes d'ECC.</p>

-

-<div class="note">

-<p><strong>Note :</strong> La sécurité de clés RSA dépend de sa longueur et de la capacité de calcul des ordinateurs. À l'heure actuelle, il est recommandé d'utiliser un clé RSA longue de 2048 bits. Bien que de nombreux serveurs web continuent d'utiliser des clés de 1024 bits, il serait préférable de passer à 2048 bits. Pour les ordinateurs 64 bits, des clés encore plus fortes devraient être utilisées (3072 ou 4096 bits par exemple).</p>

-</div>

-

-<p>Étant donné que certaines infrastructures de clés publiques utilisent encore RSA avant de migrer vers d'autres systèmes cryptographiques comme ECC, les serveurs devraient, dans la mesure du possible, continuer à supporter RSA.</p>

-

-<h3 id="Les_suites_de_chiffrement_supportées_par_RSA">Les suites de chiffrement supportées par RSA</h3>

-

-<p>Les suites de chiffrement communément supportées et qui utilisent un échange de clés basé sur RSA comportent généralement :</p>

-

-<ul>

- <li>AES et une authentification des messages basée sur SHA. Les algorithmes de chiffrement <em>Advanced Encryption Standard</em> (AES) utilisent une taille de bloc de 128 bits et des clés de 128 ou 256 bits. Il existe 3.4 x 10³⁸ clés différentes sur 128 bits et 1.1 x 10⁷⁷ clés différentes sur 256 bits. AES possède le plus grand nombre de clés parmi les différents algorithmes supportés par SSL, ce qui en fait donc le plus « fort ». Ces suites de chiffrement sont conformes à FIPS.</li>

- <li>Triple DES et authentification des messages basée sur SHA. Le triple DES (pour <em>Data Encryption Standard</em>) est le deuxième algorithme le plus fort supporté par SSL bien qu'il ne soit pas aussi rapide que RC4. Le triple DES utilise une clé trois fois plus grande qu'une clé utilisée pour un DES standard. La taille de clé est donc importante, ce qui permet d'avoir 3.7 * 10⁵⁰ clés possibles. Cette suite de chiffrement est conforme à FIPS.</li>

- <li>RC4, RC2 et une authentification des messages basée sur MD5. Les algorithmes RC4 et RC2 chiffrent sur 128 bits, ce qui permet d'avoir (environ) 3.4 * 10³⁸ clés différentes. Les algorithmes basés sur RC4 sont plus rapides que ceux basés sur RC2. RC4 peut utiliser une authentification des messages basée sur SHA ou MD5.</li>

- <li>DES et une authentification des messages basées sur SHA. DES, utilisé sur 56 bits permet de disposer d'environ 7.2 x 10¹⁶ clés différentes. Étant devenue trop faible cryptographiquement parlant, cette suite de chiffrement n'est plus conforme à FIPS.</li>

-</ul>

-

-<h3 id="Utiliser_les_courbes_elliptiques_pour_la_cryptographie">Utiliser les courbes elliptiques pour la cryptographie</h3>

-

-<p>La cryptographie sur courbes elliptiques (ou <em>Elliptic Curve Cryptography</em>, ECC en anglais) est un système qui utilise les courbes elliptiques afin de créer des clés pour chiffrer des données. ECC permet d'avoir des clés de chiffrement plus fortes et également plus courtes que celles utilisées avec RSA. Cela fait qu'ECC est plus rapide et plus efficace, en termes d'implémentation, par rapport à RSA.</p>

-

-<p>ECC dispose donc de plusieurs avantages par rapport à RSA. Un des désavantages d'ECC est qu'il est, pour l'instant, moins largement supporté que RSA.</p>

-

-<table class="standard-table">

- <thead>

- <tr>

- <th scope="col">Bits de sécurité</th>

- <th scope="col">Longueur de clé RSA</th>

- <th scope="col">Longueur de clé ECC</th>

- </tr>

- </thead>

- <caption>Comparaison de la force des algorithmes RSA et ECC</caption>

- <tbody>

- <tr>

- <td>80</td>

- <td>1024</td>

- <td>160-223</td>

- </tr>

- <tr>

- <td>112</td>

- <td>2048</td>

- <td>224-255</td>

- </tr>

- <tr>

- <td>128</td>

- <td>3072</td>

- <td>256-383</td>

- </tr>

- <tr>

- <td>192</td>

- <td>7860</td>

- <td>384-511</td>

- </tr>

- <tr>

- <td>256</td>

- <td>15360</td>

- <td>512+</td>

- </tr>

- </tbody>

-</table>

-

-<p>Les informations de ce tableau proviennent du <em>National Institute of Standards and Technology</em> (NIST). Pour plus d'informations, se référer à <a href="http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf">http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf</a>.</p>

-

-<p>Pour plus d'informations sur ECC, voir également la <a href="https://tools.ietf.org/html/rfc4492">RFC 4492</a> (et notamment la section 5.6.1 et le tableau 2).</p>

-

-<p>Une excellente ressource, disponible en français, pour comprendre SSL/TLS est <a href="http://www.iletaitunefoisinternet.fr/ssltls-benjamin-sonntag/">la conférence de Benjamin Sonntag réalisée dans le cadre d'Il était une fois Internet (CC BY-SA)</a>.</p>

----

-title: Sécurité TCP/IP

-slug: Apprendre/Sécurité_TCP_IP

-tags:

- - Beginner

- - Networking

- - Security

- - Tutorial

-translation_of: Archive/Security/TCP_IP

----

-<p>{{draft}}</p>

-

-<p>TCP/IP est très largement utilisé afin de transmettre les communications sur le réseau. Les communications TCP/IP se composent de quatre couches qui fonctionnent ensemble. Lorsqu'un utilisateur souhaite transférer des données sur un/des réseau(x), les données sont passées de la couche la plus haute à la couche la plus basse et chaque couche ajouter des informations. À chaque niveau, l'unité logique qui est manipulée est généralement composées d'un en-tête et d'une charge utile. La<em> charge utile</em> correspond à l'information passée depuis la couche précédente. L'<em>en-tête</em> contient des informations spécifiques à la couche courante (telles que les adresses utilisées). Au niveau de la couche applicative, la charge utile correspond aux données transmises. La couche la plus basse envoie les différentes données via le réseau physique. Une fois arrivée à destination, les données repassent vers les couches les plus hautes. En résumé, les données produites par une couche sont encapsulées dans un conteneur plus grand dans la couche inférieure. Les quatres couches qui permettent à TCP/IP de fonctionner sont présentées ci-après, de la plus haute à la plus basse :</p>

-

-<ul>

- <li><strong>La couche applicative</strong>. Cette couche envoie et reçoit des données pour des applications spécifiques telles que le <em>Domain Name System</em> (DNS), <em>HyperText Transfer Protocol</em> (HTTP), et <em>Simple Mail Transfer Protocol</em> (SMTP).</li>

- <li><strong>La couche de transport</strong><strong>.</strong> Cette couche fournit des services pour transporter les données entre les réseaux (en utilisant ou non des services avec connexions). Cette couche peut éventuellement assurer la fiabilité des communications. <em>Transmission Control Protocol</em> (TCP) (pour protocole de contrôle des transmissions) et <em>User Datagram Protocol</em> (UDP) (pour protocole de datagramme utilisateur) sont les protocoles de transports les plus communément utilisés.</li>

- <li><strong>La couche réseau</strong><strong>.</strong> Cette couche s'occupe de router les paquets entre les différents réseaux. L'<em>Internet Protocol</em> (IP) est le protocole réseau fondamental pour la mise en oeuvre de TCP/IP. D'autres protocoles utilisés à ce niveau sont <em>Internet Control Message Protocol</em> (ICMP) (pour protocole de contrôle des message Internet) et <em>Internet Group Management Protocol</em> (IGMP) (pour protocole de gestion des groupes Internet).</li>

- <li><strong>La couche physique</strong><strong>.</strong> Cette couche gère les communications sur les composants physiques. Le protocole le plus connu pour cette couche est Ethernet.</li>

-</ul>

-

-<p>Des contrôles de sécurité existent pour chaque couche du modèle TCP/IP. Comme vu précédemment, les données sont passées de la couche la plus haute vers la couche la plus basse, chaque couche ajoutant des informations. C'est pour cela que les contrôles de sécurité effectués par une couche ne bénéficient pas aux couches inférieures car celles-ci effectuent des opérations dont les couches supérieures ne sont pas conscientes. Voici quelques contrôles de sécurité mis en œuvre par chaque couche :</p>

-

-<ul style="list-style-type: square;">

- <li><strong>La couche applicative</strong><strong>.</strong> Des contrôles distincts doivent être mis en place pour chaque application. Si, par exemple, une application doit envoyer des données sensibles sur les réseaux, l'application devra être adaptée pour mettre en place ces contrôles.  Bien que cette solution offre un certain contrôle et une certaine flexibilité, cela peut demander des efforts importants. Concevoir et implémenter une application sûre sur le plan cryptographique est très complexe et il faut également veiller à ne pas ajouter de vulnérabilités. Bien que ces sécurités puissent protéger le contenu lié aux applications, elles ne pourront pas protéger d'autres données comme les adresses IP qui sont utilisées sur d'autres couches inférieures. Le plus possible, les contrôles effectués à cette couche devraient être basés sur des standards définis depuis quelques temps. Par exemple <em>Secure Multipurpose Internet Mail Extensions</em> (S/MIME), est communément utilisé pour chiffrer les messages électroniques.</li>

- <li><strong>La couche de transport</strong><strong>.</strong> Les contrôles présents à cette couche peuvent être utilisés pour protéger les données d'une session donnée entre deux hôtes. Les informations liées aux adresses IP sont ajoutées avec la couche réseau, la couche de transport ne peut donc pas protéger ces données. L'exemple le plus connu pour une sécurisation effectuée à ce niveau est celle du trafic HTTP par TLS (<em>Transport Layer Security</em> ou sécurité de la couche de transport) (TLS correspond à la version 3 du standard SSL, TLS est notamment décrit dans la RFC 4346). À la différence des contrôles applicatifs qui nécessitent de modifier l'application, les contrôles effectués au niveau de la couche de transport (tels que TLS) sont moins intrusifs car ils n'ont pas besoin de connaître le fonctionnement ou les caractéristiques d'une application. TLS est un protocole testé et robuste qui possède plusieurs implémentations qui ont été ajoutées à différentes applications. Il s'agit donc d'une option intéressante comparée à l'application de contrôles au niveau applicatif.</li>

- <li><strong>La couche réseau</strong><strong>.</strong> Les contrôles appliqués sur cette couche portent sur l'ensemble des applications. Toutes les communications effectuées sur le réseau entre deux hôtes ou deux réseaux peuvent être protégées à cette couche sans modifier les applications côté client ou côté serveur. Dans certains environnements, les contrôles de la couche réseau (par exemple <em>Internet Protocol Security</em> (IPsec)) représentent une meilleure solution que des contrôles aux niveaux supérieurs qui nécessiteraient de modifier les applications. Les contrôles effectués à ce niveau permettent également aux administrateurs réseaux de s'assurer du respect de certaines règles de sécurité. Un avantage intrinsèque aux contrôles effectués à ce niveau est qu'ils peuvent protéger les informations IP (telles que les adresses). Cependant, les contrôles de la couche réseau sont moins flexibles que ceux des couches supérieures. Les tunnels VPN SSL permettent de sécuriser les communications TCP et UDP (que ce soit entre un client et un serveur ou autre), comme tels, ils sont considérés comme des VPN de couche réseau.</li>

- <li><strong>La couche physique</strong><strong>.</strong> Les contrôles effectués sur la couche physique concernent toutes les communications qui transitent sur un lien physique donné. Cela peut être un circuit dédié entre deux bâtiments ou une connexion entre un modem et un fournisseur d'accès. Les contrôles de la couche réseau sont souvent apportés par des composants matériels spécifiques. Cette couche étant plus basse que la couche réseau, les contrôles effectués sur la couche physique protègent les données ainsi que les informations IP. Par rapport aux contrôles évoqués précedemment, les contrôles effectués sur cette couche sont plutôt simples à implémenter. Ils permettent également supporter d'autres protocoles réseaux. Ces contrôles s'appliquent sur un lien physique donné, ils ne peuvent donc protéger des communications qui emprunteraient plusieurs liens (par extension, ils ne peuvent donc pas créer un VPN au niveau d'Internet). Une connexion Internet emprunte généralement plusieurs liens physiques, la protection d'une telle connexion au niveau physique nécessiterait donc de contrôler les différents liens, ce qui est rarement faisablee. Ces contrôles existent depuis de nombreuses années afin de rajouter un niveau de protection sur des liens physiques douteux.</li>

-</ul>

-

-<p>Vu qu'ils permettent de protéger les données des applications sans qu'il soit nécessaire de les modifier, les contrôles de la couche réseau sont les plus utilisés pour sécuriser les communications entre différents réseaux partagés tels qu'Internet. Les contrôles de la couche réseau fournissent une solution qui couvre les données des différentes applications et les informations IP. Cependant, dans de nombreux cas, des contrôles à d'autres niveaux seront plus pertinents. Ainsi, si une seule application doit être protégée, des contrôles au niveau du réseau pourraient être excessifs. Les protocoles de contrôle de la couche de transport comme SSL/TLS sont communément utilisés pour sécuriser les communications d'applications basées sur HTTP (bien que ces protocoles permettent également de sécuriser des communications SMTP, POP, IMAP, FTP, etc.). Les principaux navigateurs web supportent tous TLS et il n'est donc pas nécessaire d'installer un logiciel client ou de configurer quoi que ce soit pour utiliser ce protolce. Pour chaque niveau, les contrôles offrent des avantages et des fonctionnalités qu'il est impossible de retrouver aux autres niveaux.</p>

-

-<p>SSL/TLS est le contrôle de sécurité le plus utilisé au niveau de la couche de transport. Selon l'implémentation et la configuration de SSL/TLS, ce dernier peut fournir les protections suivantes :</p>

-

-<ul style="list-style-type: square;">

- <li><strong>Confidentialité</strong><strong>.</strong> SSL/TLS permet de s'assurer que les données ne peuvent pas être lues par des tiers non autorisés. Pour cela, les données sont chiffrées grâce à un algorithme de chiffrement et grâce à une clé secrète, connue uniquement des deux interlocuteurs qui souhaitent échanger des données. Les données ne peuvent être déchiffrées que si l'on dispose de la clé secrète.</li>

- <li><strong>Intégrité</strong><strong>.</strong> SSL/TLS permet de déterminer si les données ont été modifiées (intentionnellement ou non) pendant le transfert. L'intégrité des données est vérifiée grâce à une valeur « MAC » (pour code d'authentification des message) qui est une somme de vérification cryptographique des données. Si les données ont été modifiées, la MAC calculée initialement et la MAC calculée à la suite du transfert seront différentes.</li>

- <li><strong>Authentification entre pairs</strong><strong>.</strong> Chaque point d'échange SSL/TLS peut confirmer l'identité d'un autre point d'échange SSL/TLS avec lequel il souhaiterait communiquer afin de s'assurer que les données sont bien envoyées à l'hôte voulu. Cette authentification SSL/TLS est généralement unilatérale : le client authentifie le serveur. Cela dit, l'authentification peut être effectuée symétriquement.</li>

- <li><strong>Protection contre le rejeu</strong><strong>.</strong> Les mêmes données ne peuvent pas être transmises plusieurs fois et les données ne peuvent pas être transmises dans le désordre.</li>

-</ul>