Introduction à la PKI et à SSL

Introduction

Pour comprendre le fonctionnement du protocole SSL (Secure Sockets Layer), il faut d'abord maîtriser les notions fondamentales de chiffrement symétrique et d'infrastructure à clés publiques (PKI). Toutes ces technologies sont utilisées par SSL. Cet article présente ces concepts.

SSL s'appuie sur la PKI et sur les technologies à clé symétrique. Il utilise le chiffrement symétrique, le chiffrement à clé publique/privée (asymétrique) et les signatures numériques.

Chiffrement symétrique

• Les deux parties de la conversation utilisent exactement les mêmes clés symétriques pour chiffrer et déchiffrer. La clé symétrique reste secrète entre les deux parties
• Toutes les données sont chiffrées à l'aide de la clé symétrique, puis transmises sur le réseau.
• Le destinataire reçoit les données chiffrées et les déchiffre avec la même clé symétrique
• La façon dont la clé symétrique est générée de part et d'autre de la conversation dépend de l'algorithme d'échange de clés
• RSA et Diffie Hellman sont des exemples d'algorithmes d'échange de clés symétriques
• Tous les navigateurs utilisent l'algorithme d'échange de clés RSA pour échanger les clés symétriques
• Des produits comme Advanced Security Option pour Oracle Net peuvent utiliser RSA ou Diffie-Hellman pour l'échange de clés
• Chaque clé symétrique utilise un algorithme de chiffrement à clé symétrique. Les algorithmes de chiffrement les plus courants sont RC4 et DES
• Plus la clé est longue, mieux les données sont protégées ; RC4 et DES peuvent chiffrer avec différentes longueurs de clé
• RC4 peut chiffrer en 256, 126, 56 et 40 bits - DES peut chiffrer en 3DES168, 3DES112, 56 et 40 bits
• Avantages : chiffrement et déchiffrement extrêmement rapides
• Inconvénients : le déploiement des clés est complexe

Chiffrement PKI

• Contrairement au chiffrement symétrique, chacune des parties de la conversation possède sa propre paire de clés, privée et publique.
• Ce qu'une clé fait, l'autre le défait : si vous chiffrez avec la clé publique, vous déchiffrez avec la clé privée correspondante.
• Le chiffrement utilise toujours la clé publique du destinataire : si un client souhaite envoyer des données au serveur, il les chiffre avec la clé publique du serveur. La clé privée du serveur sert ensuite à les déchiffrer
• La clé privée doit rester privée : personne d'autre que son propriétaire ne doit y avoir accès
• Les clés publiques et privées sont toujours générées avec un seul et même algorithme (RSA)
• Les clés publiques/privées ont elles aussi une longueur. Plus la clé est longue, plus le chiffrement est robuste
• Les longueurs de clé courantes (de la plus robuste à la moins robuste) sont : 2048, 1024 et 512 bits
• Dans les connexions SSL sur Internet, la longueur de clé publique la plus courante est de 1024 bits
• Aussi appelé 'chiffrement asymétrique'
• Avantages : le déploiement des clés est plus simple
• Inconvénients : le chiffrement/déchiffrement est extrêmement lent. Toute personne souhaitant communiquer doit posséder sa propre paire de clés publique/privée
• Remarque : en pratique, le chiffrement en masse avec des clés privées/publiques n'est jamais utilisé, en raison de sa lenteur et parce que chacun devrait posséder une paire de clés publique/privée. Il ne sert en réalité qu'à l'authentification et à l'échange des clés symétriques. Voir la section sur SSL plus loin.

Signatures numériques

• Les signatures numériques permettent de vérifier l'authenticité du message, c'est-à-dire de savoir s'il a été altéré. Les données à envoyer passent par un algorithme de hachage à sens unique, qui produit un condensé (digest)
• Le condensé est ensuite chiffré avec la clé de chiffrement pour produire une signature numérique
• Le destinataire déchiffre la signature numérique avec la clé appropriée pour obtenir le condensé
• Le destinataire fait passer les données d'origine par le même algorithme que l'expéditeur pour produire un condensé
• Le destinataire compare les deux condensés : s'ils correspondent, le message n'a pas été altéré
• Les algorithmes de hachage à sens unique les plus courants sont MD5 et SHA1

