TLS/SSL

De Wiki info-lab.fr
Aller à : Navigation, rechercher

Sommaire

Présentation

SSL (Secure Socket Layer) est un protocole de sécurisation des échanges, développé à la base par Netscape et conçu pour assurer la sécurité des transactions sur Internet (essentiellement entre un client et un serveur HTTP) ; SSL, intégré depuis 1994 dans les navigateurs, est au dessus de la couche TCP et peut être considéré comme un protocole de couche 5.
Il existe plusieurs versions de SSL ou TLS : la version 2.0 de SSL a été développée par Netscape ; SSL version 3 et TLS (Transport Layer Security, RFC 2246) version 1.0 standardisés par l'IETF remplacent donc la version Netscape de SSL. N'étant pas compatible avec SSL, TLS (dans ses versions 1.0, 1.1 et 1.2) est devenu le standard de fait même si la littérature "commerciale" fait encore référence à SSL.
TLS Sur Wikipedia
TLS pour APACHE
TLS/SSL sur securiteinfo.com

But recherché

TLS permet d'assurer les services de sécurité suivants :

  • confidentialité : elle est obtenue par l'utilisation d'algorithmes à chiffrement symétrique tels que DES, IDEA, 3DES, RC4, AES ...
  • intégrité : l'intégrité des données est assurée par l'utilisation de HMACs (Message Authentication Code RFC 2104) basés sur les fonctions d'empreinte MD5 (16 octets) ou SHA-1 (20 octets).
  • authentification : TLS permet l'authentification des 2 entités (même si l'authentification du client est facultative) basée sur des certificats X.509 ou de simples clés publiques, et l'authentification des données grâce aux HMACs.

Fonctionnement

Les sous-protocoles de SSL

Le protocole SSL est constitué de quatre sous-protocoles, et TLS a gardé cette structure :

  1. Le protocole SSL Handshake.
  2. Le protocole SSL Change Cipher Spec (CCS).
  3. Le protocole SSL Record.
  4. Le protocole SSL Alert.

Le protocole Handshake

Ce protocole permet l'authentification obligatoire du serveur, celle optionnelle du client et la négociation des méthodes de chiffrement, d'empreinte et de compression qui seront utilisées lors de la session.
Déroulement habituel d'un handshake SSL avec authentification mutuelle :

en noir, les messages du serveur.
en rouge, les messages du client.

SSL.gif

Les échanges définis par le protocole SSL se déroulent en deux phases:

  1. Première phase, authentification du serveur : Suite à la requête d'un client, le serveur envoie son certificat au client (ou a défaut sa clé publique s'il ne possède pas de certificat) et lui liste les algorithmes cryptographiques, qu'il souhaite négocier. Le client vérifie la validité du certificat à l'aide de la clé publique du CA (Certificate Authority) contenue dans le navigateur, ou accepte la clé publique. Si le certificat est valide ou la clé publique acceptée, le client génère un pré-master secret (PMS) de 48 octets qui servira à dériver le master secret (MS) de même taille, 48 octets, ce qui représente l'entropie maximale de la clé. Ce PMS est chiffré avec la clé publique du serveur puis transmis à ce dernier. Les données échangées par la suite entre le client et le serveur sont chiffrées et authentifiées à l'aide de clés dérivées de la clé maître.
  2. Deuxième phase, authentification (optionnelle) du client : Le serveur (et seulement lui) peut demander au client de s'authentifier en lui demandant tout d'abord son certificat. Le client réplique en envoyant ce certificat puis en signant un message avec sa clé privée (ce message contient des informations sur la session et le contenu de tous les échanges précédents).

Remarques :

  • L'authentification du client est facultative et au bon vouloir du serveur ; de fait elle est rarement utilisée sauf dans le cas de VPN d'entreprises.
  • L'authentification du réseau intervient dans tous les cas avant celle du client, ce qui est un gage de sécurité accrue.
  • Comme dans IPSec (IKE phase 1), l'authentification reprend les échanges précédents et valide ainsi tout le handshake.
  • Seule la clé publique du serveur est utilisée pour faire du chiffrement ; celle du client ne sert que pour de la signature.

