> Tech > Le protocole SSL

Le protocole SSL

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Le protocole SSL assure une connexion socket de bout en bout cryptée sûre. Sa place est entre la couche application et la couche transport. iSeries System SSL réside dans le kernel du système d’exploitation, où il apporte une surcroît de sécurité et de performances. Toutes les applications validées SSL sur

l’iSeries n’utilisent pas System SSL. La connexion socket sûre assure l’authentification du pair, la confidentialité des données et leur intégrité. Le protocole SSL est un protocole ouvert, non propriétaire, largement utilisé depuis plus d’une décennie. La première utilisation généralisée est venue avec SSL version 2.0 (SSLv2), bientôt suivie par SSL version 3.0 (SSLv3). L’IETF (Internet Engineering Task Force) a utilisé SSLv3 comme base pour créer TLSv1 (Transport Layer Security) en 1999 via la RFC (Request For Comments) 2246. TLSv1 a amélioré SSLv3 et en a fait un vrai standard Internet. L’industrie utilise le terme SSL comme concept pour englober ces trois protocoles. La plupart des gens ne considèrent plus le SSL comme sûr et je déconseille son utilisation Quand j’entre dans le détail des protocoles, cela ne vaut que pour TLSv1 et SSLv3. A un niveau plus abstrait, le protocole SSL présente un avantage important par rapport au cryptage. Le plus important est l’interopérabilité, qui permet de développer indépendamment des applications qui échangent des paramètres cryptographiques. Cela permet à des applications ILE C, ILER RPG ou Java de communiquer correctement entre elles au moyen de SSL. Le langage de coding de l’application et la plate-forme sur laquelle il s’exécute sont sans importance quand à la fois le client et le serveur utilisent le protocole SSL. Les opérations cryptographiques sollicitent beaucoup la CPU et donc le protocole procure une efficacité relative en combinant des algorithmes pour produire des résultats sûrs, avec un minimum de calculs. Le protocole pratique aussi la mise en cache de sessions, qui permet de contourner certaines opérations crypt o g r a p h i q u e s s u r l e s connexions sûres suivantes avec le même pair.

En y regardant de plus près, on voit bien que SSL regroupe vraiment deux protocoles en un : un protocole couche d’enregistrement au niveau le plus haut avec un protocole handshake imbriqué dans celui-ci. SSL est presque toujours construit audessus de TCP et fonctionne avec les réseaux IPv4 ou IPv6. Les applications validées SSL écoutent généralement sur un port autre que celui de leur semblable non sécurisé. Par exemple, HTTP sur SSL utilise le port 443 plutôt que le port 80 habituel. Cela vous permet d’utiliser le cryptage SSL exigeant en calculs, uniquement sur les parties de votre site Web qui demandent cette protection. SSL utilise une suite de chiffrement pour déterminer les diverses propriétés cryptographiques à utiliser dans une session sûre donnée. La figure 1 explique les éléments qui constituent un nom de suite de chiffrement dans le contexte d’une valeur constante C. Une suite de chiffrement peut aussi être une chaîne de caractères avec des espaces, un nombre hexadécimal simple tel que 0x2F, ou une représentation caractère d’un nombre hexadécimal tel que 2F. La combinaison des propriétés et des algorithmes dans la suite de chiffrement aboutit à ce que les deux côtés suivent les mêmes étapes dans le même ordre pour que le passage de témoin soit réussi.

L’iSeries accepte plusieurs suites de chiffrement basées sur des certificats en V5R3, comme le montre la liste de la figure 2. La liste de chiffrement par défaut du système est un concept qui fournit aux applications une liste de chiffres dans un ordre préféré qui peut être utilisée sans coder les chiffres spécifiquement. Le contenu ou l’ordre de la liste peut changer aux limites des releases. Une application codée pour utiliser la liste par défaut sera dynamique dans le temps et pourra donc suivre les progrès réalisés dans les suites de chiffrement sans coût supplémentaire pour l’application.