Certificats

• Avec des clés publiques/privées, comment savoir si la clé publique reçue provient bien du serveur lui-même et non d'ailleurs ?
• Une méthode d'authentification est nécessaire : c'est le rôle des certificats
• Un certificat permet à un client ou à un serveur d'identifier le tiers avec lequel il communique
• Pour prouver son identité, le serveur dispose d'un certificat, qui associe sa clé publique à l'identité réelle du serveur.
• Un certificat contient les informations suivantes :
  • Subject Name - le nom distinctif (DN) du propriétaire
  • Subject's Public Key - la clé publique du sujet
  • Issuer - le nom distinctif de l'émetteur
  • Signature numérique de l'autorité de certification (CA) - un hachage de toutes les données du certificat du serveur Web, chiffré avec la clé privée de la CA
  • Dates de validité du certificat - date de début de validité et date d'expiration
  • Informations d'administration - version/numéro de série
  • Informations étendues - contraintes, indicateurs de navigateur, etc.
• Ainsi, si un navigateur se connecte à https://www.oracle.com, le contenu du certificat est le suivant :
  • Subject Name: "CN = www.oracle.com, OU = Global IT, O = Oracle Corporation, L = Redwood Shores ,S = California, C = US"
  • Subjects Public Key: RSA (1024 Bits)
  • Issuer: OU = Secure Server Certification Authority ,O = RSA Data Security, Inc., C = US
  • Signature Algorithm: sha1(RSA)
  • Valid From: 16 June 2003 00:00:00, Valid To: 15 June 2005 23:59:59
  • Version: V3
  • Serial Number: 7731 4540 FD6E 1385 2512 6234 3A22 A271
  • À partir de toutes ces informations, le client peut déterminer si la clé publique du certificat provient bien du serveur lui-même. La section 'Comment une connexion SSL est-elle établie ?' explique plus en détail comment le client utilise ces informations
• Les types de certificats sont présentés plus loin

Pourquoi SSL utilise-t-il toutes ces technologies ?

• Les algorithmes de chiffrement/déchiffrement symétrique sont extrêmement rapides comparés au chiffrement/déchiffrement à clé publique/privée
• Le déploiement des clés est plus simple avec des clés publiques/privées qu'avec des clés symétriques
• Le chiffrement protège dans une certaine mesure contre l'altération des messages, mais pas autant que les signatures numériques
• Les certificats permettent d'associer une identité à une clé publique
• En combinant toutes ces technologies, on tire parti des avantages de chacune pour obtenir la connexion la plus fiable, la plus rapide et la plus sûre

Comment une connexion SSL est-elle établie ?

Supposons que nous voulions accéder au site suivant en SSL : https://www.oracle.com

• Le navigateur et le serveur Web conviennent de la version du protocole SSL, de la suite de chiffrement (ciphersuite) et d'un identifiant de session. Le protocole et la suite de chiffrement négociés dépendent des versions du navigateur et du serveur Web utilisés. Les versions du protocole SSL sont SSLV2, SSLV3 et TLSV1, SSLV3 étant la plus courante. La suite de chiffrement SSL précise :
  • L'algorithme d'échange de clés - la façon dont le client et le serveur échangent les clés symétriques, p. ex. RSA ou Diffie-Hellmann)
  • L'algorithme de chiffrement symétrique, p. ex. RC4 128 bits ou DES 56 bits
  • La fonction de condensé de message, p. ex. MD5 (128 bits) ou SHA-1 (160 bits)
  • Pour les besoins de cette explication, la suite de chiffrement négociée est RSA-RC4128-MD5
