Païou essaie de comprendre la sécurisation avec TLS ou SSL

Historique

1 octobre 2013 : Nouvelle page.

Difficulté

Pour : utilisateur un peu curieux.

Avec le développement d'Internet, vous pouvez faire des achats en ligne.
L'offre croît tous les jours, mais peut-on avoir une confiance totale dans le paiement par carte bancaire.
Une des façons de sécuriser ce paiement est d'utiliser des protocoles d'authentification et de chiffrement tels que TLS.

Mais cette sécurisation est également utilisée par des applications autres que le commerce par internet.

Le protocole SSL (Secure Socket Layer) est un protocole développé par Netscape. La première version du protocole a été testée par l'éditeur en interne, et la deuxième version (SSL v2) a été publiquement diffusée en 1994.
Actuellement la version utilisée est SSL v3.

Le développement de ce protocole a été repris par l'IETF au sein du groupe TLS (Transport Layer Security).

Le protocole TLS v1.0 a été normalisé en 1999 par l'IETF dans la RFC 2246 (cf. section Documentation) et présente quelques évolutions mineures par rapport à la version SSL v3.

Ces deux protocoles ne sont pas compatibles mais la plupart des serveurs et des navigateurs web peuvent mettre en œuvre les deux protocoles.
TLS a mis en place un mécanisme de compatibilité ascendante avec SSL.

TLS diffère de SSL pour la génération des clés symétriques. Cette génération est plus sécurisée dans TLS que dans SSLv3 dans la mesure où aucune étape de l'algorithme ne repose uniquement sur MD5 pour lequel sont apparues quelques faiblesses en cryptanalyse.

SSL et TLS sont tous les deux des protocoles situés entre le niveau Transport (TCP ou UDP) et le niveau Application (HTTP, FTP, POP, IMAP ...).
SSL et TLS se comportent en effet comme une couche intermédiaire supplémentaire. Ils sont indépendants du protocole utilisé au niveau application.
Cela signifie donc qu'ils peuvent aussi bien être employés pour sécuriser une transaction web, l'envoi ou la réception de courriels, etc...
SSL et TLS sont transparents pour l'utilisateur.

SSL et TLS on pour objectif de fournir les fonctionnalités :

• d'authentification : Le client doit pouvoir s'assurer de l'identité du serveur. Depuis SSL 3.0, le serveur peut aussi demander au client de s'authentifier.
  Cette fonctionnalité est assurée par l'emploi de certificats.
• de confidentialité : Le client et le serveur doivent avoir l'assurance que leur conversation ne pourra pas être écoutée par un tiers.
  Cette fonctionnalité est assurée par un algorithme de chiffrement
• d'intégrité : Le client et le serveur doivent pouvoir s'assurer que les messages transmis ne sont ni tronqués ni modifiés (intégrité), qu'ils proviennent bien de l'expéditeur attendu.
  Ces fonctionnalités sont assurées par la signature des données

Le client (par exemple le navigateur internet) et le serveur (par exemple site web en https) s'entendent sur les algorithmes et les clés à utiliser.

1. Le client envoie un message ClientHello. Celui-ci comprend :
   • la version de SSL/TLS que le client souhaite utiliser lors des négociations avec le serveur,
   • quelques octets aléatoires, générés par le client, utilisés par la suite pour créer la clé nécessaire au cryptage,
   • la liste des algorithmes de cryptage, appelée cipher_suite, le serveur utilisera celui qu'il connait et qui est le meilleur,
   • la liste des algorithmes de compression possibles pour le client, le serveur en utilisera éventuellement un pour compresser les messages,
   • en option : la liste des extensions qui pourront être utilisées pour augmenter encore la sécurité de la négociation.
     Ces extensions ne font pas partie du protocole TLS, mais elles utilisées si le serveur peut les exploiter.
2. Si le serveur n'est pas compatible avec les spécifications du client, il signale un échec de la négociation.
   Sinon, le serveur répond avec un message ServerHello qui comprend :
   • quelques octets aléatoires, générés par le client, utilisés par la suite pour créer la clé nécessaire au cryptage,
   • l'algorithme de cryptage, appelée cipher_suite, sélectionnée par le serveur dans la suite proposée par le client, pour l'authentification, l'encryptage et la vérification des messages (il choisit la suite la plus forte),
   • l'algorithme de compression des messages, choisi par le serveur dans la liste fournie par le client,
   • un identifiant de session
   • si une extension est acceptée par le serveur, elle est notifiée au client sous la forme d'un tag.
3. Le serveur envoie la commande certificate
   Cette commande est habituellement envoyée par le serveur. Elle comprend la liste des certificats que le client pourra utiliser pour authentifier le serveur et pour crypter des informations (il peut y avoir un ou plusieurs certificats).
   Si l'application qui se trouve sur le serveur (serveur web, par exemple), le serveur peut également envoyer au client une demande de certificat afin de pouvoir authentifier le client. Dans ce message, il précise quels sont les certificats qu'il peut traiter.
4. Le serveur envoie le message ServerHelloDone
   Il suit immédiatement le message précédent et indique la fin des messages du serveur et ce dernier attend la réponse du client.
   À ce stade le client possède maintenant toutes les informations nécessaires à la génération du Key Matérial dont le client et le serveur auront besoin pour crypter les données.
5. Client Key Exchange
   

   En travaux

   À réception du message ServerHelloDone, le client (le navigateur Internet) vérifie la validité du certificat numérique du serveur et des contrôles que le serveur "bonjour" les paramètres sont acceptables.
The client generates some bytes of data, encrypt them with the public key of the certificate it received and then sends the encrypted data to the server (this is called PreMaster secret and will be used to generate the Master secret). The algorithm by which the client protects the data is defined during the Client Hello and Server Hello messages. It can be RSA or Diffie-Hellman.