SSL : Secure Socket Layer

Publié le par e-commerce

Qu'est-ce que c'est ?

SSL(Secure Socket Layer) est un protocole de sécurisation des échanges, développé par Netscape. Il a été conçu pour assurer la sécurité des transactions sur Internet (notamment entre un client et un serveur), et il est intégré depuis 1994 dans les navigateurs. Il existe plusieurs versions: la version 2.0 développée par Netscape; la version 3.0 qui est actuellement la plus répandue, et la version 3.1 baptisée TLS (transport Layer Security, RFC 2246) et standardisée par l'IETF (Internet Engineering Task Force). SSL fonctionne de manière indépendante par rapport aux applications qui l'utilisent; il est obligatoirement au dessus de la couche TCP et certains le considèrent comme un protocole de niveau 5 (couche session).



Pourquoi SSL ?


SSL permet d'assurer les services de sécurité suivants:
  • confidentialité : elle est obtenue par l'utilisation d'algorithmes à chiffrement symétrique de blocs comme DES, FORTEZZA, IDEA, 3DES ou RC2, ou par des algorithmes à chiffrement symétrique de flots comme RC4 (la longueur des clés peut être limitée suivant les législations propres à l'exportation, et le padding correspondant s'applique aux algorithmes par blocs).
  • intégrité : l'intégrité des données est assurée par l'utilisation de MACs (Message Authentication Code) basés sur les fonctions de hachage MD5 (16 octets) ou SHA-1 (20 octets).
  • authentification : SSL permet l'authentification des 2 entités (authentification client facultative) basé sur des certificats X.509, et l'authentification des données grâce aux MACs.



Les sous-protocoles de SSL


Le protocole SSL est constitué de quatre sous-protocoles:
1 ) Handshake qui permet l'authentification mutuelle du client et serveur, la négociation des algorithmes de chiffrement, de hachage, et l'échange des clés symétriques qui assurent le chiffrement.
2 ) le protocole SSL Change Cipher Spec
3 ) le protocole SSL Alert
4 ) le protocole SSL Record


Déroulement des échanges SSL


Déroulement habituel d'un handshake SSL avec authentification mutuelle :
  • en noir, les échanges initiés par le serveur.
  • en rouge, les échanges initiés par le client.
  • en jaune, les échanges correspondants à l'authentification du client.



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 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. Si le certificat est valide, 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. Elle est en fait rarement utilisée dans la vie courante (qui possède une paire de clés RSA certifiée?).
  • 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.
  • Notez enfin que seule la clé publique du serveur est utilisée pour faire du chiffrement; celle du client ne sert que pour de la signature.



Les 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 de hachage
  • 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.

  • Les 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 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 Handshake


    Ce protocole permet l'authentification obligatoire du serveur, du client est optionnelle, et de négocier pour choisir les suites de chiffrement qui seront utilisées lors de la session.


    Déroulement des échanges du Handshake



    * message optionnel

    • ClientHello : ce message contient: la version: version du protocole SSL,client_random: nombre aléatoire, session_id:l'identificateur de session, cipher suite :la liste des suites de chiffrement choisies, et algo décompression: la liste des méthodes de compression.
    • ServerHello : ce message contient: la version: 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 décompression: la liste des méthodes de compression.
    • Certificate : ce message contient soit le certificat de serveur
    • ServerKeyExchange : contient le certificat de signature
    • CertificateRequest : le serveur réclame un certificat au client
    • ServerHelloDone : la fin de l'envoi de message
    • ClientKeyExchange : ce message contient le PreMastersecret crypté à l'aide PreMastersecret crypté à l'aide de la clé publique du serveur.
    • CertificateVerify : vérification explicite du certificat du client
    • Finished : fin du protocole Handshake et le début de l'émission des données



    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 Record la mise en place des algorithmes de chiffrement qui viennent d'être négociés.


    Le Protocole SSLRecord


    Ce protocole intervient après l'émission du message ChangeCipherSpec.il permet de garantir :
    - la confidentialité à l'aide de chiffrement des données
    - l'intégrité à l'aide de génération d'un condensât.


    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 SSL est abandonnée. Le deuxième octet est utilisé pour le code d'erreur.

    Liste des Messages du protocol Alert:
    Les erreurs fatales sont:
    • bad_record_mac: réception d'un MAC 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.
    Les warnings sont :
    • 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: la fin d'une connexion
    • no_certificate: réponse négative à une demande de certificat
    • unsupported_certificate: le certificat reçu n'est pas reconnu



    Les ports utilisées par SSL


    HTTPS (HTTP en SSL) 443
    SMTPS (SMTP en SSL) 465
    NNTPS 563
    LDAPS (LDAP en SSL) 636
    POP3S 995
    IMAPS 995
    TELNETS 992

    En pratique, pour accéder à un serveur qui utilise les services SSL, on ajoute un "s" lors de la spécification du protocole.
    Exemple : https://www.monserveur.com


    Implémentations


    Plusieurs offres commerciales du serveur SSL sont disponibles, par exemple:
    • SSLeay
    • Netscape Entreprise Server
    • Apache
    • Oracle Web Apllication Server
    • Internet Information Server (IIS)
    • Lotus Domino d'IBM
    • Java Server de Sun Microsystems



    Aspects cryptographiques de SSL:

    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 : 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 (voir le paragraphe Pourquoi SSL?)
    • Z désigne l'algorithme de hachage (voir le paragraphe Pourquoi SSL?)
    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); ici, SSL définit sa propre fonction pour MACer, mais nous n'entrerons pas dans les détails. Attention, les illustrations font abstraction des headers, qui ne sont pas inclus dans les données protégées.




    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):

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

    Quant au chiffrement par blocs, il est nécessaire de rajouter du 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).




    Evolutions du standard :

    La prochaine version du standard aura quelques changements, parmi lesquels on retrouve :
    • Support obligatoire de DSA et D-H; RSA devrait également être supporté en facultatif.
    • Remplacement de la fonction prorpiétaire de génération de MACs par le standard HMAC (RFC 2104)
    • Protection du numéro de version de SSL par les opérations de hachage (pour éviter les attaques par rollback par exemple)
    • Nouveau générateur de nombres aléatoires (basé MD5 et SHA-1 à la fois), nouveaux messages d'alerte ("Decryption failed")
    • ...



    Les attaques et faiblesses de SSL


    • 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.
    • 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é.
    • SSL est faible dans le sens où il n'impose pas l'authentification client (ce serait d'ailleurs difficilement gérable en pratique).
    • SSL est faible enfin car il présente des souplesses dans son implémentation, notamment en ce qui concerne la vérification des certificats des serveurs. En effet, le client 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 traffic 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.
    • 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 votre 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 algos 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 fournit 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.



    Conclusion


    Le protocole SSL est actuellement le seul protocole de sécurisation déployé et utilisé à grande échelle, son grand avantage étant sa transparence par rapport au protocole TCP. Il garantit l'authentification, la confidentialité et l'intégrité des données.
    Avec son architecture modulaire, il ne se limite pas à des applications traditionnelles, puisque il intègre les réseaux sans fil comme le WAP (Wirless Transport Layer) sous le nom WTLS ( Wireless Transport Layer Security).


    Références


    - www.netscape.com/eng/ssl3



Publié dans l'informatique

Pour être informé des derniers articles, inscrivez vous :

Commenter cet article