• Le serveur envoie le certificat au navigateur
• Le navigateur reçoit le certificat et vérifie sa validité à l'aide du certificat de la CA de confiance. Rappelons que le certificat contient la date de validité, le DN de la CA émettrice, la clé publique du serveur Web et la signature numérique de la CA (c'est-à-dire un hachage de toutes les données du certificat, chiffré avec la clé privée de la CA).
• Le client vérifie d'abord que le certificat est valide à la date du jour, d'après sa période de validité. Ici, les dates de validité sont Valid From:16 June 2003 00:00:00, Valid To: 15 June 2005 23:59:59. Au moment de la rédaction, nous sommes le 23 février 2004 : le certificat est donc valide.
• Il vérifie ensuite que le DN de l'émetteur correspond au DN de l'un des certificats de CA de confiance du client. Ceux-ci sont stockés dans la liste des certificats de confiance du navigateur. S'il correspond à l'un des certificats de CA de confiance, la CA émettrice est reconnue comme fiable. Ici, le certificat de www.oracle.com a été émis par "OU = Secure Server Certification Authority ,O = RSA Data Security, Inc., C = US". Comme il s'agit d'un fournisseur de certificats courant, son certificat est livré par défaut avec la plupart des navigateurs.
• La signature numérique est ensuite déchiffrée avec la clé publique de la CA, dont le navigateur dispose puisqu'elle figure dans le certificat de la CA stocké dans le navigateur. Le certificat d'origine passe ensuite par l'algorithme de hachage pour produire un condensé. Si les deux condensés correspondent, on sait que le certificat a été émis par la CA de confiance et qu'il n'a pas été altéré.
• Ensuite, le Common Name (CN) du DN du sujet est comparé au nom d'hôte du serveur d'où provient le certificat, pour prouver qu'il vient bien de ce serveur. Ici, nous nous sommes connectés à http://www.oracle.com ; le navigateur vérifie donc que le CN du sujet correspond. Comme le certificat contient "CN = www.oracle.com", ce test est réussi
• Si toutes les vérifications sont concluantes, le navigateur peut considérer qu'il possède bien la clé publique du serveur. Dans cet exemple, tous les tests réussissent. Dans le cas contraire, l'utilisateur est informé du problème par un message d'avertissement. Si, par exemple, le certificat avait expiré, le message d'avertissement suivant s'afficherait : "The security certificate is expired or not yet valid"
• Maintenant qu'il dispose de la clé publique du serveur Web, le navigateur demande au serveur de prouver à nouveau son identité en lui envoyant des données générées aléatoirement à signer numériquement.
• Le serveur produit un condensé des données à l'aide de l'algorithme de hachage, le chiffre avec sa clé privée et renvoie la signature numérique.
• Le navigateur reçoit la signature numérique et la déchiffre avec la clé publique du serveur pour obtenir un condensé, puis fait passer les données aléatoires d'origine par l'algorithme de hachage pour produire un second condensé.
• Si les deux condensés correspondent, le serveur a prouvé son identité.
• Le navigateur et le serveur échangent ensuite les clés de chiffrement symétriques au moyen de l'algorithme d'échange de clés (KEA) défini dans la suite de chiffrement négociée. Dans notre exemple, le KEA négocié est RSA.
• À ce stade, la négociation SSL (SSL Handshake) est terminée ; ces clés symétriques servent alors à chiffrer et à déchiffrer les données pendant toute la session, avec l'algorithme de chiffrement négocié au début de la session, soit RC4128
• Toutes les données transmises passent également par l'algorithme de hachage négocié (MD5) afin d'empêcher toute altération

Les certificats plus en détail

Vous pouvez obtenir des certificats de serveur auprès de nombreux fournisseurs en ligne, ou acheter ou télécharger un logiciel qui vous permet de générer vos propres certificats, p. ex. OpenSSL. Comme les fournisseurs sont nombreux, il est impossible de passer en revue les noms que chacun donne à ses certificats de serveur ; nous présenterons donc ceux de deux des principaux fournisseurs sur Internet : Verisign et Thawte.

Certificats de serveur

Il existe deux grands types de certificats de serveur, dont le nom commercial varie selon l'autorité de certification qui les émet.

