Introduction à SSL

  • Raccourci de la révision : Introduction_à_SSL
  • Titre de la révision : Introduction à SSL
  • ID de la révision : 262283
  • Créé :
  • Créateur : Fredchat
  • Version actuelle ? Non
  • Commentaire /* Suite(s) de chifrements -> suite(s) de chiffrement*/

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 cryptography à 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'éxecute 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é dudit 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 (liaison SSL). Le protocole SSL record définit le format utilisé pour la transmission de données. Le protocole SSL handshake 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 liaison, voir la section "La liaison 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 SSL handshake 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 certficats 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 chiffremenet. 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 liaison 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

Table 1 lists the cipher suites supported by SSL that use the RSA key-exchange algorithm. Unless otherwise indicated, all ciphers listed in the table are supported by both SSL 2.0 and SSL 3.0. Cipher suites are listed from strongest to weakest.

Table 1. Cipher Suites Supported by the SSL Protocol That Use the RSA Key-Exchange Algorithm
Strength Category and Recommended Use
Cipher Suites
Strongest Cipher Suite 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. Triple DES With 168-Bit Encryption and SHA-1 Message Authentication 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.
Strong Cipher Suites Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs. RC4 With 128-Bit Encryption and MD5 Message Authentication 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.
RC2 With 128-Bit Encryption and MD5 Message Authentication 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.
DES With 56-Bit Encryption and SHA-1 Message Authentication 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.
Exportable Cipher Suites 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.
RC2 With 40-Bit Encryption and MD5 Message Authentication 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.
Weakest Cipher Suite 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. No Encryption, MD5 Message Authentication Only 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 Note that for RC4 and RC2 ciphers, the phrase "40-bit encryption" means the keys are still 128 bits long, but only 40 bits have cryptographic significance.

Suites de chiffrements 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 sytè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 classifé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 Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs. Red Hat Console does not support these cipher suites. RC4 With 128-bit Encryption and SHA-1 Message Authentication Like RC4 with 128-bit encryption and MD5 message authentication, this cipher is one of the second strongest ciphers after Triple DES. It permits approximately 3.4 * 1038 possible keys, making it very difficult to crack. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
RC4 With SKIPJACK 80-Bit Encryption and SHA-1 Message Authentication The SKIPJACK cipher is a classified symmetric-key cryptographic algorithm implemented in Fortezza-compliant hardware. Some SKIPJACK implementations support key escrow using the Law Enforcement Access Field (LEAF). The most recent implementations do not. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
Suites de chiffrement Fortezza 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. Red Hat Console does not these cipher suites. No Encryption, SHA-1 Message Authentication Only This cipher uses SHA-1 message authentication to detect tampering. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.

The SSL Handshake

The SSL protocol uses a combination of public-key and symmetric key encryption. Symmetric key encryption is much faster than public-key encryption, but public-key encryption provides better authentication techniques. An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate itself to the client using public-key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

The exact programmatic details of the messages exchanged during the SSL handshake are beyond the scope of this document. However, the steps involved can be summarized as follows (assuming the use of the cipher suites listed in "Cipher Suites With RSA Key Exchange"):

  1. The client sends the server the client's SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL.
  2. The server sends the client the server's SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. The server also sends its own certificate and, if the client is requesting a server resource that requires client authentication, requests the client's certificate.
  3. The client uses some of the information sent by the server to authenticate the server (for details, see "Server Authentication"). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client goes on to Step 4.
  4. Using all data generated in the handshake so far, the client (with the cooperation of the server, depending on the cipher being used) creates the premaster secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in Step 2), and sends the encrypted premaster secret to the server.
  5. If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case the client sends both the signed data and the client's own certificate to the server along with the encrypted premaster secret.
  6. If the server has requested client authentication, the server attempts to authenticate the client (for details, see "Client Authentication"). If the client cannot be authenticated, the session is terminated. If the client can be successfully authenticated, the server uses its private key to decrypt the premaster secret, then performs a series of steps (which the client also performs, starting from the same premaster secret) to generate the master secret.
  7. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity-that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection.
  8. The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
  9. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.
  10. The SSL handshake is now complete, and the SSL session has begun. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

Before continuing with the session, Red Hat servers can be configured to check that the client's certificate is present in the user's entry in an LDAP directory. This configuration option provides one way of ensuring that the client's certificate has not been revoked.

