1.2. Que sont SSL et les certificats ?

1.2.1. Clef publique / clef privée

Le chiffrement à base de clef publique garantit qu'une donnée chiffrée par une clef, publique ou privée, ne peut être déchiffrée que par la clef associée. Cela peut paraître surprenant mais croyez moi, ça fonctionne. Les clefs sont de même nature et leurs rôles peuvent être inversés : ce que l'une chiffre est déchiffrable par l'autre. La paire de clef repose sur des nombres premiers et leur longueur, exprimée en digits binaires, traduit la difficulté qu'il y a à déchiffrer un message sans connaissance à priori de la clef nécessaire. L'astuce consiste à conserver une clef secrète (la clef privée) et à distribuer l'autre clef (la clef publique) à tout le monde. N'importe qui peut vous envoyer un message chiffré mais personne d'autre que vous ne peut le déchiffrer tant que vous êtes le seul à conserver un des deux membres de la paire de clefs. On peut également prouver qu'un message provient de vous en le chiffrant avec votre clef privée : seule la clef publique correspondante le déchiffrera. Notez que le message n'est pas protégé parce que vous le signez. Tout le monde a accès à la clef de déchiffrement, ne l'oubliez pas.

Le problème consiste à obtenir la clef publique du correspondant. En général, vous lui demanderez de la transmettre via un message signé qui la contiendra accompagnée d'un certificat.

Message-->[Clef publique]-->Message chiffré-->[Clef privée]-->Message

1.2.2. Le certificat

Qu'est-ce qui vous garantit que vous dialoguez bien avec la bonne personne ou le bon site web ? En principe, quelqu'un aura fait l'effort (s'il est sérieux) de vérifier que les propriétaires du site sont bien ceux qu'ils affirment être. On fait naturellement confiance à ce quelqu'un : son certificat, un certificat racine, est incorporé à votre navigateur. Un certificat contient des informations relatives à son propriétaire comme une adresse électronique, un nom, l'usage prévu du certificat, une durée de validité, un identifiant de localisation ou un nom qualifié (DN/Distinguished Name) qui comprend le nom d'usage (CN/Common Name) et l'identifiant du signataire du certificat. Le certificat comprend également la clef publique et un haché pour garantir l'intégrité du message. Comme vous avez décidé de faire confiance au signataire du certificat, vous accordez du crédit à son contenu. On parle d'arbre de confiance de certification ou de chemin de certification. En général, le navigateur et les applications incluent d'office le certificat racine d'autorités de certification bien connues. L'autorité de certification tient à jour une liste des certificats signés ainsi qu'une liste des certificats révoqués. Un certificat n'est pas fiable tant qu'il n'est pas signé puisque seul un certificat signé ne peut pas être modifié. Un certificat peut se signer lui-même. On parle alors de certificat auto-signé. Tous les certificats de CA racines sont ce type.

Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 1 (0x1)
 Signature Algorithm: md5WithRSAEncryption
 Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=administrator@sopac.org
 Validity
 Not Before: Nov 20 05:47:44 2001 GMT
 Not After : Nov 20 05:47:44 2002 GMT
 Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email=administrator@sopac.org
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 RSA Public Key: (1024 bit)
 Modulus (1024 bit):
 00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a:
 9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36:
 b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4:
 7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86:
 08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd:
 94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25:
 da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e:
 42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a:
 6c:14:e2:ae:62:e7:6b:30:e9
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Comment:
 OpenSSL Generated Certificate
 X509v3 Subject Key Identifier:
 FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F
 X509v3 Authority Key Identifier:
 keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6
 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org
 serial:00
 Signature Algorithm: md5WithRSAEncryption
 34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd:
 aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57:
 2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96:
 34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62:
 e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5:
 0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06:
 ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:
 bc:5a
-----BEGIN CERTIFICATE-----
MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox
DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww
CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B
CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy
MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD
VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD
Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv
cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB
0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI
2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2
JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ
YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud
DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl
uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp
amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx
FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0
cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw
VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb
xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b
Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
-----END CERTIFICATE-----

Comme vous avez pu le remarquer, le certificat mentionne son émetteur, contient la clef publique de son propriétaire, la période de validité du certificat et une signature pour vérifier qu'il n'a pas été modifié. Le certificat ne contient PAS la clef privée qui ne doit jamais être révélée. Ce certificat contient tous les éléments nécessaires pour envoyer un message chiffré à son propriétaire ou pour vérifier un message dont la signature lui est attribuée.

1.2.3. La clef symétrique