Quand les suites de chiffrement symétriques AES ont été ajoutées à la liste par défaut en V5R3, les applications existantes utilisant la liste ont commencé automatiquement à supporter les connexions sûres qui utilisaient AES. Mais les chiffrements AES n’étaient pas placés à l’avant dans la liste, donc dans la plupart des cas, le même chiffrement RC4 à l’avant de la liste serait encore celui qui serait négocié. Les interfaces de programmation peuvent spécifier la liste par défaut, un sous-ensemble de cette liste, ou juste un chiffrement spécifique.

Le terme handshake signifie négocier les propriétés de sécurité pour la connexion en utilisant le protocole handshake. (Pour une explication détaillée de ce protocole, voir le TLS RFC 2246.) Il n’est pas nécessaire de connaître les handshakes dans le détail, mais une connaissance élémentaire du processus vous aidera à résoudre les problèmes de connectivité SSL. L’information suivante sur le protocole handshake ne prétend pas être exhaustive, mais c’est plutôt un moyen de renforcer l’information cryptographique déjà évoquée.

Une connexion sûre commence par une connexion socket TCP. Le client envoie un hello client au serveur contenant une liste des versions de protocoles et des suites de chiffrement que le client supportera, en même temps que d’autres informations. Le serveur répond par un hello serveur qui contient la version de protocole et la suite de chiffrement qui seront négociées. La version de protocole commun la plus haute acceptée par les deux côtés est retenue. Pour un serveur iSeries, la première suite de chiffrement dans la liste ordonnée du serveur qui est aussi dans la liste supportée du client, est utilisée. Le serveur envoie son certificat, lequel contient sa clé publique, au client. Si le serveur est configuré de manière à appliquer l’authentification client, une demande de certificat client est envoyée au client. Par souci de simplicité, supposons qu’aucune authentification client n’est configurée. Le client valide le certificat du serveur. La validation consiste à décrypter la signature numérique du certificat serveur à l’aide de la clé publique de la CA signataire. Le total de contrôle de la signature est comparé à un hash courant du certificat pour garantir que le certificat est intact. Le client doit avoir approuvé le signataire du certificat pour être parvenu à ce stade de la validation.

A présent, le client génère un secret prémaître, crypté à l’aide de la clé publique obtenue auprès du certificat serveur. Le secret prémaître crypté est placé dans un enregistrement d’échange de clé client et envoyé au serveur. Le serveur décrypte le secret prémaître en utilisant sa clé privée. A ce stade, les deux côtés ont maintenant le même secret prémaître, qu’ils utilisent pour générer un secret maître. Des données aléatoires ont été incluses dans les hello client et serveur et sont utilisées comme une partie de la semence pour générer le secret maître. Le secret maître est divisé en plusieurs parties pour fournir les diverses informations de secret partagé requises pour la connexion sûre.

Les deux côtés doivent maintenant indiquer à l’autre qu’il faut commencer à utiliser les clés symétriques qu’ils ont générées. Cela se fait par un enregistrement change cipher spec. Il indique que l’enregistrement suivant envoyé sera crypté avec les nouvelles clés. Le message fini est l’enregistrement suivant envoyé. Il contient un hash ou digest de tous les messages handshake qui ont été envoyés par les deux côtés avant l’enregistrement change cipher spec. Ce digest est crypté avec la nouvelle clé symétrique. Les deux côtés décryptent ensuite le message fini de leur pair et comparent le hash calculé au hash reçu. S’il y a correspondance, c’est que le handshake a fonctionné et l’application peut donc commencer à envoyer et à recevoir des données en toute sécurité en utilisant la même clé symétrique que celle qui a été utilisée pour le message fini. S’il y a discordance, c’est que le handshake a échoué et l’on peut supposer qu’une attaque d’intrus intermédiaire s’est produite – c’est-à-dire qu’un message a été altéré en route.

Après avoir vu comment et pourquoi SSL est sûr, entrons dans des détails propres à l’iSeries.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010