It's important to note that both client and server authentication involve encrypting some piece of data with one key of a public-private key pair and decrypting it with the other key:

  • In the case of server authentication, the client encrypts the premaster secret with the server's public key. Only the corresponding private key can correctly decrypt the secret, so the client has some assurance that the identity associated with the public key is in fact the server with which the client is connected. Otherwise, the server cannot decrypt the premaster secret and cannot generate the symmetric keys required for the session, and the session will be terminated.
  • In the case of client authentication, the client encrypts some random data with the client's private key-that is, it creates a digital signature. The public key in the client's certificate can correctly validate the digital signature only if the corresponding private key was used. Otherwise, the server cannot validate the digital signature and the session is terminated.

The sections that follow provide more details on server authentication and client authentication.

Server Authentication

Red Hat's SSL-enabled client software always requires server authentication, or cryptographic validation by a client of the server's identity. As explained in Step 2 of "The SSL Handshake", the server sends the client a certificate to authenticate itself. The client uses the certificate in Step 3 to authenticate the identity the certificate claims to represent.

To authenticate the binding between a public key and the server identified by the certificate that contains the public key, an SSL-enabled client must receive a "yes" answer to the four questions shown in Figure 2. Although the fourth question is not technically part of the SSL protocol, it is the client's responsibility to support this requirement, which provides some assurance of the server's identity and thus helps protect against a form of security attack known as "man in the middle."

Figure 2. Authentication of a Client Certificate

An SSL-enabled client goes through these steps to authenticate a server's identity:

  1. Is today's date within the validity period? The client checks the server certificate's validity period. If the current date and time are outside of that range, the authentication process won't go any further. If the current date and time are within the certificate's validity period, the client goes on to Step.
  2. Is the issuing CA a trusted CA? Each SSL-enabled client maintains a list of trusted CA certificates, represented by the shaded area on the right side of Figure 3. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client's list of trusted CAs, the answer to this question is yes, and the client goes on to Step 3. If the issuing CA is not on the list, the server will not be authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
  3. Does the issuing CA's public key validate the issuer's digital signature? The client uses the public key from the CA's certificate (which it found in its list of trusted CAs in step 2) to validate the CA's digital signature on the server certificate being presented. If the information in the server certificate has changed since it was signed by the CA or if the CA certificate's public key doesn't correspond to the private key used by the CA to sign the server certificate, the client won't authenticate the server's identity. If the CA's digital signature can be validated, the server treats the user's certificate as a valid "letter of introduction" from that CA and proceeds. At this point, the client has determined that the server certificate is valid. It is the client's responsibility to take Step 4 before Step 5.
  4. Does the domain name in the server's certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as "man in the middle." Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don't match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to Step 5.
  5. The server is authenticated. The client proceeds with the SSL handshake. If the client doesn't get to step 5 for any reason, the server identified by the certificate cannot be authenticated, and the user will be warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server requires client authentication, the server performs the steps described in "Client Authentication."

After the steps described here, the server must successfully use its private key to decrypt the premaster secret the client sends in Step 4 of "The SSL Handshake." Otherwise, the SSL session will be terminated. This provides additional assurance that the identity associated with the public key in the server's certificate is in fact the server with which the client is connected.

Man-in-the-Middle Attack

As suggested in Step 4 above, the client application must check the server domain name specified in the server certificate against the actual domain name of the server with which the client is attempting to communicate. This step is necessary to protect against a man-in-the-middle attack, which works as follows.

The "man in the middle" is a rogue program that intercepts all communication between the client and a server with which the client is attempting to communicate via SSL. The rogue program intercepts the legitimate keys that are passed back and forth during the SSL handshake, substitutes its own, and makes it appear to the client that it is the server, and to the server that it is the client.

The encrypted information exchanged at the beginning of the SSL handshake is actually encrypted with the rogue program's public key or private key, rather than the client's or server's real keys. The rogue program ends up establishing one set of session keys for use with the real server, and a different sent of session keys for use with the client. This allows the rogue program not only to read all the data that flows between the client and the real server, but also to change the data without being deleted. Therefore, it is extremely important for the client to check that the domain name in the server certificate corresponds to the domain name of the server with which a client is attempting to communicate-in addition to checking the validity of the certificate by performing the other steps described in Server Authentication.

Client Authentication

SSL-enabled servers can be configured to require client authentication, or cryptographic validation by the server of the client's identity. When a server configured this way requests client authentication (see Step 6 of "The SSL Handshake"), the client sends the server both a certificate and a separate piece of digitally signed data to authenticate itself. The server uses the digitally signed data to validate the public key in the certificate and to authenticate the identity the certificate claims to represent.

