Introduction à SSL

  • Raccourci de la révision : Introduction_à_SSL
  • Titre de la révision : Introduction à SSL
  • ID de la révision : 262299
  • Créé :
  • Créateur : Fredchat
  • Version actuelle ? Non
  • Commentaire /* Suites de chiffrement de Fortezza */

Contenu de la révision

{{template.Traduction_en_cours("Introduction to SSL")}}

Introduction

Ce document est une introduction au protocole Secure Sockets Layer (SSL). SSL a été universellement adopté par le World Wide Web pour authentifier et crypter les communications entre les clients et les serveurs.

Le nouveau protocole standard de l'Internet Engineering Task Force (IETF), appelé Transport Layer Security (TLS) est basé sur SSL. Les détails de ce protocole sont disponible dans le document Request For Comments (RFC): 2246, The TLS Protocol Version 1.0. Certains produits de Red Hat supportent déjà le TLS. La plupart des autres produits de Red Hat prévoient son support dans les futures versions.

Ce document est d'abord destiné aux administrateurs de serveurs Red Hat, mais les informations qu'il contient peuvent être tout aussi utiles aux développeurs d'applications supportant SSL. Ce document suppose que vous connaissez les concepts de base de la cryptographie à clef publique, tels que décrit dans « Introduction à la cryptographie à clef publique ».

Le protocole SSL

Le Transmission Control Protocol/Internet Protocol (TCP/IP) définit le transport et le routage des données sur Internet. Les autres protocoles, tels que HyperText Transport Protocol (HTTP), Lightweight Directory Access Protocol (LDAP), ou Internet Messaging Access Protocol (IMAP), s'exécute par "dessus" TCP/IP au sens qu'ils utilisent tous TCP/IP pour supporter les tâches applicatives typiques telles qu'afficher des pages Web ou faire tourner des serveurs de courrier.

Figure 1. Where SSL Runs

Le protocole SSL s'exécute par dessus TCP/IP et en dessous des protocoles de haut niveau tels que HTTP ou IMAP. Il utilise TCP/IP au nom des protocoles de haut niveau, et, lors du processus, il autorise un serveur avec SSL activé à s'authentifier auprès d'un client SSL, il autorise le client à s'authentifier auprès du serveur, et il autorise les deux ordinateurs à établir une connexion chiffrée.

Ces possibilités répondent aux soucis fondamentaux concernant les communication par Internet ou tout autre réseau TCP/IP :

  • L'authentification du serveur SSL permet à un utilisateur de confirmer l'identité du dit serveur. Les logiciels client SSL peuvent utiliser les techniques standards de cryptographie à clef publique pour vérifier que le certificat d'un serveur et son ID publique sont valides et qu'ils sont listés par une autorité de certification (AC ou Certificate Authority en anglais) faisant partie des AC de confiance définies par le logiciel client. Cette confirmation peut être importante si l'utilisateur, par exemple, utilise sa carte de crédit pour payer une transaction par Internet et qu'il désire vérifier l'identité du serveur récepteur.
  • L'authentification d'un client SSL permet à un serveur de confirmer l'identité de l'utilisateur. En utilisant les mêmes techniques que pour l'authentification du serveur, un serveur SSL peut vérifier la validité du certificat client et de son ID publique et qu'ils ont été délivrés par une AC appartenant à la liste des AC de confiance du serveur. Cette confirmation est importante lorsque, par exemple, le serveur d'un banque veut s'assurer de l'identité du destinataire des données.
  • Une connexion SSL cryptée, requiert que toutes les informations échangées entre le client et le serveur soient codée par le logiciel émetteur et décodée par le logiciel récepteur, ceci permettant un haut degré de confidentialité. La confidentialité est important pour les deux parties pour toutes les transactions privées. De plus, toutes les données transmises lors d'une connexion SSL cryptée sont protégées par un mécanisme détectant les altérations, pour déterminer automatiquement si les données ont été modifiées pendant la transmission.

Le protocole SSL inclus deux sous-protocoles : le protocole SSL record et le protocole SSL handshake (négociation SSL). Le protocole SSL record définit le format utilisé pour la transmission de données. Le protocole de négociation SSL implique d'utiliser le protocole SSL record pour échanger une série de messages entre un serveur SSL et un client SSL lorsqu'ils établissent la première connexion SSL. Cet échange de messages est destiné à faciliter les actions suivantes :

  • Authentifier le serveur auprès du client.
  • Autoriser le client et le serveur à sélectionner un algorithme de cryptage, ou de chiffrement, supporter par chacun d'eux.
  • Éventuellement, authentifier le client auprès du serveur.
  • Utiliser les techniques de cryptographie à clef publique pour générer des secrets partagés.
  • Établir un connexion SSL cryptée.

Pour plus d'informations à propos du processus de négociation, voir la section "La négociation SSL."

Chiffrements utilisés avec SSL

Le protocole SSL supporte l'utilisation d'un grand nombre d'algorithme de cryptographie, ou de chiffrements, pour des usages tels l'authentification réciproque entre un serveur et un client, la transmission de certificat, et l'établissement d'une session sécurisée. Les clients et les serveurs peuvent supporter différentes suites de chiffrement, ou paramètres de chiffrements, selon des facteurs tels que la version de SSL qu'ils intègrent, la politique d'entreprise concernant la force de cryptage acceptable et les restrictions gouvernementales sur l'exportation de logiciels SSL. Parmi ses autres fonctions, le protocole de négociation SSL détermine la façon dont le serveur et le client négocient la suite de chiffrement à utiliser pour s'authentifier l'un à l'autre, pour transmettre des certificats et pour établir des sessions sécurisées.

Les algorithmes par échange de clef, tels que KEA et RSA, dirigent la manière dont le serveur et le client vont déterminer les clefs symétriques que chacun d'eux utilisera pendant la session SSL. Les suites de chiffrement les plus couramment utilisées se servent de clefs d'échange RSA.

Les protocoles SSL 2.0 et SSL 3.0 autorisent la redondance des paramètres de suites de chiffrement. Les administrateurs peuvent activer ou désactiver chaque suite de chiffrement supportée par les clients ou les serveurs. Lorsqu'un client et un serveur s'échangent des informations à l'établissement de la négociation SSL, ils identifient les plus fortes suites de chiffrement autorisées qu'ils ont en commun pour les utiliser lors de la session SSL.

Note : Dans Firefox 2, le support de SSL 2.0 est désactivé par défaut, en faveur de SSL 3.0. Voir l'article La sécurité dans Firefox pour plus d'informations.

La décision d'une organisation concernant les suites de chiffrement activer dépend de critères tels que la sensibilités des données à échanger, la rapidité du chiffrement et des conditions d'application des régles d'exportation.

Certaines organisations peuvent vouloir désactiver les chiffrement les plus faibles pour empêcher les connexions SSL avec des cryptage faible. Cependant, à cause de restrictions imposées par le gouvernement étasunien sur les produits supportant un cryptage de plus de 40-bit, désactiver le support de tous les chiffrements 40-bit restreindra l'accés au réseau aux seuls navigateurs provenant des États-Unis (à moins que le serveur n'ait une Global Server ID qui permette aux clients internationaux d'utiliser un cryptage plus fort).

Pour satisfaire une plus grande portion possible d'utilisateur, il est préférable pour les administrateurs d'activer le plus grand nombre de suites de chiffrement possibles. Ainsi, lorsqu'un client ou un serveur domestique se connectera avec, respectivement, un serveur ou un client domestique, il essayera d'utiliser le plus fort chiffrement disponible. Et lorsque le le client ou le serveur domestique se connectera avec un serveur ou un client international, il négociera l'utilisation de chiffrements autorisés par les lois d'exportations étasuniennes.

Cependant, comme les chiffrements 40-bit peuvent être cassés très rapidement, les administrateurs dont les utilisateurs peuvent utiliser de plus forts chiffrements sans déroger aux règles d'exportation devraient désactiver les chiffrements 40-bit s'ils sont soucieux à propos de l'accès au données par des personnes tiers non autorisées.

Red Hat Console ne supporte pas toutes les suites de chiffrement intégrer par les serveurs et les clients Red Hat. Pour s'assurer que Red Hat Console peut contrôler un serveur SSL, le serveur doit autoriser au moins une des suites de chiffrement pour SSL 3.0 suivantes :
  • RC4 avec chiffrement 128-bit et message d'authentification MD5
  • RC4 avec chiffrement 40-bit et message d'authentification MD5
  • RC2 avec chiffrement 40-bit et message d'authentification MD5
  • Pas de chiffrement, uniquement message d'authentification MD5

Suites de chiffrement avec clef d'échange RSA