1. Global Server ID's (GSID) (émis par Verisign)
   Les Global Server Certificates, parfois appelés Server Gated Cryptography ou certificats 128 bits, permettent à tous les navigateurs d'utiliser le chiffrement symétrique 128 bits, même s'il s'agit d'un navigateur d'exportation limité au chiffrement symétrique 40 bits. Un GSID comporte généralement deux parties : le certificat lui-même et un certificat intermédiaire supplémentaire, qui sert à relever le niveau de chiffrement (step-up). C'était utile en raison des anciennes réglementations sur l'exportation, qui n'autorisaient que les navigateurs d'exportation hors des États-Unis. Depuis l'assouplissement de ces réglementations, les nouveaux navigateurs peuvent utiliser le chiffrement 128 bits partout dans le monde. Comme indiqué plus haut, le nom de ces certificats varie. Thawte, par exemple, les appelle 128bit SuperCerts. Ce type de certificat ne devrait plus être nécessaire aujourd'hui, puisque tous les navigateurs récents prennent en charge le chiffrement symétrique 128 bits.
2. Secure Server Certificates (émis par Verisign)
   On les appelle parfois certificats 40 bits. Ils permettent pourtant un chiffrement en masse de 128 bits ou plus si le serveur Web et le navigateur client prennent tous deux en charge le chiffrement symétrique de 128 bits ou plus. Cela peut sembler illogique, mais tout dépend des suites de chiffrement utilisées pour générer la clé symétrique. Thawte appelle ces certificats SSL Certificates. En réalité, les certificats 40 bits ou 128 bits n'existent pas : les deux types prennent en charge les mêmes niveaux de chiffrement ; simplement, les GSID permettent aux anciens navigateurs d'exportation d'utiliser le chiffrement symétrique SSL en 128 bits. On peut dire qu'un certificat a une taille de clé, mais celle-ci désigne la longueur de la clé publique qu'il contient (c.-à-d. 512/1024/2048 bits). Les noms des certificats ont été choisis à des fins purement commerciales.
3. Certificats client
   Dans la plupart des applications Internet, le serveur envoie un certificat au client afin de s'authentifier. Avec SSL, un serveur peut aussi demander au client de s'authentifier, pour plus de sécurité. Cette pratique est rare dans la plupart des applications Internet, mais courante dans les applications intranet Web. Dans ce scénario, le client et le serveur possèdent chacun un certificat, et le serveur authentifie également le client. Si vous souhaitez une authentification du client, un certificat client doit être émis pour votre navigateur ou votre application. Ces certificats sont offerts par des fournisseurs sur Internet comme Verisign ou Thawte, ou peuvent être produits avec des logiciels commerciaux comme Oracle Certificate Authority, Netscape Certificate Server ou RSA Keon Server. Avec un navigateur, la clé privée du certificat client correspondant est stockée dans une base de données du navigateur, généralement protégée par un mot de passe. Si vous faites appel à un fournisseur comme Verisign ou Thawte pour vos certificats client, toute la génération de la clé privée est effectuée conjointement par le navigateur et le site Web. Pendant la génération, un NIP vous sera demandé ; vous devrez le saisir lors de chaque connexion SSL si le serveur exige l'authentification du client. Les certificats client sont parfois appelés certificats personnels. Ils contiennent les mêmes informations qu'un certificat de serveur, mais n'ont pas de User Common Name (CN) : cet attribut contient plutôt votre nom complet ou votre adresse courriel. Lorsqu'un serveur authentifie le client, il ne fait donc aucune validation par rapport à un nom d'hôte.

Prise en charge dans OracleAS 9iAS/10G et Fusion Middleware 11g

Certificats, protocoles SSL et modules HTTP Server pris en charge

Cette section présente les types de certificats, les protocoles SSL et les modules HTTP Server pris en charge par HTTP Server selon les versions d'Application Server.

Certificats

Certificats de serveur

1.0.2.X* : Oui
9.0.2 : Oui
9.0.3 : Oui
9.0.4.X (10GR1) : Oui
10.1.2(10GR2) : Oui
10.1.3(10GR3) : Oui
11.1.1.X (FMW11g) : Oui

Global Server ID's**