The SSL protocol requires the client to create a digital signature by creating a one-way hash from data generated randomly during the handshake and known only to the client and server. The hash of the data is then encrypted with the private key that corresponds to the public key in the certificate being presented to the server.

To authenticate the binding between the public key and the person or other entity identified by the certificate that contains the public key, an SSL-enabled server must receive a "yes" answer to the first four questions shown in Figure 3. Although the fifth question is not part of the SSL protocol, Red Hat servers can be configured to support this requirement to take advantage of the user's entry in an LDAP directory as part of the authentication process.

Figure 3. Authentication and Verification of a Client Certificate

An SSL-enabled server goes through these steps to authenticate a user's identity:

  1. Does the user's public key validate the user's digital signature? The server checks that the user's digital signature can be validated with the public key in the certificate. If so, the server has established that the public key asserted to belong to John Doe matches the private key used to create the signature and that the data has not been tampered with since it was signed.
    At this point, however, the binding between the public key and the DN specified in the certificate has not yet been established. The certificate might have been created by someone attempting to impersonate the user. To validate the binding between the public key and the DN, the server must also complete Step 3 and Step 4.
  2. Is today's date within the validity period? The server checks the certificate's validity period. If the current date and time are outside of that range, the authentication process won't go any further. If the current date and time are within the certificate's validity period, the server goes on to Step 3.
  3. Is the issuing CA a trusted CA? Each SSL-enabled server maintains a list of trusted CA certificates, represented by the shaded area on the right side of Figure 3. This list determines which certificates the server will accept. If the DN of the issuing CA matches the DN of a CA on the server's list of trusted CAs, the answer to this question is yes, and the server goes on to Step 4. If the issuing CA is not on the list, the client will not be authenticated unless the server can verify a certificate chain ending in a CA that is on the list. Administrators can control which certificates are trusted or not trusted within their organizations by controlling the lists of CA certificates maintained by clients and servers.
  4. Does the issuing CA's public key validate the issuer's digital signature? The server uses the public key from the CA's certificate (which it found in its list of trusted CAs in Step 3) to validate the CA's digital signature on the certificate being presented. If the information in the certificate has changed since it was signed by the CA or if the public key in the CA certificate doesn't correspond to the private key used by the CA to sign the certificate, the server won't authenticate the user's identity. If the CA's digital signature can be validated, the server treats the user's certificate as a valid "letter of introduction" from that CA and proceeds. At this point, the SSL protocol allows the server to consider the client authenticated and proceed with the connection as described in Step 6. Red Hat servers may optionally be configured to perform Step 5 before Step 6.
  5. Is the user's certificate listed in the LDAP entry for the user? This optional step provides one way for a system administrator to revoke a user's certificate even if it passes the tests in all the other steps. The Red Hat Certificate System can automatically remove a revoked certificate from the user's entry in the LDAP directory. All servers that are set up to perform this step will then refuse to authenticate that certificate or establish a connection. If the user's certificate in the directory is identical to the user's certificate presented in the SSL handshake, the server goes on to step 6.
  6. Is the authenticated client authorized to access the requested resources? The server checks what resources the client is permitted to access according to the server's access control lists (ACLs) and establishes a connection with appropriate access. If the server doesn't get to step 6 for any reason, the user identified by the certificate cannot be authenticated, and the user is not allowed to access any server resources that require authentication.

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_liaison_SSL">La liaison 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 cryptography à 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'éxecute 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é dudit 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> (liaison SSL). Le protocole <i>SSL record</i> définit le format utilisé pour la transmission de données. Le protocole <i>SSL handshake</i> 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 liaison, voir la section "<a href="#La_liaison_SSL">La liaison 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 SSL <i>handshake</i> 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 certficats 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 chiffremenet. 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 liaison 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>Table 1 lists the cipher suites supported by SSL that use the RSA key-exchange algorithm. Unless otherwise indicated, all ciphers listed in the table are supported by both SSL 2.0 and SSL 3.0. Cipher suites are listed from strongest to weakest.
</p>
<table border="1" cellpadding="5">
<caption>  <b>Table 1.</b> Cipher Suites Supported by the SSL Protocol That Use the RSA Key-Exchange Algorithm
</caption>
<tbody><tr bgcolor="#cccccc">
<th>
<div class="TableTitle">Strength Category and Recommended Use</div>
</th><th>
<div class="TableTitle">Cipher Suites</div>
</th></tr>
<tr>
<td> <b>Strongest Cipher Suite</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>Triple DES With 168-Bit Encryption and SHA-1 Message Authentication</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>Strong Cipher Suites</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>RC4 With 128-Bit Encryption and MD5 Message Authentication</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>RC2 With 128-Bit Encryption and MD5 Message Authentication</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>DES With 56-Bit Encryption and SHA-1 Message Authentication</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>Exportable Cipher Suites</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>RC2 With 40-Bit Encryption and MD5 Message Authentication</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>Weakest Cipher Suite</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>No Encryption, MD5 Message Authentication Only</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> Note that for RC4 and RC2 ciphers, the phrase "40-bit encryption" means the keys are still 128 bits long, but only 40 bits have cryptographic significance.
</p>
</td></tr></tbody></table>
<h4 name="Suites_de_chiffrements_de_Fortezza"> Suites de chiffrements 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 sytè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 classifé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> Permitted for deployments within the United States only. These cipher suites support encryption that is strong enough for most business or government needs. Red Hat Console does not support these cipher suites.
</td><td> <b>RC4 With 128-bit Encryption and SHA-1 Message Authentication</b> Like RC4 with 128-bit encryption and MD5 message authentication, this cipher is one of the second strongest ciphers after Triple DES. It permits approximately 3.4 * 10<sup>38</sup> possible keys, making it very difficult to crack. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
</td></tr>
<tr>
<td> <b>RC4 With SKIPJACK 80-Bit Encryption and SHA-1 Message Authentication</b> The SKIPJACK cipher is a classified symmetric-key cryptographic algorithm implemented in Fortezza-compliant hardware. Some SKIPJACK implementations support key escrow using the Law Enforcement Access Field (LEAF). The most recent implementations do not. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
</td></tr>
<tr>
<td> <b>Suites de chiffrement Fortezza 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. Red Hat Console does not these cipher suites.
</td><td> <b>No Encryption, SHA-1 Message Authentication Only</b> This cipher uses SHA-1 message authentication to detect tampering. This cipher suite is supported by SSL 3.0 but not by SSL 2.0.
</td></tr></tbody></table>
<h3 name="The_SSL_Handshake"> The SSL Handshake </h3>
<p>The SSL protocol uses a combination of public-key and symmetric key encryption. Symmetric key encryption is much faster than public-key encryption, but public-key encryption provides better authentication techniques. An SSL session always begins with an exchange of messages called the <i>SSL handshake</i>. The handshake allows the server to authenticate itself to the client using public-key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.
</p><p>The exact programmatic details of the messages exchanged during the SSL handshake are beyond the scope of this document. However, the steps involved can be summarized as follows (assuming the use of the cipher suites listed in "<a href="#Cipher_Suites_With_RSA_Key_Exchange">Cipher Suites With RSA Key Exchange</a>"):
</p>
<ol><li> The client sends the server the client's SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL.
</li><li> The server sends the client the server's SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. The server also sends its own certificate and, if the client is requesting a server resource that requires client authentication, requests the client's certificate.
</li><li> The client uses some of the information sent by the server to authenticate the server (for details, see "<a href="#Server_Authentication">Server Authentication</a>"). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client goes on to Step 4.
</li><li> Using all data generated in the handshake so far, the client (with the cooperation of the server, depending on the cipher being used) creates the premaster secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in Step 2), and sends the encrypted premaster secret to the server.
</li><li> If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case the client sends both the signed data and the client's own certificate to the server along with the encrypted premaster secret.
</li><li> If the server has requested client authentication, the server attempts to authenticate the client (for details, see "<a href="#Client_Authentication">Client Authentication</a>"). If the client cannot be authenticated, the session is terminated. If the client can be successfully authenticated, the server uses its private key to decrypt the premaster secret, then performs a series of steps (which the client also performs, starting from the same premaster secret) to generate the master secret.
</li><li> Both the client and the server use the master secret to generate the <i>session keys,</i> which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity-that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection.
</li><li> The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
</li><li> The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.
</li><li> The SSL handshake is now complete, and the SSL session has begun. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
</li></ol>
<p>Before continuing with the session, Red Hat servers can be configured to check that the client's certificate is present in the user's entry in an LDAP directory. This configuration option provides one way of ensuring that the client's certificate has not been revoked.
</p><p>It's important to note that both client and server authentication involve encrypting some piece of data with one key of a public-private key pair and decrypting it with the other key:
</p>
<ul><li> In the case of server authentication, the client encrypts the premaster secret with the server's public key. Only the corresponding private key can correctly decrypt the secret, so the client has some assurance that the identity associated with the public key is in fact the server with which the client is connected. Otherwise, the server cannot decrypt the premaster secret and cannot generate the symmetric keys required for the session, and the session will be terminated.
</li><li> In the case of client authentication, the client encrypts some random data with the client's private key-that is, it creates a digital signature. The public key in the client's certificate can correctly validate the digital signature only if the corresponding private key was used. Otherwise, the server cannot validate the digital signature and the session is terminated.
</li></ul>
<p>The sections that follow provide more details on server authentication and client authentication.
</p>
<h4 name="Server_Authentication"> Server Authentication </h4>
<p>Red Hat's SSL-enabled client software always requires server authentication, or cryptographic validation by a client of the server's identity. As explained in Step 2 of "<a href="#The_SSL_Handshake">The SSL Handshake</a>", the server sends the client a certificate to authenticate itself. The client uses the certificate in Step 3 to authenticate the identity the certificate claims to represent.
</p><p>To authenticate the binding between a public key and the server identified by the certificate that contains the public key, an SSL-enabled client must receive a "yes" answer to the four questions shown in Figure 2. Although the fourth question is not technically part of the SSL protocol, it is the client's responsibility to support this requirement, which provides some assurance of the server's identity and thus helps protect against a form of security attack known as "man in the middle."
</p><p><img align="none" alt="Figure 2. Authentication of a Client Certificate" src="File:fr/Media_Gallery/11svauth.gif">
</p><p>An SSL-enabled client goes through these steps to authenticate a server's identity:
</p>
<ol><li> <b>Is today's date within the validity period?</b> The client checks the server certificate's validity period. If the current date and time are outside of that range, the authentication process won't go any further. If the current date and time are within the certificate's validity period, the client goes on to Step.
</li><li> <b>Is the issuing CA a trusted CA?</b> Each SSL-enabled client maintains a list of trusted CA certificates, represented by the shaded area on the right side of Figure 3. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client's list of trusted CAs, the answer to this question is yes, and the client goes on to Step 3. If the issuing CA is not on the list, the server will not be authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
</li><li> <b>Does the issuing CA's public key validate the issuer's digital signature?</b> The client uses the public key from the CA's certificate (which it found in its list of trusted CAs in step 2) to validate the CA's digital signature on the server certificate being presented. If the information in the server certificate has changed since it was signed by the CA or if the CA certificate's public key doesn't correspond to the private key used by the CA to sign the server certificate, the client won't authenticate the server's identity. If the CA's digital signature can be validated, the server treats the user's certificate as a valid "letter of introduction" from that CA and proceeds. At this point, the client has determined that the server certificate is valid. It is the client's responsibility to take Step 4 before Step 5.
</li><li> <b>Does the domain name in the server's certificate match the domain name of the server itself?</b> This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as "man in the middle." Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don't match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to Step 5.
</li><li> <b>The server is authenticated.</b> The client proceeds with the SSL handshake. If the client doesn't get to step 5 for any reason, the server identified by the certificate cannot be authenticated, and the user will be warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server requires client authentication, the server performs the steps described in "<a href="#Client_Authentication">Client Authentication</a>."
</li></ol>
<p>After the steps described here, the server must successfully use its private key to decrypt the premaster secret the client sends in Step 4 of "<a href="#The_SSL_Handshake">The SSL Handshake</a>." Otherwise, the SSL session will be terminated. This provides additional assurance that the identity associated with the public key in the server's certificate is in fact the server with which the client is connected.
</p>
<h4 name="Man-in-the-Middle_Attack"> Man-in-the-Middle Attack </h4>
<p>As suggested in Step 4 above, the client application must check the server domain name specified in the server certificate against the actual domain name of the server with which the client is attempting to communicate. This step is necessary to protect against a man-in-the-middle attack, which works as follows.
</p><p>The "man in the middle" is a rogue program that intercepts all communication between the client and a server with which the client is attempting to communicate via SSL. The rogue program intercepts the legitimate keys that are passed back and forth during the SSL handshake, substitutes its own, and makes it appear to the client that it is the server, and to the server that it is the client.
</p><p>The encrypted information exchanged at the beginning of the SSL handshake is actually encrypted with the rogue program's public key or private key, rather than the client's or server's real keys. The rogue program ends up establishing one set of session keys for use with the real server, and a different sent of session keys for use with the client. This allows the rogue program not only to read all the data that flows between the client and the real server, but also to change the data without being deleted. Therefore, it is extremely important for the client to check that the domain name in the server certificate corresponds to the domain name of the server with which a client is attempting to communicate-in addition to checking the validity of the certificate by performing the other steps described in Server Authentication.
</p>
<h4 name="Client_Authentication"> Client Authentication </h4>
<p>SSL-enabled servers can be configured to require client authentication, or cryptographic validation by the server of the client's identity. When a server configured this way requests client authentication (see Step 6 of "<a href="#The_SSL_Handshake">The SSL Handshake</a>"), the client sends the server both a certificate and a separate piece of digitally signed data to authenticate itself. The server uses the digitally signed data to validate the public key in the certificate and to authenticate the identity the certificate claims to represent.
</p><p>The SSL protocol requires the client to create a digital signature by creating a one-way hash from data generated randomly during the handshake and known only to the client and server. The hash of the data is then encrypted with the private key that corresponds to the public key in the certificate being presented to the server.
</p><p>To authenticate the binding between the public key and the person or other entity identified by the certificate that contains the public key, an SSL-enabled server must receive a "yes" answer to the first four questions shown in Figure 3. Although the fifth question is not part of the SSL protocol, Red Hat servers can be configured to support this requirement to take advantage of the user's entry in an LDAP directory as part of the authentication process.
</p><p><img align="none" alt="Figure 3. Authentication and Verification of a Client Certificate" src="File:fr/Media_Gallery/04cert.gif">
</p><p>An SSL-enabled server goes through these steps to authenticate a user's identity:
</p>
<ol><li> <b>Does the user's public key validate the user's digital signature?</b> The server checks that the user's digital signature can be validated with the public key in the certificate. If so, the server has established that the public key asserted to belong to John Doe matches the private key used to create the signature and that the data has not been tampered with since it was signed.<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;"> At this point, however, the binding between the public key and the DN specified in the certificate has not yet been established. The certificate might have been created by someone attempting to impersonate the user. To validate the binding between the public key and the DN, the server must also complete Step 3 and Step 4.</div>
</li><li> <b>Is today's date within the validity period?</b> The server checks the certificate's validity period. If the current date and time are outside of that range, the authentication process won't go any further. If the current date and time are within the certificate's validity period, the server goes on to Step 3.
</li><li> <b>Is the issuing CA a trusted CA?</b> Each SSL-enabled server maintains a list of trusted CA certificates, represented by the shaded area on the right side of Figure 3. This list determines which certificates the server will accept. If the DN of the issuing CA matches the DN of a CA on the server's list of trusted CAs, the answer to this question is yes, and the server goes on to Step 4. If the issuing CA is not on the list, the client will not be authenticated unless the server can verify a certificate chain ending in a CA that is on the list. Administrators can control which certificates are trusted or not trusted within their organizations by controlling the lists of CA certificates maintained by clients and servers.
</li><li> <b>Does the issuing CA's public key validate the issuer's digital signature?</b> The server uses the public key from the CA's certificate (which it found in its list of trusted CAs in Step 3) to validate the CA's digital signature on the certificate being presented. If the information in the certificate has changed since it was signed by the CA or if the public key in the CA certificate doesn't correspond to the private key used by the CA to sign the certificate, the server won't authenticate the user's identity. If the CA's digital signature can be validated, the server treats the user's certificate as a valid "letter of introduction" from that CA and proceeds. At this point, the SSL protocol allows the server to consider the client authenticated and proceed with the connection as described in Step 6. Red Hat servers may optionally be configured to perform Step 5 before Step 6.
</li><li> <b>Is the user's certificate listed in the LDAP entry for the user?</b> This optional step provides one way for a system administrator to revoke a user's certificate even if it passes the tests in all the other steps. The Red Hat Certificate System can automatically remove a revoked certificate from the user's entry in the LDAP directory. All servers that are set up to perform this step will then refuse to authenticate that certificate or establish a connection. If the user's certificate in the directory is identical to the user's certificate presented in the SSL handshake, the server goes on to step 6.
</li><li> <b>Is the authenticated client authorized to access the requested resources?</b> The server checks what resources the client is permitted to access according to the server's access control lists (ACLs) and establishes a connection with appropriate access. If the server doesn't get to step 6 for any reason, the user identified by the certificate cannot be authenticated, and the user is not allowed to access any server resources that require authentication.
</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