Les algorithmes de chiffrement à paire de clefs publique/privée sont intéressants mais pas toujours pratiques. Ils sont asymétriques parce que des clefs différentes sont requises au chiffrement et au déchiffrement. La même clef ne peut remplir les deux rôles. Les algorithmes symétriques actuels sont nettement plus rapides que les algorithmes asymétriques. Une clef symétrique est toutefois potentiellement peu sûre. Il suffit qu'un individu nuisible se la procure et il n'y a plus d'information protégée. La clef symétrique doit donc être transmise au correspondant sans être interceptée. Rien n'est sûr dans l'Internet. La solution consiste à envelopper la clef symétrique dans un message chiffré au moyen d'un algorithme asymétrique. Comme personne d'autre que vous ne connaît la clef privée, le message chiffré avec la clef privée est sûr (enfin, relativement, rien n'est garanti en ce bas monde sinon la mort et les impôts). La clef de chiffrement symétrique est choisie aléatoirement de telle sorte qu'une compromission accidentelle n'ait pas d'impact sur les transactions futures.

Clef symétrique-->[Clef publique]-->Clef de session chiffrée-->[Clef privée]-->Clef symétrique

1.2.4. Les algorithmes de chiffrement

Différents algorithmes existent, symétriques ou non, avec diverses longueurs de clef. En principe les algorithmes ne peuvent pas être brevetés. Si Henri Poincaré l'avait fait, il aurait pu poursuivre Albert Einstein … Les algorithmes ne peuvent donc pas être brevetés, à l'exception toutefois des États-Unis. OpenSSL est mis au point dans des pays où les algorithmes ne sont pas brevetés et où l'usage de la cryptographie n'est pas réservé à des agences d'état pour des fins militaires ou d'espionnage. Lors de la négociation entre le navigateur et le serveur web, les applications fournissent l'une à l'autre une liste d'algorithmes qu'elles peuvent traiter, classés par ordre de préférence. L'algorithme préféré en commun est choisi. OpenSSL peut être compilé sans inclure la gestion de certains algorithmes de façon à rester utilisable dans des pays où l'usage de la cryptographie est réglementé.

1.2.5. Le hachage

Un hachage s'obtient par application d'une fonction, dite à sens unique, à un message. La fonction présente cette propriété qu'il n'est pas possible de former un message initial à partir du haché. En outre, le haché est complètement modifié en cas de changement, même mineur, du message d'origine. Il est donc pratiquement impossible de modifier un message à haché constant. Les fonctions de hachage s'emploient dans des mécanismes à base de mot de passe, des vérifications d'intégrité (MD5) et en général pour vérifier que des données n'ont pas été altérées. L'IETF (Internet Engineering Task Force) préfère apparemment SHA1 à MD5 pour diverses raisons techniques (cf RFC2459 7.1.2 and 7.1.3).

1.2.6. La signature

La signature d'un message consiste à associer une identité à son contenu. Le plus souvent il s'agit de prouver qui en est l'auteur mais ce n'est pas toujours le cas. Le message peut être textuel ou être le certificat de quelqu'un d'autre. Pour signer un message, son haché est d'abord créé puis ce dernier est chiffré avec la clef privée. Le résultat et votre certificat accompagnent ensuite le message d'origine. Le destinataire de l'ensemble recalcule le haché et le compare au résultat du déchiffrement de la signature avec votre clef publique supposée. Il vérifie ensuite la validité de votre certificat.

Ce type de signature permet de transmettre la clef publique et le certificat à chaque correspondant.

Il y a deux façons de signer, soit en incluant le message à la signature, soit en chiffrant le message et sa signature. Cette dernière forme n'est qu'un chiffrement très pauvre car n'importe quelle application qui dispose de la clef publique peut l'inverser. La première forme permet de passer un contenu textuel à l'utilisateur en toute circonstance tandis que la deuxième l'interdit dès que le message a été altéré.

1.2.7. Le mot de passe

Le mot de passe correspond à un mot de passe originel Unix à ceci près qu'il est normalement plus long que 8 caractères et ne se limite pas forcément à un seul mot. De nos jours les systèmes Unix utilisent des hachés MD5 ou autres qui n'imposent plus de limitation de longueur de mot de passe.

1.2.8. L'infrastructure de clefs publiques

L'infrastructure de clefs publiques (PKI/Public Key Infrastructure) désigne le système de gestion et la base de données qui permettent de signer les certificats, de tenir à jour une liste de certificats révoquer, de distribuer les clefs publiques, etc. Il est le plus souvent accessible via un site web ou un serveur LDAP. Certaines entités sont également chargées de vérifier que vous êtes bien qui vous prétendez être. On peut avoir recours à une PKI commerciale connue dont le certificat racine se trouve déjà dans votre application. Un problème apparaît au niveau du courrier électronique pour lequel vous avez le choix entre l'emploi d'un certificat générique ou une facturation d'environ 100E par an pour chaque adresse électronique. De plus, il n'y a aucun moyen d'obtenir la clef publique de quelqu'un sans avoir reçu auparavant de ce correspondant son certificat (accompagné de sa clef publique).