Le tableau 1 liste les suites de chiffrement supportées par SSL utilisant un algorithme à clef d'échange RSA. À moins que cela ne soit indiqué, tous les chiffrements listés dans ce tableau sont supportés par les protocoles SSL 2.0 et SSL 3.0. Les suites de chiffrement sont listées du plus haut au plus bas niveau de chiffrement.

Table 1. Suites de chiffrement supportées par le protocole SSL utilisant un algorithme de clef d'échange RSA
Niveau de chiffrement et usage recommandé
Suites de chiffrement
Chiffrement de très haut niveau Permitted for deployments within the United States only. This cipher suite is appropriate for banks and other institutions that handle highly sensitive data. Red Hat Console does not support this cipher suite. Chiffrement 168-Bit triple DES et message d'authentification SHA-1 Triple DES is the strongest cipher supported by SSL, but it is not as fast as RC4. Triple DES uses a key three times as long as the key for standard DES. Because the key size is so large, there are more possible keys than for any other cipher-approximately 3.7 * 1050. This cipher suite is FIPS-compliant. Both SSL 2.0 and SSL 3.0 support this cipher suite.
Chiffrement de haut niveau Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs. Chiffrement 128-Bit avec RC4 et message d'authentification MD5 Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 1038 possible keys, making them very difficult to crack. RC4 ciphers are the fastest of the supported ciphers. Both SSL 2.0 and SSL 3.0 support this cipher suite. Red Hat Console supports only the SSL 3.0 version of this cipher suite.
Chiffrement 128-Bit avec RC2 et message d'authentification MD5 Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 1038 possible keys, making them very difficult to crack. RC2 ciphers are slower than RC4 ciphers. This cipher suite is supported by SSL 2.0 but not by SSL 3.0. Red Hat Console does not support this cipher suite.
Chiffrement 56-Bit avec DES et message d'authentification SHA-1 DES is stronger than 40-bit encryption, but not as strong as 128-bit encryption. DES 56-bit encryption permits approximately 7.2 * 1016 possible keys. This cipher suite is FIPS-compliant. Both SSL 2.0 and SSL 3.0 support this cipher suite, except that SSL 2.0 uses MD5 rather than SHA-1 for message authentication. Red Hat Console does not support this cipher suite.
Chiffrements exportables These cipher suites are not as strong as those listed above, but may be exported to most countries (note that France permits them for SSL but not for S/MIME). They provide the strongest encryption available for exportable products.1 RC4 With 40-Bit Encryption and MD5 Message Authentication RC4 40-bit encryption permits approximately 1.1 * 1012 (a trillion) possible keys. RC4 ciphers are the fastest of the supported ciphers. Both SSL 2.0 and SSL 3.0 support this cipher. Red Hat Console supports only the SSL 3.0 version of this cipher suite.
Chiffrement 40-bit avec RC2 et message d'authentification MD5 RC2 40-bit encryption permits approximately 1.1 * 1012 (a trillion) possible keys. RC2 ciphers are slower than the RC4 ciphers. Both SSL 2.0 and SSL 3.0 support this cipher. Red Hat Console supports only the SSL 3.0 version of this cipher suite.
Chiffrement de bas niveau This cipher suite provides authentication and tamper detection but no encryption. Server administrators must be careful about enabling it, however, because data sent using this cipher suite is not encrypted and may be accessed by eavesdroppers. Pas de chiffrement, uniquement message d'authentification MD5 This cipher suite uses MD5 message authentication to detect tampering. It is typically supported in case a client and server have none of the other ciphers in common. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.

1 Notez que pour les chiffrements RC4 et RC2, le terme "chiffrement 40-bit" signifie que les clefs sont en 128 bits, mais que seuls 40 bits ont une signification cryptographique.

Suites de chiffrement de Fortezza

Le tableau 2 liste les suites de chiffrement additionnelles supportées par les produits Red Hat intégrant Fortezza. Pour SSL 3.0 Fortezza est un système de cryptage utilisé par les agences gouvernementales étasuniennes pour la gestion des informations sensibles, mais déclassifiées. Il fournit une implémentation hardware de 2 chiffrements classifiés, développés par le gouvernement fédéral étasunien : Fortezza KEA et SKIPJACK. Les chiffrements Fortezza pour SSL utilise un algorithme par clef d'échange (KEA) plutôt qu'un algorithme de clef d'échange RSA mentionné dans la précédente section, et il utilise les cartes Fortezza et DSA pour l'authentification client.

Tableau 2. Suites de chiffrement supportées par Red Hat lors de l'utilisation de Fortezza pour SSL 3.0
Niveau de chiffrement et usage recommandé Suites de chiffrement
Suites de chiffrement Fortezza haut niveau Autorisé pour un déploiement uniquement aux États-Unis. Ces suites de chiffrement supportent un chiffrement d'assez haut niveau pour la plupart des besoin commerciaux et gouvernementaux. Red Hat Console n'intègre pas ces suites de chiffrement. Chiffrement 128-Bit avec RC4 et message d'authentification SHA-1 Comme le chiffrement 128-Bit avec RC4 et message d'authentification MD5, ce chiffrement est un des deux plus fort chiffrements après le Triple DES. Il permet approximativement 3.4 * 1038 clefs, le rendant très difficile à briser. Cette suite de chiffrement est supportée par le protocole SSL 3.0 mais pas par SSL 2.0.
Chiffrement 80-bit RC4 avecSKIPJACK et message d'authentification SHA-1 Le chiffrement SKIPJACK est un algorithme cryptographique à clefs symétriques classifié, implémenté dans les matériels compatibles Fortezza. Certaines implémentations de SKIPJACK supportent les clefs tierce partie utilisant le Law Enforcement Access Field (LEAF). Les plus récentes implémentations ne les supportent pas. Cette suite de chiffrement est supportée par le protocole SSL 3.0 mais pas par SSL 2.0.
Suites de chiffrement Fortezza bas niveau Cette suite de chiffrement fournit l'authentification et la détection des altérations mais pas l'encryptage des données. Les administrateurs de serveurs doivent être très prudents concernant son activation, du fait que les données transmises avec cette suites de chiffrement ne sont pas encryptées et qu'elles sont potentiellement accessibles à de personnes tierces espionnant le réseau. Red Hat Console ne supporte pas ces suites de chiffrement. Pas de chiffrement, message d'authentification SHA-1 uniquement Ce chiffrement utilise le message d'authentification SHA-1 pour détecter les altérations de données. Cette suite de chiffrement est supportées par le protole SSL 3.0 mais pas par SSL 2.0.

La négociation SSL

Le protocole SSL utilise une combinaison de clef publique et de cryptage par clef symétrique. Le cryptage par clef symétrique est plus rapide que le cryptage par clef publique, cependant, le cryptage par clef publique fournit de bien meilleures techniques d'authentification. Une session SSL débute toujours par un échange de messages appelé négociation SSL. La négociation permet au serveur de s'authentifier auprès du client en utilisant les techniques par clef publique, puis autorise le client et le serveur à coopérer pour la création de clefs symétriques utilisées pour le cryptage rapide, le décryptage, et la détection de l'altération des données pendant la session qui suit. Éventuellement, la négociation SSL peut également permettre au client de s'authentifier auprès du serveur.

