Clé maitre = P RF(clé préliminaire, master secret, ClientHelloRandom.ServerHelloRandom)

SSL et TLS 1) Introduction Le protocole SSL, Secure Socket Layer définit une connexion sécurisée au-dessus d une couche transport fiable, TCP, Transfer Control Protocol, par exemple. La version SSLv2 a été mise au point par Netscape Communication Corporation début 1995. Cette version était buggée et SSLv3 est lancée fin 1995. Le protocole TLS, Transport Layer Security, défini par l IETF, Internet Engeneering Task Force, rfc 2246 en 1998 et publié en janvier 1999 est proche de la version SSLv3. Le protocole TLS v1.2 est défini 5246. Etant au-dessus de la couche transport, SSL n est pas implanté sur le réseau mais par l émetteur et le récepteur. Certains considèrent SSL comme appartenant à la couche session. Il peut être employé de façon transparente par différentes applications comme HTTP, HyperText Transfer Protocol, LDAP, Lightweight Directory Protocol qui est un protocole d accès à des annuaires, IMAP, Interactive Mail Access Protocol, rfc 1064, qui gère une boîte à lettres accessible de plusieurs ordinateurs, POP3, Post Office Protocol, rfc 1225, qui sert à rapatrier du courrier d une boîte à lettres distante vers un ordinateur local. Le protocole SSL sert souvent dans le e-commerce. Il est, en général, intégré aux navigateurs. Un site Web sécurisé avec SSL ou TLS a son adresse URL, Uniform Resource Locator commençant par https : // Sur le navigateur, on reconnaît, en général, une session sécurisée avec SSL ou TLS par la présence d un cadenas. Beaucoup d applications ont deux versions: une version sécurisée avec SSL, l autre pas. Les numéros de port pour ces 2 versions sont différents. Numéro de port d HTTP: 80. Numéro de port d HTTPS: 443 Numéros de port de FTP, File Transfer Protocol: 20 (données) et 21 (contrôle). Numéros de port de FTPS: 989 (données) et 990 (contrôle). Numéros de port pour IMAP: 143. Numéros de port pour IMAPS: 993. Certaines applications utilisent le même numéro de port pour les messages sécurisés et pour les autres. Ainsi la rfc 2817 permet à HTTP d utiliser SSL sur le port 80. Le protocole SSL est orienté client serveur. Il réalise l échange de clés mais pas en général avec le protocole de DH, Diffie-Hellman, l authentification du serveur par le client au moment de la mise en place. En exploitation, les messages peuvent être authentifiés, cryptés et compressés. 2) Le protocole SSL est composé essentiellement de 2 protocoles: SSL-handshake et SSL- 1

record. Il y a aussi 2 protocoles plus petits: SSL-change-cipher spec protocol et SSL-alert protocol. 2.1) SSL-handshake protocol Il est réalisé par la sous-couche SSL-handshake layer. Il consiste en une négociation. Le client fait au serveur une proposition principale et une proposition alternative. Ceci constitue le message ClientHello. Le message ClientHello comporte une structure ClientHello.random contenant un nombre aléatoire. Le serveur détermine la proposition définitive à partir de ces 2 propositions et l envoie au client. C est le message ServerHello. Le message ServerHello comporte une structure ServerHello.random contenant un nombre aléatoire. A l issue de cette négociation, un ensemble de paramètres est défini. Ces paramètres sont un identifiant de session, la version de SSL ou de TLS utilisée, une méthode de compression de données (aucune, PKZip, gzip...) et d autres paramètres appelés suite de chiffrement. L identifiant de session est une séquence d octets choisie par le serveur. Elle permet d identifier et de reprendre une session. La suite de chiffrement comporte la méthode utilisée pour l échange des clés (RSA, Rivest Shamir Adelman, DH, DH+ DSA, Digital Secure Algorithm, DH+RSA...), la méthode de chiffrement en exploitation ( aucune, 3DES-EDE-CBC, 3Data Encryption Standard-Encryption Decryption Encryption-Cipher Block Chaining, AES-128-CBC, Advanced Envryption Standard-128-CBC,...), la méthode de hachage en exploitation (SHA256, Secure Hash Algorithm MD5, MessageDigest5...) pour l authentification (code HMAC, Hashed Message Authentication Code). Le client s assure, alors de la clé publique du serveur. Les navigateurs sont livrés avec des certificats de confiance d AC, Autorité de Certification, c est-à-dire avec des clés publiques certifiées. Le serveur envoie le message Certificate contenant un de ses certificats émis par une AC. Si l AC n est pas reconnue par le client, le serveur peut lui envoyer la chaîne de certificats qui permettra au client de s assurer de la clé publique du serveur. TLS (rfc 5246) ne prévoit pas l envoi par le serveur de listes de certificats révoqués (CRL, Certificate Revocation List). Par contre rien n empêche le module chargé de valider les certificats de consulter des CRLs. Par contre, le serveur ne s assure pas tout le temps de la clé publique du client. Par exemple, SSL sert souvent dans le e-commerce et si le serveur demandait l authentification du client, ce dernier pourrait trouver le temps trop long. De plus, les clients n ont pas toujours de certificats numériques. Pour beaucoup d applications, le serveur peut authentifier par un autre moyen le client. Par exemple, dans le e-commerce, il peut authentifier son interlocu- 2

