Introduction à SSL

mieux protéger une application internet

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
La dernière fois j'ai annoncé la sortie des articles consacrés à SQL injection. Cependant, à l’occasion de l'une de mes dernières missions je me suis aperçu de ne jamais avoir abordé les sujets liés au protocole SSL. Alors, voici le premier article lié à cet autre moyen de sécuriser les applications web.

Dans la première partie d'article on va revenir un peu en arrière. Cela nous servira à comprendre l'influence de ce protocole sur le monde du web. Ensuite on se chargera des notions plus techniques. Cette partie va contenir l'explication de la communication sécurisée entre un serveur et un client.

Une invention de Netscape
SSL est un des moyens de sécurisation des applications web. Le protocole a été développé en 1994 par Netscape en tant qu'une façon supplémentaire de protéger les échanges sur la Toile. Les premiers problèmes ont vu le jour un an plus tard, avec l'article d'Adam Shostack. L'auteur du "The New School of Information Security" a découvert que le protocole ne protège pas la transmission de données dans la situation où la sécurité du serveur est compromise. Cependant, le temps a amené les améliorations de la technique. La version 2.0 du protocole encryptait les données sur 40 bytes. La version suivante, sortie en 1996, encryptait déjà sur 128 bytes. Elle contenait également les corrections pour les vulnérabilités détectées au cours des 2 années précédentes.

Le schéma de l'échange avec le protocole de négociation
Le protocole de négociation, appelé Handshake, sert à établir les clés et des protocoles de chiffrement communs pour les acteurs de l'échange. Sa finalité est la clé secrète utilisée ensuite pour chiffrer et déchiffrer les données transmises.


SERVEUR CLIENT
Le client envoie une requête qui contient :
- la version du protocole
- les informations sur les méthodes de cryptage supportées
- le chiffre aléatoire utilisé pour la génération des clés symétriques
- l'identifiant de la sesssion si elle existe; sinon 0 à sa place
Le serveur répond. Sa réponse contient:
- la version du protocole
- les informations sur l'algorithme de compression
- la clé publique et le certificat X.509
- le chiffre aléatoire utilisé ensuite pour génération des clés symétriques
- si le serveur a reçu un identifiant de la session, il retourne une partie des données; sinon, la réponse contient toutes les données sur la nouvelle session initiée par le serveur

C'est alors que les deux parties trouvent le protocole de chiffrement le plus puissant connue par elles.
La validation de la viabilité du certificat (confiance, intégralité, date d'expiration, conformité avec le nom de domaine).
Si la validation réussit, le client génère la clé appelée "pre-master key" (pré clé principale). Elle est encryptée avec la clé publique reçue de la part du serveur.
Le client renvoie la clé générée chiffrée. Il informe aussi le serveur que leur échange va désormais contenir les données cryptées.
La vérification et la décryption de la clé avec la clé privée du serveur. Si elle réussit, il informe qu'à partir de maintenant il va envoyer uniquement les données cryptées.


Une fois toutes ces étapes terminées, on passe au protocole de communication (SSL record protocole). L'échange est alors basée sur la validation et le découpage.

L'expéditeur crée plusieurs paquets de données compressées. Ensuite il les signe cryptographiquement et chiffre avant d'envoyer.

Le récepteur doit alors déchiffrer les données et vérifier leur signature. Si tout est correct, il décompresse les données et regroupe les paquets afin de lire le message.

Cryptage symétrique et asymétrique
Les données sont échangées selon un chiffrement symétrique. Par contre, la transmission de la clé se déroule avec un chiffrement asymétrique. Qu'est-ce que cela signifie ?

Echange des données d'après un chiffrement symétrique se caractérise par l'utilisation d'une clé partagée par deux parties. Cette clé sert aussi bien à chiffrer qu'à déchiffrer les données. Dans SSL cet élément secret est la finalité du protocole de négociation.

La transmission de cette clé se déroule avec un chiffrement asymétrique. Ce type de chiffrement emploie les notions de clé publique et de clé privée. Cela veut dire que l'émetteur émet une clé publique à son récepteur qui possède sa clé privée. Le destinataire de l'échange chiffre alors sa clé avec la clé publique et renvoie le résultat.

Dans les parties suivantes on va aborder les sujets des certificats et des problèmes "du terrain" liés au protocole SSL.



L'article écrit en rythme de:
Rahil Kayden - Kizomba
Bartosz KONIECZNY 18-09-2011 18:39 sécurité des applications web
Un conseil MySQL

Comment sommer les champs du type TIME ?

La requête suivante devrait être utile :
SELECT SEC_TO_TIME(SUM(TIME_TO_SEC(maColonne))) AS somme FROM nomTableau;