Les détails programmatiques exacts des messages échangés pendant la négociation SSL fait parti des objectifs de ce document. Cependant, les étapes mises en œuvre peuvent être résumées comme suit (en admettant l'utilisation de suites de chiffrement listées à la section « Suites de chiffrement avec clef d'échange RSA ») :

  1. Le client envoie au serveur sa version de SSL, ses paramètres de chiffrement, des données générées aléatoirement, et toutes autres informations dont le serveur à besoin pour communiquer avec lui en utilisant SSL.
  2. Le serveur envoie au client sa version de SSL ses paramètres de chiffrement, des données générées aléatoirement, et toutes autres informations dont le client à besoin pour communiquer avec lui en utilisant SSL. Le serveur envoie également son propre certificat et, si le client demande une ressource serveur nécessitant une authentification client, il demande le certificat client.
  3. Le client utilise certaines informations envoyées par le serveur pour l'authentifier (pour plus d'informations, voir la section « Authentification serveur »). Si le serveur ne peut pas être authentifié, l'utilisateur est averti du problème et il est informé que la connexion chiffrée et authentifiée ne peut pas être établie. Si le serveur peut être correctement authentifié, le client procède alors à l'étape 4.
  4. En utilisant toutes les données générées pendant la négociation SSL, le client (avec la coopération du serveur, suivant les chiffrements utilisés) crée un premaster secret pour la session, le chiffre avec la clef publique du serveur (obtenue dans le certificat du serveur envoyé à l'étape 2), et envoie le premaster secret chiffré au serveur.
  5. Si le serveur requiert une authentification client (une étape optionnelle dans la négociation), le client doit alors signer une autre portion de données limitée à cette négociation et connue par le client et le serveur. Dans ce cas, le client envoie les données chiffrées et son propre certificat au serveur ainsi que le premaster secret chiffré.
  6. Si le serveur a requis une authentification client, il tente cette authentification (pour plus d'information, voir la section « Authentification client »). Si le client ne peut être authentifié, alors la session prend fin. Si le client est authentifié avec succès, le serveur utilise sa clef privée pour déchiffrer le premaster secret, puis procéder à une série d'étapes (également exécutée par le client, à partir du même premaster secret) pour générer le master secret.
  7. Le client et le serveur utilise tout les deux, le the master secret pour générer des clefs de sessions, qui sont des clefs symétriques utilisées pour chiffrer et déchiffrer les informations échangées pendant la session SSL et pour vérifier leur intégrité, afin de détecter tout changement intervenu dans les données entre leur envoie et leur réception durant la connexion SSL.
  8. Le client envoie un message au serveur pour l'informer que les futures données transmises seront chiffrées avec la clef de session. Il envoie alors séparément un message (chiffré) indiquant que la négociation côté client est finie.
  9. Le serveur envoie un message au client pour l'informer que les futures données transmises seront chiffrées avec la clef de session. Il envoie alors séparément un message chiffré indiquant que la négociation SSL côté serveur est finie.
  10. La négociation SSL est maintenant terminée et la session SSL peut commencer. Le client et le serveur utilisent les clefs de session pour crypter et décrypter les données échangées et pour valider leur intégrité.

Avant d'aller plus loin dans la session, les serveurs Red Hat peuvent être configurés pour vérifier que le certificat client est présent dans les données de l'utilisateur dans le répertoire LDAP. Cette option de configuration fournit un moyen sûr de savoir si le certificat client n'a pas été révoqué.

Il est important de retenir que l'authentification du serveur comme celle du client entraîne le cryptage de certaines données à l'aide d'une clef, privée ou publique, et leur décryptage à l'aide de l'autre clef :

  • Dans le cas d'une authentification serveur, le client chiffre le premaster secret avec la clef publique du serveur. Seule la clef privée correspondante pourra déchiffrer correctement ce secret, ainsi le client sera assuré que l'identité associée à la clef publique est bien celle du serveur avec lequel il est connecté. Dans le cas contraire, le serveur ne pourra pas déchiffrer le premaster secret et ne pourra pas générer les clefs symétriques requises pour la session et celle-ci se terminera.
  • Dans le cas d'une authentification client, le client chiffre certaines données aléatoires avec ses clef privée, créant ainsi une signature numérique. La clef publique du certificat client peut correctement valider cette signature suelement si elle correspond à la clef privée utilisée. Dans le cas contraire, le serveur ne pourra pas valider la signature numérique et la session se terminera.

Les sections ci-dessous fournissent plus de détails concernant les authentifications serveur et client.

Authentification serveur

Les logiciels client SSL de Red Hat requirent toujours une authentification client ou une validation cryptographique de l'identité du serveur par le client. Comme expliqué à l'étape 2 de « La négociation SSL », le serveur envoie son certificat au client pour s'identifier. Le client utilise le certificat serveur lors de l'étape 3 pour authentifier l'identité du serveur que le certificat est supposé représenter.

Pour authentifier le lien existant entre la clef publique et le serveur identifié par le certificat contenant cette clef, un client SSL doit recevoir un « Oui » comme réponse aux quatre questions décrites dans la Figure 2. Bien que la quatrième question ne fasse pas techniquement partie du protocole SSL, il est de la responsabilité du client d'implémenter cette option, qui donne une plus grande assurance quant à l'identité du serveur et aide ainsi à le protéger contre des attaques de type «Man-in-the-Middle ».

Figure 2. Authentification d'un certificat client

Un client SSL doit valider toutes ces étapes pour authentifier l'identité d'un serveur :

  1. La date du jour courant est-elle dans la période de validité ? Le client vérifie la période de validité du certificat serveur. Si la date du jour courant est en dehors de cette période de validité, le processus d'authentification n'ira pas plus loin. Dans le cas contraire, le client continue le processus d'authentification.
  2. L'AC émettrice est-elle une AC de confiance ? Chaque client SSL possède une liste de certificat d'AC de confiance, représentée par le cadre ombré sur la droite de la figure 3. Cette liste détermine quels certificats serveur le client acceptera. Si le nom distinct (DN ou distinguished name en anglais) de l'AC émettrice correspond au DN d'une AC de confiance présente dans la liste du client, la réponse à la question sera « Oui », et le client passera à l'étape 3. Si l'AC émettrice n'est pas dans la liste, le serveur ne sera pas authentifié à moins que le client ne vérfie a certificate chain ending dans le certificat se trouvant dans la liste.
  3. La clef publique de l'AC émettrice valide-t-elle la signature numérique de l'émetteur ? Le client utilise la clef publique provenant du certificat de l'AC (trouve dans sa liste des AC de confiance à l'étape 2) pour valider la signature numérique de l'AC présente dans le certificat serveur qui lui est présenté. Si l'information du certificat serveur a été modifiée depuis qu'elle a été signée par l'AC ou si la clef publique du certificat d'AC ne correspond pas à la clef privée utilisée par l'AC pour signée le certificat serveur, le client n'authentifiera pas l'identité du serveur. Si la singature numérique de l'AC peut être validée, le serveur traite le certificat client comme une « lettre de recommandation » valide de la part de l'AC et poursuit le processus. À ce moment, le client a déterminé que le certificat serveur est valide. Il est désormais de sa responsabilité de procéder à l'étape 4 avant de passer à l'étape 5.
  4. Le nom de domaine présent dans le certificat serveur correspond-il au nom de domaine du serveur ? Cette étape confirme que le serveur est bien localisé à l'adresses réseau spécifiée par le nom de domaine du certificat serveur. Bien que cette étape ne fasse pas partie du protocole SSL, elle fournit l'unique protection contre une attaque de type «Man-in-the-midlle ». Les clients doivent exécuter cette étape et ils doivent refuser d'authentifier un serveur ou d'établir une connexion si le nom de domaine ne correspond pas. Si le nom de domaine du serveur correspond à celui présent dans le certificat serveur, alors le client peut procéder à l'étape 5.
  5. Le serveur est authentifié. Le client procède à la négociation SSL. Si le client n'exécute pas l'étape 5, quelle qu'en soit la raison, le serveur identifié par le certificat ne pourra pas être authentifié, et l'utilisateur sera averti du problème et informé qu'une connexion chiffrée et authentifiée ne pourra pas être établie. Si le serveur requiert une authentification client, il exécutera les étapes décrites dans la section « Authentification client ».

Après les étapes décrites ici, le serveur doit réussir à utiliser sa clef privée pour décrypter le premaster secret que le client lui envoie lors de l'étape 4 de « La négociation SSL ». Dans le cas contraire, la session SSL se terminera. Ceci fournit l'assurance que l'identité associée à la clef privée présente dans le certificat serveur est bien celle du serveur auquel le client est connecté.

Attaque du type « Man-in-the-Middle » (l'homme-au-milieu)

Tel que suggéré dans l'étape 4 ci-dessus, l'application cliente doit comparer le nom de domaine du serveur, spécifié dans le certificat serveur, avec le nom de domaine du serveur auquel le client essaye de se connecter. Cette étape est nécessaire pour protéger la communication contre une attaque de type « Man-in-the-Middle » qui fonctionne comme expliqué ci-dessous.

L'« homme au milieu » est une programme parasite qui intercepte toutes les communications entre le client et le serveur avec lequel il veut établir une connexion SSL. Ce programme intercepte les clefs légitimes qui sont échangées dans les deux sens, leur substitue ses propres clefs, et se fait passer pour le serveur auprès du client, et pour le client auprès du serveur.

Les informations chiffrées échangées au commencement de la négociation SSL sont alors chiffrées avec la clef publique du programme parasite ou avec sa clef privée, en remplacement de celles du client, ou du serveur. Le programme parasite finit par établir un premier ensemble de clefs de session à utiliser avec le véritable serveur, puis un second ensemble à utiliser avec le client. Ceci permet au programme parasite de lire non seulement toutes les données transmises entre le client et le serveur, mais également de modifier ces données sans que cela ne soit détecté. Il est donc très important pour le client de vérifier que le nom de domaine du certificat serveur correspond effectivement au nom de domaine du serveur avec lequel il tente de communiquer, en plus de vérifier la validité du certificat en procédant aux autres étapes décrites dans la section « Authentification serveur ».

Authentification client

Les serveurs SSL peuvent être configurés pour exiger une authentification client, ou une validation cryptographique de l'identité du client par le serveur. Un serveur ainsi configuré demande l'authentification du client (voir l'étape 6 de « La négociation SSL »), le client envoie au serveur un certificat et des données signées numériquement pour s'authentifier. Le serveur utilise les données signées numériquement pour valider la clef publique dans le certificat et pour authentifier l'identité que le certificat est supposé représenter.

Le protocole SSL requiert que le client crée une signature numérique en créant une empreinte numérique unidirectionnelle générée aléatoirement pendant la négociation et connues uniquement du client et du serveur. L'empreinte numérique des données est alors chiffrée avec la clef privée correspondant à la clef publique du certificat soumis au serveur.

Pour authentifier le lien entre la clef publique et la personne ou tout autre entité identifiée par le certificat contenant la clef publique, un serveur SSL doit recevoir la réponse « Oui » aux quatre premières questions représentées sur la Figure 3. Bien que la cinquième question ne fasse pas partie du protocole SSL, les serveurs Red Hat peuvent être configurés pour la poser afin de tirer avantage de l'enregistrement de l'utilisateur dans un répertoire LDAP lors du processus d'authentification.

Figure 3. Authentification et vérification du certificat client

Un serveur SSL suit ces étapes pour authentifier l'identité d'un utilisateur :

  1. La clef publique de l'utilisateur correspond-elle à sa signature numérique ? Le serveur vérifie que la signature numérique de l'utilisateur peut être validée par la clef publique présente dans le certificat. Si oui, le serveur établit que la clef publique supposée appartenir à John Doe correspond à la clef privée utilisée pour la création de la signature et que les données n'ont pas été corrompues depuis qu'elle a été créée.
Cependant, lors de cette étape, le lien entre la clef publique et le {{template.Abbr("DN", "Nom distinctif")}} spécifié dans le certificat n'est pas encore établi. Le certificat a pu être créé par quelqu'un essayant d'usurper l'identité de l'utilisateur. Pour valider le lien entre la clef publique et le {{template.Abbr("DN", "Nom distinctif")}}, le serveur doit également compléter les étapes 3 et 4.
  1. La date de fin de période de validité est-elle dépassée ? Le serveur vérifie la période de validité du certificat. Si la date et l'heure ne sont pas dans cette période, le processus d'authentification s'arrête. Dans le cas contraire, le serveur exécute l'étape 3.
  1. L'{{template.Abbr("AC", "autorité de certification")}} émettrice est-elle une {{template.Abbr("AC", "autorité de certification")}} de confiance ? Chaque serveur SSL possède une liste de certificats provenant d'{{template.Abbr("AC", "autorités de certification")}} de confiance, représenté par la zone partagée sur la droite de la Figure 3. Cette liste détermine les certificats acceptés par le serveur. Si le DN de l'AC émettrice correspond au DN d'une AC de confiance présente dans la liste du serveur, la réponse à la question est « Oui » et le serveur passe à l'étape 4. Si l'AC émettrice n'est pas dans la liste, le client ne sera pas authentifié, à moins que le serveur ne puisse vérifier a certificate chain ending in a CA qui n'est pas dans la liste. Les administrateurs peuvent contrôler, pour leur organisation, quels certificats seront de confiance ou non en contrôlant les listes de certificats d'AC maintenues par les clients et les serveurs.
  1. La clef publique de l'{{template.Abbr("AC", "autorité de certification")}} émettrice correspond-elle à sa signature numérique ? Le serveur utilise la clef publique du certificat d'{{template.Abbr("AC", "autorité de certification")}} (qui a été trouvé dans la liste des AC de confiance à l'étape 3) pour valider la signature numérique de l'{{template.Abbr("AC", "autorité de certification")}} dans le certificat présenté. Si l'information contenue dans le certificat a été modifiée depuis qu'il a été signé par l'AC ou si la clef publique incluse avec le certificat ne correspondent pas à la signature numérique utilisée par l'AC pour signer le certificat, alors le serveur n'authentifiera pas l'identité de l'utilisateur. Si la signature numérique de l'AC peut être validée, le serveur traite le certificat de l'utilisateur comme « lettre de recommandation » valide de la part de l'AC et continue le processus. À partir d'ici, le protocole SSL autorise le serveur à considérer le client comme authentifié et procède à la connexion telle que décrite à l'étape 6. Les serveurs Red Hat peuvent éventuellement être configurés pour exécuter l'étape 5 avant l'étape 6.
  1. Le certificat de l'utilisateur est-il listé dans les entrées LDAP ? Cette étape optionnelle fournit un moyen aux administrateurs système de révoquer un certificat utilisateur même si celui-ci valide toutes les conditions du test. Le Red Hat Certificate System peut supprimer automatiquement un certificat révoqué des données concernant l'utilisateur dans le répertoire LDAP. Tous les serveurs configurés pour exécuter cette étape refuseront alors d'authentifier ce certificat ou d'établir une connexion. Si le certificat utilisateur présent dans le répertoire est identique à celui présenté par l'utilisateur lors de la négociation SSL, alors le serveur passera à l'étape 6.
  1. Le client authentifié est-il autorisé à accéder aux ressources demandées ? Le serveur vérifie les ressources auxquelles l'utilisateur est autoriser à accéder selon les listes de contrôle d'accès du serveur (ACLs) et il établit la connexion avec les droits d'accès appropriés. Si, pour une raison ou une autre, le serveur n'exécute pas l'étape 6, l'utilisateur identifié ne peut pas être authentifié et il ne sera pas autorisé à accéder aux ressources du serveur requérant l'authentification.

Informations sur le document original

  • Auteur(s) : {{mediawiki.external('Author Names')}}
  • Autres contributeurs: Giacomo Magnini
  • Dernière mise à jour : 26 septembre 2005
  • Copyright : © 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. All rights reserved.
{{ wiki.languages( { "ja": "ja/Introduction_to_SSL", "en": "en/Introduction_to_SSL" } ) }}

Source de la révision

<p>
{{template.Traduction_en_cours("Introduction to SSL")}}
</p>
<h3 name="Introduction"> Introduction </h3>
<p>Ce document est une introduction au protocole <i>Secure Sockets Layer</i> (SSL). SSL a été universellement adopté par le <i>World Wide Web</i> pour authentifier et crypter les communications entre les clients et les serveurs.
</p>
<ul><li> <a href="#Le_protocole_SSL">Le protocole SSL</a>
</li><li> <a href="#Filtres_utilis.C3.A9s_avec_SSL">Filtres utilisés avec SSL</a>
</li><li> <a href="#La_n.C3.A9gociation_SSL">La négociation SSL</a>
</li></ul>
<p>Le nouveau protocole standard de l'<i>Internet Engineering Task Force</i> (IETF), appelé <i>Transport Layer Security</i> (TLS) est basé sur SSL. Les détails de ce protocole sont disponible dans le document <i>Request For Comments</i> (RFC): 2246, <i><a class="external" href="ftp://ftp.isi.edu/in-notes/rfc2246.txt">The TLS Protocol Version 1.0</a></i>. Certains produits de Red Hat supportent déjà le TLS. La plupart des autres produits de Red Hat prévoient son support dans les futures versions.
</p><p>Ce document est d'abord destiné aux administrateurs de serveurs Red Hat, mais les informations qu'il contient peuvent être tout aussi utiles aux développeurs d'applications supportant SSL. Ce document suppose que vous connaissez les concepts de base de la cryptographie à clef publique, tels que décrit dans « <a href="fr/Introduction_%c3%a0_la_cryptographie_%c3%a0_clef_publique">Introduction à la cryptographie à clef publique</a> ».
</p>
<h3 name="Le_protocole_SSL"> Le protocole SSL </h3>
<p>Le <i>Transmission Control Protocol/Internet Protocol (TCP/IP)</i> définit le transport et le routage des données sur Internet. Les autres protocoles, tels que <i>HyperText Transport Protocol (HTTP)</i>, <i>Lightweight Directory Access Protocol (LDAP)</i>, ou <i>Internet Messaging Access Protocol (IMAP)</i>, s'exécute par "dessus" TCP/IP au sens qu'ils utilisent tous TCP/IP pour supporter les tâches applicatives typiques telles qu'afficher des pages Web ou faire tourner des serveurs de courrier.
</p><p><img align="none" alt="Figure 1. Where SSL Runs" src="File:fr/Media_Gallery/10ssl.gif">
</p><p>Le protocole SSL s'exécute par dessus TCP/IP et en dessous des protocoles de haut niveau tels que HTTP ou IMAP. Il utilise TCP/IP au nom des protocoles de haut niveau, et, lors du processus, il autorise un serveur avec SSL activé à s'authentifier auprès d'un client SSL, il autorise le client à s'authentifier auprès du serveur, et il autorise les deux ordinateurs à établir une connexion chiffrée.
</p><p>Ces possibilités répondent aux soucis fondamentaux concernant les communication par Internet ou tout autre réseau TCP/IP :
</p>
<ul><li> L'authentification du serveur SSL permet à un utilisateur de confirmer l'identité du dit serveur. Les logiciels client SSL peuvent utiliser les techniques standards de cryptographie à clef publique pour vérifier que le certificat d'un serveur et son ID publique sont valides et qu'ils sont listés par une autorité de certification (AC ou Certificate Authority en anglais) faisant partie des AC de confiance définies par le logiciel client. Cette confirmation peut être importante si l'utilisateur, par exemple, utilise sa carte de crédit pour payer une transaction par Internet et qu'il désire vérifier l'identité du serveur récepteur.
</li></ul>
<ul><li> L'authentification d'un client SSL permet à un serveur de confirmer l'identité de l'utilisateur. En utilisant les mêmes techniques que pour l'authentification du serveur, un serveur SSL peut vérifier la validité du certificat client et de son ID publique et qu'ils ont été délivrés par une AC appartenant à la liste des AC de confiance du serveur. Cette confirmation est importante lorsque, par exemple, le serveur d'un banque veut s'assurer de l'identité du destinataire des données.
</li></ul>
<ul><li> Une connexion SSL cryptée, requiert que toutes les informations échangées entre le client et le serveur soient codée par le logiciel émetteur et décodée par le logiciel récepteur, ceci permettant un haut degré de confidentialité. La confidentialité est important pour les deux parties pour toutes les transactions privées. De plus, toutes les données transmises lors d'une connexion SSL cryptée sont protégées par un mécanisme détectant les altérations, pour déterminer automatiquement si les données ont été modifiées pendant la transmission.
</li></ul>
<p>Le protocole SSL inclus deux sous-protocoles : le protocole <i>SSL record</i> et le protocole <i>SSL handshake</i> (négociation SSL). Le protocole <i>SSL record</i> définit le format utilisé pour la transmission de données. Le protocole de négociation SSL implique d'utiliser le protocole <i>SSL record</i> pour échanger une série de messages entre un serveur SSL et un client SSL lorsqu'ils établissent la première connexion SSL. Cet échange de messages est destiné à faciliter les actions suivantes :
</p>
<ul><li> Authentifier le serveur auprès du client.
</li><li> Autoriser le client et le serveur à sélectionner un algorithme de cryptage, ou de chiffrement, supporter par chacun d'eux.
</li><li> Éventuellement, authentifier le client auprès du serveur.
</li><li> Utiliser les techniques de cryptographie à clef publique pour générer des <i>secrets partagés</i>.
</li><li> Établir un connexion SSL cryptée.
</li></ul>
<p>Pour plus d'informations à propos du processus de négociation, voir la section "<a href="#La_n.C3.A9gociation_SSL">La négociation SSL</a>."
</p>
<h3 name="Chiffrements_utilis.C3.A9s_avec_SSL"> Chiffrements utilisés avec SSL </h3>
<p>Le protocole SSL supporte l'utilisation d'un grand nombre d'algorithme de cryptographie, ou de chiffrements, pour des usages tels l'authentification réciproque entre un serveur et un client, la transmission de certificat, et l'établissement d'une session sécurisée. Les clients et les serveurs peuvent supporter différentes suites de chiffrement, ou paramètres de chiffrements, selon des facteurs tels que la version de SSL qu'ils intègrent, la politique d'entreprise concernant la force de cryptage acceptable et les restrictions gouvernementales sur l'exportation de logiciels SSL. Parmi ses autres fonctions, le protocole de négociation SSL détermine la façon dont le serveur et le client négocient la suite de chiffrement à utiliser pour s'authentifier l'un à l'autre, pour transmettre des certificats et pour établir des sessions sécurisées.
</p><p>Les algorithmes par échange de clef, tels que KEA et RSA, dirigent la manière dont le serveur et le client vont déterminer les clefs symétriques que chacun d'eux utilisera pendant la session SSL. Les suites de chiffrement les plus couramment utilisées se servent de clefs d'échange RSA.
</p><p>Les protocoles SSL 2.0 et SSL 3.0 autorisent la redondance des paramètres de suites de chiffrement. Les administrateurs peuvent activer ou désactiver chaque suite de chiffrement supportée par les clients ou les serveurs. Lorsqu'un client et un serveur s'échangent des informations à l'établissement de la négociation SSL, ils identifient les plus fortes suites de chiffrement autorisées qu'ils ont en commun pour les utiliser lors de la session SSL.
</p>
<div class="note"><b>Note :</b> Dans Firefox 2, le support de SSL 2.0 est désactivé par défaut, en faveur de SSL 3.0.  Voir l'article <a href="fr/La_s%c3%a9curit%c3%a9_dans_Firefox">La sécurité dans Firefox</a> pour plus d'informations.</div>
<p>La décision d'une organisation concernant les suites de chiffrement activer dépend de critères tels que la sensibilités des données à échanger, la rapidité du chiffrement et des conditions d'application des régles d'exportation.
</p><p>Certaines organisations peuvent vouloir désactiver les chiffrement les plus faibles pour empêcher les connexions SSL avec des cryptage faible. Cependant, à cause de restrictions imposées par le gouvernement étasunien sur les produits supportant un cryptage de plus de 40-bit, désactiver le support de tous les chiffrements 40-bit restreindra l'accés au réseau aux seuls navigateurs provenant des États-Unis (à moins que le serveur n'ait une <i>Global Server ID</i> qui permette aux clients internationaux d'utiliser un cryptage plus fort).
</p><p>Pour satisfaire une plus grande portion possible d'utilisateur, il est préférable pour les administrateurs d'activer le plus grand nombre de suites de chiffrement possibles. Ainsi, lorsqu'un client ou un serveur domestique se connectera avec, respectivement, un serveur ou un client domestique, il essayera d'utiliser le plus fort chiffrement disponible. Et lorsque le le client ou le serveur domestique se connectera avec un serveur ou un client international, il négociera l'utilisation de chiffrements autorisés par les lois d'exportations étasuniennes.
</p><p>Cependant, comme les chiffrements 40-bit peuvent être cassés très rapidement, les administrateurs dont les utilisateurs peuvent utiliser de plus forts chiffrements sans déroger aux règles d'exportation devraient désactiver les chiffrements 40-bit s'ils sont soucieux à propos de l'accès au données par des personnes tiers non autorisées.
</p>
<div class="note">Red Hat <i>Console</i> ne supporte pas toutes les suites de chiffrement intégrer par les serveurs et les clients Red Hat. Pour s'assurer que Red Hat Console peut contrôler un serveur SSL, le serveur doit autoriser au moins une des suites de chiffrement pour SSL 3.0 suivantes :
<ul><li> RC4 avec chiffrement 128-bit et message d'authentification MD5
</li><li> RC4 avec chiffrement 40-bit et message d'authentification MD5
</li><li> RC2 avec chiffrement 40-bit et message d'authentification MD5
</li><li> Pas de chiffrement, uniquement message d'authentification MD5</li></ul></div>

<h4 name="Suites_de_chiffrement_avec_clef_d.27.C3.A9change_RSA"> Suites de chiffrement avec clef d'échange RSA </h4>
<p>Le tableau 1 liste les suites de chiffrement supportées par SSL utilisant un algorithme à clef d'échange RSA. À moins que cela ne soit indiqué, tous les chiffrements listés dans ce tableau sont supportés par les protocoles SSL 2.0 et SSL 3.0. Les suites de chiffrement sont listées du plus haut au plus bas niveau de chiffrement.
</p>
<table border="1" cellpadding="5">
<caption>  <b>Table 1.</b> Suites de chiffrement supportées par le protocole SSL utilisant un algorithme de clef d'échange RSA
</caption>
<tbody><tr bgcolor="#cccccc">
<th>
<div class="TableTitle">Niveau de chiffrement et usage recommandé</div>
</th><th>
<div class="TableTitle">Suites de chiffrement</div>
</th></tr>
<tr>
<td> <b>Chiffrement de très haut niveau</b> Permitted for deployments within the United States only. This cipher suite is appropriate for banks and other institutions that handle highly sensitive data. Red Hat Console does not support this cipher suite.
</td><td> <b>Chiffrement 168-Bit triple DES et message d'authentification SHA-1</b> Triple DES is the strongest cipher supported by SSL, but it is not as fast as RC4. Triple DES uses a key three times as long as the key for standard DES. Because the key size is so large, there are more possible keys than for any other cipher-approximately 3.7 * 10<sup>50</sup>. This cipher suite is FIPS-compliant. Both SSL 2.0 and SSL 3.0 support this cipher suite.
</td></tr>
<tr>
<td rowspan="3" valign="top"> <b>Chiffrement de haut niveau</b> Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs.
</td><td> <b>Chiffrement 128-Bit avec RC4 et message d'authentification MD5</b> Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 10<sup>38</sup> possible keys, making them very difficult to crack. RC4 ciphers are the fastest of the supported ciphers. Both SSL 2.0 and SSL 3.0 support this cipher suite. Red Hat Console supports only the SSL 3.0 version of this cipher suite.
</td></tr>
<tr>
<td> <b>Chiffrement 128-Bit avec RC2 et message d'authentification MD5</b> Because the RC4 and RC2 ciphers have 128-bit encryption, they are the second strongest next to Triple DES (Data Encryption Standard), with 168-bit encryption. RC4 and RC2 128-bit encryption permits approximately 3.4 * 10<sup>38</sup> possible keys, making them very difficult to crack. RC2 ciphers are slower than RC4 ciphers. This cipher suite is supported by SSL 2.0 but not by SSL 3.0. Red Hat Console does not support this cipher suite.
</td></tr>
<tr>
<td> <b>Chiffrement 56-Bit avec DES et message d'authentification SHA-1</b> DES is stronger than 40-bit encryption, but not as strong as 128-bit encryption. DES 56-bit encryption permits approximately 7.2 * 10<sup>16</sup> possible keys. This cipher suite is FIPS-compliant. Both SSL 2.0 and SSL 3.0 support this cipher suite, except that SSL 2.0 uses MD5 rather than SHA-1 for message authentication. Red Hat Console does not support this cipher suite.
</td></tr>
<tr>
<td rowspan="2" valign="top"> <b>Chiffrements exportables</b> These cipher suites are not as strong as those listed above, but may be exported to most countries (note that France permits them for SSL but not for S/MIME). They provide the strongest encryption available for exportable products.<a href="#15631"><sup>1</sup></a>
</td><td> <b>RC4 With 40-Bit Encryption and MD5 Message Authentication</b> RC4 40-bit encryption permits approximately 1.1 * 10<sup>12</sup> (a trillion) possible keys. RC4 ciphers are the fastest of the supported ciphers. Both SSL 2.0 and SSL 3.0 support this cipher. Red Hat Console supports only the SSL 3.0 version of this cipher suite.
</td></tr>
<tr>
<td> <b>Chiffrement 40-bit avec RC2 et message d'authentification MD5</b> RC2 40-bit encryption permits approximately 1.1 * 10<sup>12</sup> (a trillion) possible keys. RC2 ciphers are slower than the RC4 ciphers. Both SSL 2.0 and SSL 3.0 support this cipher. Red Hat Console supports only the SSL 3.0 version of this cipher suite.
</td></tr>
<tr>
<td> <b>Chiffrement de bas niveau</b> This cipher suite provides authentication and tamper detection but no encryption. Server administrators must be careful about enabling it, however, because data sent using this cipher suite is not encrypted and may be accessed by eavesdroppers.
</td><td> <b>Pas de chiffrement, uniquement message d'authentification MD5</b> This cipher suite uses MD5 message authentication to detect tampering. It is typically supported in case a client and server have none of the other ciphers in common. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
</td></tr></tbody></table>
<table>
<tbody><tr>
<td>
<p><sup>1</sup> Notez que pour les chiffrements RC4 et RC2, le terme "chiffrement 40-bit" signifie que les clefs sont en 128 bits, mais que seuls 40 bits ont une signification cryptographique.
</p>
</td></tr></tbody></table>
<h4 name="Suites_de_chiffrement_de_Fortezza"> Suites de chiffrement de Fortezza </h4>
<p>Le tableau 2 liste les suites de chiffrement additionnelles supportées par les produits Red Hat intégrant Fortezza. Pour SSL 3.0 Fortezza est un système de cryptage utilisé par les agences gouvernementales étasuniennes pour la gestion des informations sensibles, mais déclassifiées. Il fournit une implémentation hardware de 2 chiffrements classifiés, développés par le gouvernement fédéral étasunien : Fortezza KEA et SKIPJACK. Les chiffrements Fortezza pour SSL utilise un algorithme par clef d'échange (KEA) plutôt qu'un algorithme de clef d'échange RSA mentionné dans la précédente section, et il utilise les cartes Fortezza et DSA pour l'authentification client.
</p>
<table border="1" cellpadding="5">
<caption> <b>Tableau 2.</b> Suites de chiffrement supportées par Red Hat lors de l'utilisation de Fortezza pour SSL 3.0
</caption>
<tbody><tr bgcolor="#cccccc">
<th> Niveau de chiffrement et usage recommandé
</th><th> Suites de chiffrement
</th></tr>
<tr>
<td rowspan="2" valign="top"> <b>Suites de chiffrement Fortezza haut niveau</b> Autorisé pour un déploiement uniquement aux États-Unis. Ces suites de chiffrement supportent un chiffrement d'assez haut niveau pour la plupart des besoin commerciaux et gouvernementaux. <i>Red Hat Console</i> n'intègre pas ces suites de chiffrement.
</td><td> <b>Chiffrement 128-Bit avec RC4 et message d'authentification SHA-1</b> Comme le chiffrement 128-Bit avec RC4 et message d'authentification MD5, ce chiffrement est un des deux plus fort chiffrements après le Triple DES. Il permet approximativement 3.4 * 10<sup>38</sup> clefs, le rendant très difficile à briser. Cette suite de chiffrement est supportée par le protocole SSL 3.0 mais pas par SSL 2.0.
</td></tr>
<tr>
<td> <b>Chiffrement 80-bit RC4 avecSKIPJACK et message d'authentification SHA-1</b> Le chiffrement SKIPJACK est un algorithme cryptographique à clefs symétriques classifié, implémenté dans les matériels compatibles Fortezza. Certaines implémentations de SKIPJACK supportent les clefs tierce partie utilisant le <i>Law Enforcement Access Field</i> (LEAF). Les plus récentes implémentations ne les supportent pas. Cette suite de chiffrement est supportée par le protocole SSL 3.0 mais pas par SSL 2.0.
</td></tr>
<tr>
<td> <b>Suites de chiffrement Fortezza bas niveau</b> Cette suite de chiffrement fournit l'authentification et la détection des altérations mais pas l'encryptage des données. Les administrateurs de serveurs doivent être très prudents concernant son activation, du fait que les données transmises avec cette suites de chiffrement ne sont pas encryptées et qu'elles sont potentiellement accessibles à de personnes tierces espionnant le réseau. Red Hat <i>Console</i> ne supporte pas ces suites de chiffrement.
</td><td> <b>Pas de chiffrement, message d'authentification SHA-1 uniquement</b> Ce chiffrement utilise le message d'authentification SHA-1 pour détecter les altérations de données. Cette suite de chiffrement est supportées par le protole SSL 3.0 mais pas par SSL 2.0.
</td></tr></tbody></table>
<h3 name="La_n.C3.A9gociation_SSL"> La négociation SSL </h3>
<p>Le protocole SSL utilise une combinaison de clef publique et de cryptage par clef symétrique. Le cryptage par clef symétrique est plus rapide que le cryptage par clef publique, cependant, le cryptage par clef publique fournit de bien meilleures techniques d'authentification. Une session SSL débute toujours par un échange de messages appelé <i>négociation SSL</i>. La négociation permet au serveur de s'authentifier auprès du client en utilisant les techniques par clef publique, puis autorise le client et le serveur à coopérer pour la création de clefs symétriques utilisées pour le cryptage rapide, le décryptage, et la détection de l'altération des données pendant la session qui suit. Éventuellement, la négociation SSL peut également permettre au client de s'authentifier auprès du serveur.
</p><p>Les détails programmatiques exacts des messages échangés pendant la négociation SSL fait parti des objectifs de ce document. Cependant, les étapes mises en œuvre peuvent être résumées comme suit (en admettant l'utilisation de suites de chiffrement listées à la section « <a href="#Suites_de_chiffrement_avec_clef_d.27.C3.A9change_RSA">Suites de chiffrement avec clef d'échange RSA</a> ») :
</p>
<ol><li> Le client envoie au serveur sa version de SSL, ses paramètres de chiffrement, des données générées aléatoirement, et toutes autres informations dont le serveur à besoin pour communiquer avec lui en utilisant SSL.
</li><li> Le serveur envoie au client sa version de SSL ses paramètres de chiffrement, des données générées aléatoirement, et toutes autres informations dont le client à besoin pour communiquer avec lui en utilisant SSL. Le serveur envoie également son propre certificat et, si le client demande une ressource serveur nécessitant une authentification client, il demande le certificat client.
</li><li> Le client utilise certaines informations envoyées par le serveur pour l'authentifier (pour plus d'informations, voir la section « <a href="#Authentification_serveur">Authentification serveur</a> »). Si le serveur ne peut pas être authentifié, l'utilisateur est averti du problème et il est informé que la connexion chiffrée et authentifiée ne peut pas être établie. Si le serveur peut être correctement authentifié, le client procède alors à l'étape 4.
</li><li> En utilisant toutes les données générées pendant la négociation SSL, le client (avec la coopération du serveur, suivant les chiffrements utilisés) crée un <b>premaster secret</b> pour la session, le chiffre avec la clef publique du serveur (obtenue dans le certificat du serveur envoyé à l'étape 2), et envoie le <b>premaster secret</b> chiffré au serveur.
</li><li> Si le serveur requiert une authentification client (une étape optionnelle dans la négociation), le client doit alors signer une autre portion de données limitée à cette négociation et connue par le client et le serveur. Dans ce cas, le client envoie les données chiffrées et son propre certificat au serveur ainsi que le <b>premaster secret</b> chiffré.
</li><li> Si le serveur a requis une authentification client, il tente cette authentification (pour plus d'information, voir la section « <a href="#Authentification_client">Authentification client</a> »). Si le client ne peut être authentifié, alors la session prend fin. Si le client est authentifié avec succès, le serveur utilise sa clef privée pour déchiffrer le <b>premaster secret</b>, puis procéder à une série d'étapes (également exécutée par le client, à partir du même <b>premaster secret</b>) pour générer le <b>master secret</b>.
</li><li> Le client et le serveur utilise tout les deux, le <b>the master secret</b> pour générer des <i>clefs de sessions</i>, qui sont des clefs symétriques utilisées pour chiffrer et déchiffrer les informations échangées pendant la session SSL et pour vérifier leur intégrité, afin de détecter tout changement intervenu dans les données entre leur envoie et leur réception durant la connexion SSL.
</li><li> Le client envoie un message au serveur pour l'informer que les futures données transmises seront chiffrées avec la clef de session. Il envoie alors séparément un message (chiffré) indiquant que la négociation côté client est finie.
</li><li> Le serveur envoie un message au client pour l'informer que les futures données transmises seront chiffrées avec la clef de session. Il envoie alors séparément un message chiffré indiquant que la négociation SSL côté serveur est finie.
</li><li> La négociation SSL est maintenant terminée et la session SSL peut commencer. Le client et le serveur utilisent les clefs de session pour crypter et décrypter les données échangées et pour valider leur intégrité.
</li></ol>
<p>Avant d'aller plus loin dans la session, les serveurs Red Hat peuvent être configurés pour vérifier que le certificat client est présent dans les données de l'utilisateur dans le répertoire LDAP. Cette option de configuration fournit un moyen sûr de savoir si le certificat client n'a pas été révoqué.
</p><p>Il est important de retenir que l'authentification du serveur comme celle du client entraîne le cryptage de certaines données à l'aide d'une clef, privée ou publique, et leur décryptage à l'aide de l'autre clef :
</p>
<ul><li> Dans le cas d'une authentification serveur, le client chiffre le <b>premaster secret</b> avec la clef publique du serveur. Seule la clef privée correspondante pourra déchiffrer correctement ce <i>secret</i>, ainsi le client sera assuré que l'identité associée à la clef publique est bien celle du serveur avec lequel il est connecté. Dans le cas contraire, le serveur ne pourra pas déchiffrer le <b>premaster secret</b> et ne pourra pas générer les clefs symétriques requises pour la session et celle-ci se terminera.
</li><li> Dans le cas d'une authentification client, le client chiffre certaines données aléatoires avec ses clef privée, créant ainsi une signature numérique. La clef publique du certificat client peut correctement valider cette signature suelement si elle correspond à la clef privée utilisée. Dans le cas contraire, le serveur ne pourra pas valider la signature numérique et la session se terminera.
</li></ul>
<p>Les sections ci-dessous fournissent plus de détails concernant les authentifications serveur et client.
</p>
<h4 name="Authentification_serveur"> Authentification serveur </h4>
<p>Les logiciels client SSL de Red Hat requirent toujours une authentification client ou une validation cryptographique de l'identité du serveur par le client. Comme expliqué à l'étape 2 de « <a href="#La_n.C3.A9gociation_SSL">La négociation SSL</a> », le serveur envoie son certificat au client pour s'identifier. Le client utilise le certificat serveur lors de l'étape 3 pour authentifier l'identité du serveur que le certificat est supposé représenter.
</p><p>Pour authentifier le lien existant entre la clef publique et le serveur identifié par le certificat contenant cette clef, un client SSL doit recevoir un « Oui » comme réponse aux quatre questions décrites dans la Figure 2. Bien que la quatrième question ne fasse pas techniquement partie du protocole SSL, il est de la responsabilité du client d'implémenter cette option, qui donne une plus grande assurance quant à l'identité du serveur et aide ainsi à le protéger contre des attaques de type «Man-in-the-Middle ».
</p><p><img align="none" alt="Figure 2. Authentification d'un certificat client" src="File:fr/Media_Gallery/11svauth.gif">
</p><p>Un client SSL doit valider toutes ces étapes pour authentifier l'identité d'un serveur :
</p>
<ol><li> <b>La date du jour courant est-elle dans la période de validité ?</b> Le client vérifie la période de validité du certificat serveur. Si la date du jour courant est en dehors de cette période de validité, le processus d'authentification n'ira pas plus loin. Dans le cas contraire, le client continue le processus d'authentification.
</li><li> <b>L'AC émettrice est-elle une AC de confiance ?</b> Chaque client SSL possède une liste de certificat d'AC de confiance, représentée par le cadre ombré sur la droite de la figure 3. Cette liste détermine quels certificats serveur le client acceptera. Si le nom distinct (DN ou distinguished name en anglais) de l'AC émettrice correspond au DN d'une AC de confiance présente dans la liste du client, la réponse à la question sera « Oui », et le client passera à l'étape 3. Si l'AC émettrice n'est pas dans la liste, le serveur ne sera pas authentifié à moins que le client ne vérfie <b>a certificate chain ending</b> dans le certificat se trouvant dans la liste.
</li><li> <b>La clef publique de l'AC émettrice valide-t-elle la signature numérique de l'émetteur ?</b> Le client utilise la clef publique provenant du certificat de l'AC (trouve dans sa liste des AC de confiance à l'étape 2) pour valider la signature numérique de l'AC présente dans le certificat serveur qui lui est présenté. Si l'information du certificat serveur a été modifiée depuis qu'elle a été signée par l'AC ou si la clef publique du certificat d'AC ne correspond pas à la clef privée utilisée par l'AC pour signée le certificat serveur, le client n'authentifiera pas l'identité du serveur. Si la singature numérique de l'AC peut être validée, le serveur traite le certificat client comme une « lettre de recommandation » valide de la part de l'AC et poursuit le processus. À ce moment, le client a déterminé que le certificat serveur est valide. Il est désormais de sa responsabilité de procéder à l'étape 4 avant de passer à l'étape 5.
</li><li> <b>Le nom de domaine présent dans le certificat serveur correspond-il au nom de domaine du serveur ?</b> Cette étape confirme que le serveur est bien localisé à l'adresses réseau spécifiée par le nom de domaine du certificat serveur. Bien que cette étape ne fasse pas partie du protocole SSL, elle fournit l'unique protection contre une attaque de type «Man-in-the-midlle ». Les clients doivent exécuter cette étape et ils doivent refuser d'authentifier un serveur ou d'établir une connexion si le nom de domaine ne correspond pas. Si le nom de domaine du serveur correspond à celui présent dans le certificat serveur, alors le client peut procéder à l'étape 5.
</li><li> <b>Le serveur est authentifié.</b> Le client procède à la négociation SSL. Si le client n'exécute pas l'étape 5, quelle qu'en soit la raison, le serveur identifié par le certificat ne pourra pas être authentifié, et l'utilisateur sera averti du problème et informé qu'une connexion chiffrée et authentifiée ne pourra pas être établie. Si le serveur requiert une authentification client, il exécutera les étapes décrites dans la section  « <a href="#Authentification_client">Authentification client</a> ».
</li></ol>
<p>Après les étapes décrites ici, le serveur doit réussir à utiliser sa clef privée pour décrypter le <b>premaster secret</b> que le client lui envoie lors de l'étape 4 de « <a href="#La_n.C3.A9gociation_SSL">La négociation SSL</a> ». Dans le cas contraire, la session SSL se terminera. Ceci fournit l'assurance que l'identité associée à la clef privée présente dans le certificat serveur est bien celle du serveur auquel le client est connecté.
</p>
<h4 name="Attaque_du_type_.C2.AB_Man-in-the-Middle_.C2.BB_.28l.27homme-au-milieu.29"> Attaque du type « Man-in-the-Middle » (l'homme-au-milieu) </h4>
<p>Tel que suggéré dans l'étape 4 ci-dessus, l'application cliente doit comparer le nom de domaine du serveur, spécifié dans le certificat serveur, avec le nom de domaine du serveur auquel le client essaye de se connecter. Cette étape est nécessaire pour protéger la communication contre une attaque de type « Man-in-the-Middle » qui fonctionne comme expliqué ci-dessous.
</p><p>L'« homme au milieu » est une programme parasite qui intercepte toutes les communications entre le client et le serveur avec lequel il veut établir une connexion SSL. Ce programme intercepte les clefs légitimes qui sont échangées dans les deux sens, leur substitue ses propres clefs, et se fait passer pour le serveur auprès du client, et pour le client auprès du serveur.
</p><p>Les informations chiffrées échangées au commencement de la négociation SSL sont alors chiffrées avec la clef publique du programme parasite ou avec sa clef privée, en remplacement de celles du client, ou du serveur. Le programme parasite finit par établir un premier ensemble de clefs de session à utiliser avec le véritable serveur, puis un second ensemble à utiliser avec le client. Ceci permet au programme parasite de lire non seulement toutes les données transmises entre le client et le serveur, mais également de modifier ces données sans que cela ne soit détecté. Il est donc très important pour le client de vérifier que le nom de domaine du certificat serveur correspond effectivement au nom de domaine du serveur avec lequel il tente de communiquer, en plus de vérifier la validité du certificat en procédant aux autres étapes décrites dans la section « <a href="#Authentification_serveur">Authentification serveur</a> ».
</p>
<h4 name="Authentification_client"> Authentification client </h4>
<p>Les serveurs SSL peuvent être configurés pour exiger une authentification client, ou une validation cryptographique de l'identité du client par le serveur. Un serveur ainsi configuré demande l'authentification du client (voir l'étape 6 de « <a href="#La_n.C3.A9gociation_SSL">La négociation SSL</a> »), le client envoie au serveur un certificat et des données signées numériquement pour s'authentifier. Le serveur utilise les données signées numériquement pour valider la clef publique dans le certificat et pour authentifier l'identité que le certificat est supposé représenter.
</p><p>Le protocole SSL requiert que le client crée une signature numérique en créant une empreinte numérique unidirectionnelle générée aléatoirement pendant la négociation et connues uniquement du client et du serveur. L'empreinte numérique des données est alors chiffrée avec la clef privée correspondant à la clef publique du certificat soumis au serveur.
</p><p>Pour authentifier le lien entre la clef publique et la personne ou tout autre entité identifiée par le certificat contenant la clef publique, un serveur SSL doit recevoir la réponse  « Oui » aux quatre premières questions représentées sur la Figure 3. Bien que la cinquième question ne fasse pas partie du protocole SSL, les serveurs Red Hat peuvent être configurés pour la poser afin de tirer avantage de l'enregistrement de l'utilisateur dans un répertoire LDAP lors du processus d'authentification.
</p><p><img align="none" alt="Figure 3. Authentification et vérification du certificat client" src="File:fr/Media_Gallery/04cert.gif">
</p><p>Un serveur SSL suit ces étapes pour authentifier l'identité d'un utilisateur :
</p>
<ol><li> <b>La clef publique de l'utilisateur correspond-elle à sa signature numérique ?</b> Le serveur vérifie que la signature numérique de l'utilisateur peut être validée par la clef publique présente dans le certificat. Si oui, le serveur établit que la clef publique supposée appartenir à John Doe correspond à la clef privée utilisée pour la création de la signature et que les données n'ont pas été corrompues depuis qu'elle a été créée.
</li></ol>
<div style="margin: 0pt 0pt 7pt 90pt; color: rgb(0, 0, 0); font-style: normal; font-weight: normal; text-align: left; text-decoration: none; text-indent: 0pt; text-transform: none; vertical-align: baseline;">Cependant, lors de cette étape, le lien entre la clef publique et le <i>{{template.Abbr("DN", "Nom distinctif")}}</i> spécifié dans le certificat n'est pas encore établi. Le certificat a pu être créé par quelqu'un essayant d'usurper l'identité de l'utilisateur. Pour valider le lien entre la clef publique et le <i>{{template.Abbr("DN", "Nom distinctif")}}</i>, le serveur doit également compléter les étapes 3 et 4.</div>
<ol><li> <b>La date de fin de période de validité est-elle dépassée ?</b> Le serveur vérifie la période de validité du certificat. Si la date et l'heure ne sont pas dans cette période, le processus d'authentification s'arrête. Dans le cas contraire, le serveur exécute l'étape 3.
</li></ol>
<ol><li> <b>L'{{template.Abbr("AC", "autorité de certification")}} émettrice est-elle une {{template.Abbr("AC", "autorité de certification")}} de confiance ?</b> Chaque serveur SSL possède une liste de certificats provenant d'{{template.Abbr("AC", "autorités de certification")}} de confiance, représenté par la zone partagée sur la droite de la Figure 3. Cette liste détermine les certificats acceptés par le serveur. Si le DN de l'AC émettrice correspond au DN d'une AC de confiance présente dans la liste du serveur, la réponse à la question est « Oui » et le serveur passe à l'étape 4. Si l'AC émettrice n'est pas dans la liste, le client ne sera pas authentifié, à moins que le serveur ne puisse vérifier <b>a certificate chain ending in a CA</b> qui n'est pas dans la liste. Les administrateurs peuvent contrôler, pour leur organisation, quels certificats seront de confiance ou non en contrôlant les listes de certificats d'AC maintenues par les clients et les serveurs.
</li></ol>
<ol><li> <b>La clef publique de l'{{template.Abbr("AC", "autorité de certification")}} émettrice correspond-elle à sa signature numérique ?</b> Le serveur utilise la clef publique du certificat d'{{template.Abbr("AC", "autorité de certification")}} (qui a été trouvé dans la liste des AC de confiance à l'étape 3) pour valider la signature numérique de l'{{template.Abbr("AC", "autorité de certification")}} dans le certificat présenté. Si l'information contenue dans le certificat a été modifiée depuis qu'il a été signé par l'AC ou si la clef publique incluse avec le certificat ne correspondent pas à la signature numérique utilisée par l'AC pour signer le certificat, alors le serveur n'authentifiera pas l'identité de l'utilisateur. Si la signature numérique de l'AC peut être validée, le serveur traite le certificat de l'utilisateur comme « lettre de recommandation » valide de la part de l'AC et continue le processus. À partir d'ici, le protocole SSL autorise le serveur à considérer le client comme authentifié et procède à la connexion telle que décrite à l'étape 6. Les serveurs Red Hat peuvent éventuellement être configurés pour exécuter l'étape 5 avant l'étape 6.
</li></ol>
<ol><li> <b>Le certificat de l'utilisateur est-il listé dans les entrées LDAP ?</b> Cette étape optionnelle fournit un moyen aux administrateurs système de révoquer un certificat utilisateur même si celui-ci valide toutes les conditions du test. Le <i>Red Hat Certificate System</i> peut supprimer automatiquement un certificat révoqué des données concernant l'utilisateur dans le répertoire LDAP. Tous les serveurs configurés pour exécuter cette étape refuseront alors d'authentifier ce certificat ou d'établir une connexion. Si le certificat utilisateur présent dans le répertoire est identique à celui présenté par l'utilisateur lors de la négociation SSL, alors le serveur passera à l'étape 6.
</li></ol>
<ol><li> <b>Le client authentifié est-il autorisé à accéder aux ressources demandées ?</b> Le serveur vérifie les ressources auxquelles l'utilisateur est autoriser à accéder selon les listes de contrôle d'accès du serveur (ACLs) et il établit la connexion avec les droits d'accès appropriés. Si, pour une raison ou une autre, le serveur n'exécute pas l'étape 6, l'utilisateur identifié ne peut pas être authentifié et il ne sera pas autorisé à accéder aux ressources du serveur requérant l'authentification.
</li></ol>
<div class="originaldocinfo">
<h3 name="Informations_sur_le_document_original"> Informations sur le document original </h3>
<ul><li> Auteur(s) : {{mediawiki.external('Author Names')}}
</li><li> Autres contributeurs: Giacomo Magnini
</li><li> Dernière mise à jour : 26 septembre 2005
</li><li> Copyright : © 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. All rights reserved.
</li></ul>
</div>
{{ wiki.languages( { "ja": "ja/Introduction_to_SSL", "en": "en/Introduction_to_SSL" } ) }}
Revenir à cette révision