teur à partir des renseignements contenus sur la carte de paiement. Dans certains cas, notamment quand la méthode DH est choisie pour l échange de clés, le serveur envoie, juste après le message Certificate, le message ServerKeyExchange pour fixer un certain nombre de paramètres. Le serveur envoie le message ServerHelloDone pour indiquer que le client peut commencer le processus d échange de clés. Le client et le serveur se mettent d accord sur un secret partagé: c est la clé maître préliminaire. Pour cela, si la méthode RSA a été choisie dans le suite de chiffrement, le client génère une valeur de 48 octets et l envoie, dans le message ClientKeyExchange, chiffrée avec la clé publique du serveur, au serveur. Seul le serveur pourra déchiffrer le secret. Le serveur et le client calculent une clé maître à partir de la clé préliminaire et des champs random des messages ClientHello et ServerHello. On a: Clé maitre = P RF(clé préliminaire, master secret, ClientHelloRandom.ServerHelloRandom) où PRF, PseudoRandomFunction construit des résumés de longueur variable utilisant les codes HMAC et les fonctions de hachage MD5 et SHA1. La clé préliminaire ne sert plus et la rfc 5246 conseille de l effacer. Le code de PRF est donné section 3. Si le serveur n a qu une clé RSA (K s, K s ) Clé publique Clé privée destinée à l authentification, il peut générer une clé RSA temporaire (K t, K t ) et envoyer au client D K s (K t ), K t. Le client génèrera la clé préliminaire K et enverra E Kt (K). Le client et le serveur vérifient que l entité paire connaît la clé maître en envoyant chacun un message Finished fabriqué à partir des messages précédents (les champs random évitent le rejeu) et de la clé maître. Le message envoyé par le client est PRF(CléMaître, Client Finished, MD5(messages précédents).sha1(messages précédents)) Le message envoyé par le serveur est PRF(CléMaître, Server Finished, MD5(messages précédents).sha1(messages précédents)). Comme le client est sûr de la clé publique du serveur à cause du certificat envoyé, il est sûr que seul le serveur pourra décrypter la clé préliminiaire. Si le message reçu par le client est, pour celui-ci, un bon cryptage, le client est sûr de parler avec l entité qui connaît la clé maître, c est-à-dire avec l entité qui a pu décrypter la clé préliminaire, c est-à-dire avec le serveur. Le serveur 3

n a pas authentifié le client. Un intrus a pu se faire passer pour le client et persuader le serveur que son RSA est celui du client. Schématiquement, sans authentification du client, SSL-handshake consiste en les échanges suivants: ClientHello Client ServerHello Cerificate ServerKeyExchange (optionnel) ServerHelloDone ClientKeyExchange Finished Serveur Si le serveur demande l authentification du client et si la méthode RSA a été choisie dans le suite de chiffrement, le client envoie son certificat numérique dans un message de type Certificate. Après avoir envoyé la clé préliminaire cryptée au serveur, le client envoie le message CertificateVerify contenant la signature D K c (H(messages précédents)), où (K c, K c) Clé publique Clé privée et H est une fonction de hachage définie dans le message ServerKeyExchange qui est alors envoyé. Le serveur peut s assurer que l émetteur est bien le client. En effet, messages précédents dépend de la clé préliminaire et le code D K c (H(messages précédents)) du message CertificateVerify assure que cet envoi vient du client L envoi du message PRF(CléMaître, Client Finished, MD5(messages précédents).sha1(messages précédents)), vu plus haut, permet au serveur de terminer l authentification du client en s assurant que ce dernier connaît bien le secret. Schématiquement, avec authentification du client, SSL-handshake consiste en les échanges suivants: 4