Contenu des messages du Handshake

  • ClientHello : Initialisation de la communication, le client renseigne les champs suivants : version la version du protocole SSL, client_random nombre aléatoire, session_id l'identificateur de session, cipher suite la liste des suites de chiffrement supportées, et algo decompression la liste des méthodes de compression.
  • ServerHello : Réponse au "Hello", précise version la version du protocole SSL, Server_random nombre aléatoire, session_id l'identificateur de session, cipher suite la liste des suites de chiffrement choisies, et algo decompression la liste des méthodes de compression. Le champ Certificate contient le certificat de serveur (s'il en possède un), et enfin c'est ici que le serveur peut demander au client de s'authentifier.
  • ServerKeyExchange : Si les certificats ne sont pas supportés, ce message permet l'échange des clés publiques.
  • CertificateRequest : le serveur réclame un certificat au client.
  • CertificateMessage : le client envoie le certificat réclamé par le serveur.
  • NoCertificate : Le client précise qu'il n'a pas le certificat réclamé.
  • CertificateVerify : vérification explicite du certificat du serveur par le client.
  • ServerHelloDone : Message indiquant que le serveur a répondu à tous les messages, seul le client peut optionnelement continuer ou terminer par un message "Finished"..
  • ClientKeyExchange : ce message contient le PreMastersecret chiffrée à l'aide de la clé publique du serveur.
  • Finished : fin du protocole Handshake. Ce message doit être suivi d'un message généré par le sous-protocole CCS validant tout ce qui a été précédemment négocié.

Variables d'état d'une session SSL