1.0.2.X* : Oui
9.0.2 : Non
9.0.3 : Non
9.0.4.X (10GR1) : Oui (1)
10.1.2(10GR2) : Oui(2)
10.1.3(10GR3) : Oui
11.1.1.X (FMW11g) : Oui

Certificats client

1.0.2.X* : Oui
9.0.2 : Oui
9.0.3 : Oui
9.0.4.X (10GR1) : Oui
10.1.2(10GR2) : Oui
10.1.3(10GR3) : Oui
11.1.1.X (FMW11g) : Oui

* Comprend les versions d'OHS livrées avec Oracle RDBMS 8.1.7 et 9.X
** Comprend les certificats de tout fournisseur qui relèvent le niveau de chiffrement des anciens navigateurs d'exportation

1) La version 9.0.4.3 doit être installée pour que les GSID fonctionnent
2) La version 10.1.2.3 doit être installée pour que les GSID fonctionnent

Protocoles

SSL V2.0

1.0.2.X* : O
9.0.2 : N
9.0.3 : N
9.0.4 (10GR1)** : N
10.1.2(10GR2)*** : O
10.1.3(10GR3) : O
11.1.1.X (FMW11g) : N

SSL V3.0

1.0.2.X* : O
9.0.2 : O
9.0.3 : O
9.0.4(10GR1)** : O
10.1.2(10GR2)*** : O
10.1.3(10GR3) : O
11.1.1.X (FMW11g) : O

TLS V1.0

1.0.2.X* : O
9.0.2 : N
9.0.3 : N
9.0.4 (10GR1)** : N
10.1.2(10GR2)*** : O
10.1.3(10GR3) : O
11.1.1.X (FMW11g) : O

* Comprend les versions d'OHS livrées avec Oracle RDBMS 8.1.7 et 9.X
** Comprend les versions d'OHS livrées avec le RDBMS 10.1.
*** Comprend les versions d'OHS livrées avec le RDBMS 10.2
Notez que, dans ce qui précède, la directive SSLProtocol ALL prend également en charge SSLV3_V2H, c'est-à-dire SSLV3 avec un Client Hello SSLV2

Directive OHS : SSLProtocol

MOD_SSL/OPENSSL

1.0.2.X* : O
9.0.2 : N
9.0.3 : N
9.0.4(10GR1)** : N
10.1.2(10GR2)*** : N
10.1.3(10GR3) : N
11.1.1.X (FMW11g) : N

MOD_OSSL/OWM

1.0.2.X* : N
9.0.2 : O
9.0.3 : O
9.0.4(10GR1)** : O
10.1.2(10GR2)*** : O
10.1.3(10GR3) : O
11.1.1.X (FMW11g) : O****

* Comprend les versions d'OHS livrées avec Oracle RDBMS 8.1.7 et 9.X
** Comprend les versions d'OHS livrées avec le RDBMS 10.1
*** Comprend les versions d'OHS livrées avec le RDBMS 10.2
**** FMW 11g offre plusieurs façons de générer un portefeuille (Wallet) - Voir la note 1218603.1 Understanding Wallets and Keystores in Fusion Middleware 11g
OWM - Oracle Wallet Manager

Référence

SSL combine le chiffrement symétrique et les technologies PKI pour assurer l'authentification, le chiffrement et l'authenticité des messages. Les certificats garantissent qu'une clé publique reçue provient bien de l'entité qui l'a envoyée. Il existe différents types de certificats de serveur, que les fournisseurs désignent sous des noms différents. Oracle Application Server prend en charge plusieurs protocoles SSL et suites de chiffrement, et HTTP Server peut être configuré pour les utiliser si la version les prend en charge

NOTE:1218603.1 - Understanding Wallets and Keystores in Fusion Middleware 11g
NOTE:1218695.1 - Master Note for SSL Configuration in Fusion Middleware 11g
NOTE:1275428.1 - Support Status for SHA2 in Oracle Application Server (10.1.2.X.X/10.1.3.X.X) and Fusion Middleware 11g (11.1.1.X)

• SSL/TLS
• Sécurité
• Oracle Database