ClientHello Client ServerHello Cerificate Server Key Exchange le serveur demande le certificat ServerHelloDone Cerificate ClientKeyExchange CertificateVerify Finished Serveur La méthode de DH, peut être utilisée pour fixer la clé préliminaire. La méthode est un peu différente de la méthode reposant sur RSA car le client ne génère pas un secret qu il envoie crypté mais le client et le serveur dérouleront l algo de DH classique. Il y a 3 méthodes de DH possibles: la méthode de DH fixe, la méthode de DH éphémère, la méthode de DH anonyme. Le client utilisera un système ayant les mêmes paramètres (même groupe, même générateur) que celui du serveur. La méthode de DH fixe consiste en l envoi par le serveur d un certificat de clé DH. La méthode de DH éphémère consiste en l envoi par le serveur d un certificat de csa (DSA, RSA), puis des éléments publics de l algo de DH (groupe, générateur de groupe, clé publique). Ce deuxième envoi avec les nonces des messages hello est signé par le csa. Que ce soit la méthode de DH fixe ou éphémère, le client communique au serveur sa clé publique de DH. Cela se fait soit dans un certificat de DH dont les paramètres sont les mêmes que ceux du serveur, soit explicitement. Dans ce dernier cas, l envoi doit être authentifié par un csa et le serveur peut, optionnellement, demander le certificat du csa au client. L authentification du serveur par le client avec les méthodes DH fixe et DH éphémère est analogue à celle avec la clé RSA: si le client constate que le message Finished reçu est correct, il conclut que son interlocuteur connaît le secret. L interlocuteur n a pu fabriquer le secret que grâce à la clé privée associée à la clé publique qu il a reçue. Comme le client est sûr que la clé publique est celle du serveur, grâce au certificat, il est sûr que son interlocuteur est le serveur et que lui seul connaît le secret. Si le client envoie un certificat de DH, il sera authentifié à l issue du SSLhandshake protocol. Sinon, l authentification du client est optionnelle, le 5

client n envoyant le certificat authentifiant sa clé publique de DH éphémère que si le serveur le demande dans un message Certificate Request. Si les 2 communicants choisissent l échange de certificats de DH pour s authentifier, la clé préliminaire sera toujours la même, quelle que soit la session, mais la clé maître construite à partir des nonces sera différente. La méthode de Diffie-Hellman anonyme est spéciale car, dans ce cas il n y a pas d authentification des 2 communicants A et B. Il n y a pas d envoi de certificats. Une attaque par le milieu est possible. 2.2) SSL-change cipher spec protocol Il consiste en l envoi par les 2 entités du message ChangeCipherSpec juste avant l échange Finished dans le protocole SSL-handshake pour avertir la sous-couche SSL-record de l entité paire du changement de paramètres. Comme le message ChangeCipherSpec n appartient pas au protocole handshake, il ne figure pas sur les schémas ci-dessus. 2.3) SSL-alert protocol En exploitation, une entité peut envoyer un message d alerte d erreurs en cas d anomalies constatées. Ce message décrit l anomalie. Il y a 2 types de message d alerte: le type fatal et le type warning. Après avoir envoyé ou reçu un message de type fatal, une machine doit fermer la connexion et oublier tout ce qui se rapporte à cette connexion (identifiant de session, secret,...), de façon à ce que celle-ci ne puisse pas être reprise. La fermeture d une session TLS se fait par l envoi d un message d alerte de notification de fermeture. L émetteur E de ce message (client ou serveur) ferme, tout de suite, la session TLS en écriture. A la réception du message, le récepteur doit répondre par le même type de message et fermer la session immédiatement. L émetteur E n est pas obligé d attendre le message réponse de notification de fermeture pour fermer la session en lecture. 2.4) SSL-record protocol A partir de la clé maître, le serveur et le client vont générer, à l aide de la fonction PRF, 4 ou 6 clés secrètes, deux des clés sont optionnelles. Trois clés sont utilisées pour le trafic dans un sens, les trois autres pour le trafic dans l autre sens. Il y a une clé pour le chiffrement, une autre pour l intégrité des données (hachage), une autre, optionnelle, pour générer de façon aléatoire les vecteurs d initialisation (IV, Initialization Vectors) pour le chiffrement. Pour générer les 6 clés, SSL-record génère un bloc secret qui est divisé en 6 blocs de taille adéquate: bloc secret = P RF(clé maitre, Key expansion, serverrandom.clientrandom) où serverrandom et clientrandom sont les nonces des messages ClientHello et ServerHello maintenant stockés dans des structures. 6