Une session SSL est définie par les variables suivantes:

  • Session ID (l'dentifiant de session) une séquence arbitraire de 32 octets choisie par le serveur pour identifier une session.
  • Peer certificate (le certificat du pair) c'est un certificat X 509 du correspondant (soit pour un serveur ou un client).
  • Compression method l'algorithme de compression utilisé, NULL pour l'instant (ce champ reste vide)
  • Cipher spec (la suite de chiffrement) définit les algorithmes de chiffrement et d'empreinte
  • MasterSecret c'est un clé de 48 octets partagée entre le client et le serveur.
  • Is resumable (le drapeau) c'est un flag qui indique si il est possible d'ouvrir de nouvelles connexions sur la session en question.

Variables d'état d'une connexion SSL

Les paramètres qui définissent une connexion SSL sont ceux qui se seront rafraîchis pendant une session lors d'établissement d'une nouvelle connexion. Ces paramètres sont:

  • Server_random et Client_random: deux nombres aléatoires de 32 octets, générés par le client et le serveur lors de chaque connexion.
  • Server_MAC_write_secret: clé secrète utilisé par le serveur pour calculer les MACs
  • Client_MAC_write_secret: clé secrète utilisé par le client pour calculer les MACs
  • Server_write_key: clé symétrique utilisé par le serveur pour le chiffrement des données.
  • Client_write_key: clé symétrique utilisé par le client pour le chiffrement des données.
  • Initialization vectors : vecteur d'initialisation (IV) pour le chiffrement par bloc en mode CBC (Cipher Bloc Chaining), l'un du coté serveur et l'autre du coté client.
  • Sequence number: chaque message est numéroté, l'un pour le serveur, l'autre par le client, et chacun codé sur 8 octets.

Le protocole ChangeCipherSpec (CCS)

Ce protocole comprend un seul et unique message (1 octet) qui porte le même nom que le protocole, il permet d'indiquer au protocole SSLRecord la mise en place des algorithmes de chiffrement qui viennent d'être négociés.

Le Protocole SSLRecord

Intervenant après l'émission du message ChangeCipherSpec (CCS), Il a pour rôle de :

  • chiffrer les données pour assurer leur confidentialité.
  • garantir l'intégrité et l'authentification des données échangées à l'aide des mécanismes de condensat.

SslRecord fonctionne en parallèle avec SslAlert.

Le protocole SSL Alert

Ce protocole génère des messages d'alerte suite aux erreurs que peuvent s'envoyer le client et le serveur. Les messages sont composés de 20 octets, le premier étant soit fatal soit warning. Si le niveau de criticité du message est fatal, la connexion TLS/SSL est abandonnée. Le deuxième octet est utilisé pour désigner le code d'erreur.

  • Liste des Messages de type erreur fatale du protocol Alert :
    • bad_record_mac: réception d'un MAC (ou HMAC) erroné
    • decompression_failure: les données appliquées à la fonction de compression sont invalides
    • handshake_failure: impossibilité de négocier les bons paramètres
    • illegal_parameter: un paramètre échangé au cours du protocole Handshake ne correspondait pas avec les autres paramètres
    • unexpected_message: message non reconnu.
  • Liste des Messages de type warning du protocol Alert
    • bad_certificate: le certificat n'est pas bon
    • certificate_expired: certificat périmé
    • certificat_revoked: certificat révoqué
    • certificat_unknown: certificat invalide pour des raisons précisés au dessus
    • close_notify: fin d'une connexion
    • no_certificate: réponse négative à une demande de certificat
    • unsupported_certificate: le certificat reçu n'est pas reconnu

Aspects cryptographiques de SSL/TLS

Le handshake SSL permet aux 2 entités de choisir une suite d'algorithmes cryptographiques pour assurer la sécurité de leurs échanges. Cette suite sera de la forme SSL_X_WITH_Y_Z où :

  • X désigne l'algorithme utilisé pour l'échange de clés : DSA, RSA ou Diffie-Hellman avec signature DSS ou RSA. Notez que DH n'est supporté que par la version 3.0 et non par la 2.0 de SSL. D'autre part, son implémentation n'est pas sensible aux attaques type man-in-the-middle car les paramètres d'exponentiation sont authentifiés par les 2 extrémités.
  • Y désigne l'algorithme de chiffrement
  • Z désigne l'algorithme d'empreinte

La version 3.0 de SSL permet 31 possibilités de suites d'algorithmes cryptographiques différentes. Une de ces possibilités est de ne rien utiliser, ce qui revient à utiliser des algorithmes fictifs ne modifiant pas les données, ce que nous désignons comme suit :

SSL_NULL_WITH_NULL_NULL 

Un autre exemple est :

SSL_RSA_WITH_DES_CBC_MD5 

Intégrité et authentification

L'intégrité est assurée au moyen de MACs (messages authentication codes), qui ont la double spécificité d'assurer à la fois intégrité et authentification des données. Un MAC allie une fonction de hachage (ici MD5 ou SHA-1, d'où une longueur finale de 16 ou 20 octets) à une clé secrète partagée par les 2 entités. Une façon habituelle de générer des MACs est d'utiliser la fonction HMAC RFC 2104; SSL en version 2 n'utilise pas le standard HMAC mais définit sa propre fonction de MAC, par contre HMAC est entièrement supporté à partir de SSL 3.0
Attention, les illustrations font abstraction des en-têtes des couches inférieures, qui ne sont pas inclus dans les données protégées. SSL MAC.gif

Après génération du MAC, les données sont directement envoyées dans la fonction de chiffrement.

Confidentialité

Le chiffrement peut-être soit par flots, soit par blocs, suivant l'algorithme choisi. Prenons l'exemple du chiffrement par flot (en gris les données chiffrées):

SSL MAC Flot.gif

Quant au chiffrement par blocs, il est nécessaire de rajouter du bourrage (padding) avant le traitement, pour que la longueur totale des données à traiter soit un multiple de la taille d'un seul bloc (n x 64 bits par exemple).

SSL MAC Bloc.gif

Utilisation d'OpenSSL

Générer un certificat x509 ; création d'une clé privée RSA 2048 bits :

openssl genrsa -out server.key 2048

Générer une demande de certificat à partir de cette clé privée (les informations à renseigner doivent correspondre à la future utilisation de ce certificat, notamment le champ Common Name qui doit indiquer l'URL du "virtual host HTTPS" si le certificat aura cet usage) :

openssl req -new -key server.key > server.csr
 Country Name (2 letter code) [AU]:FR
 State or Province Name (full name) [Some-State]:PROVINCE
 ......................................

Le fichier .csr ainsi crée doit être soit signé par une autorité de certification, soit auto-signé en créant sa propre autorité de certification.
Choix de la seconde possibilité et création d'une clef privée pour cette autorité :

openssl genrsa -des3 1024 > ca.key

Cette clé privée sera protégée par une passphrase à renseigner à sa création.
A partir de cette clef privée, génération du certificat x509 auto-signé de notre future autorité, valide par exemple 5 ans  ; la passphrase de la clef privée sera demandée (les informations à renseigner doivent identifier l'autorité de certification) :

openssl req -new -x509 -days 1825 -key ca.key > ca.crt
 Country Name (2 letter code) [AU]:FR
 State or Province Name (full name) [Some-State]:PROVINCE
 ......................................

Cette autorité fraîchement crée peut maintenant signer

openssl x509 -req -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -CAserial ca.srl

L'argument CAcreateserial n'est nécessaire que lors de la première signature d'un certificat. Il faudra à nouveau saisir la passphrase de la clef privée de notre autorité. Le fichier certificat pour notre serveur est server.crt.

L'utilisation d'une autorité de certification personnelle :

  • soit provoquera un avertissement des clients se connectant à la ressource qui utilise les certificats qu'elle aura signée
  • soit pour éviter ces avertissements, l'autorité de certification doit être reconnue par les clients : Les navigateurs peuvent ajouter de nouvelles autorités reconnues, il suffit de leur faire importer le fichier ca.crt de notre autorité.

Calculer l'empreinte de la clé publique d'un certificat :

openssl x509 -sha1 -fingerprint -noout -in /etc/ssl/certs/certificat.pem
SHA1 Fingerprint=9E:6F:E1:9C:5F:AE:45:E8:76:A9:68:28:9D:AF:C5:26:3E:D7:52:8E

Faiblesses de TLS/SSL et attaques possibles

  • TLS/SSL est théoriquement vulnérable aux attaques par force brute en cas d'utilisation de clés 40 bits, il est donc conseillé d'utiliser des clés de 128 bits minimum si la législation locale le permet.
  • Si l'authentification du serveur est obligatoire, malheureusement celle du client est optionnelle.
  • SSL est très vulnérable aux attaques par le milieu (man in the middle): l'attaquant intercepte (physiquement) la requête du client et se fait passer pour le serveur auprès de lui, tout en se faisant passer pour un client auprès du serveur légitime. Il reçoit donc la totalité du flux supposé protégé. Son implémentation devrait donc être rigoureuse, mais souvent SSL est implémenté de manière trop laxiste, notamment en ce qui concerne la vérification des certificats des serveurs. En effet, tout client (par exemple un navigateur) devrait vérifier la signature, la validité ainsi que le statut de révocation du certificat (au moyen de CRLs ou du protocole OCSP) et devrait s'assurer que le CA concerné appartient bien aux CAs auxquels il fait confiance. Or cela n'est pas obligatoire, et peut permettre à un attaquant de substituer sa propre clé publique à celle du serveur original puis de rediriger le trafic vers son faux site tout en faisant croire au client qu'il communique bien avec son serveur légitime. Il est donc important de bien vérifier les URLs par exemple. Si la manière d'implémenter TLS/SSL est problématique avec certains navigateurs, elle est carrément catastrophiques pour nombres d'applications utilisées sur des plateformes mobiles (applications pour smartphones utilisant SSL/TLS) où n'importe quel certificat est accepté automatiquement sans vérification auprès d'une AC (dans le cas d'une clé publique elle est aussi acceptée silencieusement sans en référer à l'utilisateur) ce qui expose grandement aux attaques par le milieu : Dans ces conditions la mise en place de TLS/SSL trompe l'utilisateur avec un faux sentiment de sécurité.
  • SSL est éventuellement vulnérable à des attaques plus poussées, basées sur des propriétés cryptographiques. L'utilisation de certificats par exemple nécessite une grande vigilance (date de validité, multitude de CAs inconnus certifiant tout et n'importe quoi... Il suffit de jeter un coup d'oeil à la liste contenue dans n'impote quel navigateur pour s'en rendre compte); il existe également des attaques par brute-force sur l'échange de la clé symétrique (2^20 essais) ou des attaques dites de rollback dans lesquelles l'attaquant cherche à modifier le choix des algorithmes d'échanges de clés de façon à ce que les 2 entités n'utilisent pas les mêmes (RSA et DH par exemple). Ainsi, cet attaquant pourra déchiffrer le message car les paramètres fournis par le serveur dans le cas d'un algorithme n'offrent aucune sécurité si on les applique à un autre... Cette attaque peut-être réalisée si une session 3.0 est résumée en session 2.0 par exemple.
  • Enfin le comportement peu sérieux voire "léger" de nombreuses autorités de certification peut mettre à mal toute la chaîne de confiance TLS/SSL si des certificats ont été compromis ou transmis à de mauvaises personnes : Voir par exemple les incidents chez Comodo et DigiNotar.
Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Outils