La sous-couche SSL-record assure, alors, le transfert des données de façon sécurisée. Le processus suivi par l émetteur est le suivant, certaines fonctions pouvant ne pas exister: les données sont compressées. Elles sont hachées avec la clé K HMAC pour contrôler l intégrité des données. Un résumé HMAC, Hashed Message Authentication Code est ainsi généré. Ceci procure l intégrité des données et l authentification réelle si l émetteur est le serveur. Le message envoyé est le chiffrement avec la clé secrète générée pour le chiffrement de la concaténation du message compressé et du résumé HMAC. Les algos de chiffrement par bloc sont implantés en mode CBC, Cipher Block Chaining. Le chiffrement par flux se fait avec RC4, Ron s Code 4. Le récepteur déchiffre le message reçu. Il est le seul à pouvoir le faire avec l émetteur, contrôle la signature et décompresse les données. Par exemple, si l émetteur veut envoyer le message mes, il envoie C = E KDES (compress(mes).hmac(k HMAC, compress(mes))) où. est la concaténation. Le récepteur déchiffre C. Il calcule à partir du champ compress(mes) reçu le résumé HMAC(K HMAC, compress(mes)). S il est identique au résumé reçu, les données sont intègres et il décompresse le champ compress(mes). Le résumé HMAC d un texte txt construit avec un secret partagé K HMAC est H ((K HMAC ch1).h ((K HMAC ch2).m)) où H est une fonction de hachage et ch1 = 0x5C 0x5C... 0x5C } {{ } B et ch2 = 0x36 0x36... 0x36 } {{ } B avec B la longueur en octets des blocs traités par H. A tout moment, le client peut envoyer un message ClientHello pour entamer la négociation en vue de redéfinir les paramètres de sécurité. A tout moment, le serveur peut envoyer un message HelloRequest. Le client pourra alors envoyer un message ClientHello pour renégocier les paramètres envoyés. Si le client n envoie rien, le serveur peut envoyer un message SSL-alert de fermeture de connexion. Si le numéro de session du message ClientHello est le numéro de session courant, les seuls nouveaux paramètres sont ClientHelloRandom et Server- HelloRandom. La clé maître n est pas recalculée. Les clés de session le sont avec les nouveaux paramètres. Avec cette technique, la découverte de la clé maître permet de connaître d autres secrets. Le système n a pas la propriété PFS, Perfect Forward Secrecy, i.e. que la découverte d un secret permet d en découvrir d autres. 7

Si le numéro de session est celui d une autre session active ou un ancien numéro de session entre le même client et le même serveur, son nouveau bloc secret sera calculé avec la clé maître associée à ce numéro de session et avec les nouveaux nonces du client (message ClientHello) et serveur (message ServerHello). La rfc 5996 recoomande de limiter la durée de vie d un numéro de session à 24 heures. Si la numéro de session du message ClientHello est nouveau, le protocole Handshake est exécuté dans sa totalité. Avec cette technique, le système a la propriété PFS. 3) Qualités des secrets Lorsque le système RSA seul est utilisé dans l échange des clés, la découverte de sa clé privée entraîne la découverte de toutes les clés préliminaires qu elle a cryptées et qu elle pourra encore cryptées si sa compromission n est pas connue, et donc de toutes les clés de session associées. De même la découverte d une clé de DH fixe entraîne la découverte de toutes les clés préliminaires qu elle a permis de définir et qu elle pourra encore définir si sa compromission n est pas connue, et donc de toutes les clés de session associées. Par contre, si DH éphémère est utilisé par les deux communicants, la découverte d une clé privée d un des systèmes entraîne celle d une clé préliminaire et des clés de session que cette clé préliminaire a permis de définir. La découverte d une clé privée de DH éphémère est, à priori, moins probable que celle de DH fixe le système de DH éphémère ne servant pas longtemps. 4) Attaques contre TLS 4.1) Attaques contre TLS peu sécurisés Certificat du serveur (ou du client si celui-ci est demlandé) non réellement vérifié. Certificats révoqués non consultés. 4.2) Attaque de DoS, Deny of Service TLS repose sur TCP. Les attaques de DoS visant l établissement de la connexion TCP, comme le SYN-flood, peuvent paralyser un serveur TLS. Cette attaque n est pas contre TLS mais contre un protocole encapsulmant TLS. De même, l envoi de TCP-PDU avec le drapeau RST avec un numéro de séquence valide sur des connexions établies les ferme. L emploi d IPSec permet de contrer ces attaques. 5) La fonction PRF Soit a un secret qu on coupe en 2: a = al.ar. 8

La fonction PRF utilisée par SSL est la suivante: PRF(a, b, c) = P MD5(aL, b.c) P SHA1(aR, b.c) (rfc 2246) ou avec PRF(a, b, c) = P SHA 256(aR, b.c) (rfc 5246) P H(a, b) = HMAC H (a, A[1].b).HMAC H (a, A[2].b).HMAC H (a, A[3].b) avec A[0] = b, A[i] = HMAC H (a, A[i 1] pour i > 1 On voit que PRF dépend de la longueur de la sortie attendue. Par exemple, SHA1 produisant des résumés de 160 octets, si on veut une sortie de 512 octets, il faut calculer A[1], A[2], A[3], A[4] P SHA1 produit alors une sortie de 640 octets On jette les 128 octets les plus à droite. Bibliographie B. Favre, P.A. Goupille, Guide pratique de sécurité informatique, Dunod, 2005. H.X. Mel et Doris Baker La cryptographie décryptée Campus Press 2001. Natkin, Les protocoles de sécurité d Internet, Dunod, 2002. rfc 2246, 5246, TLS protocol rfc 2817, HTTP Upgrade to TLS 9