L'établissement de la communication SSL , ou " Handshake " se
fait au moyen des mécanismes d'authentification cités plus haut. Le serveur
et le client négocient auparavant l'algorithme de cryptage et choisissent l'algorithme
le plus puissant qu'ils aient en commun.
Authentification du serveur. L'authentification du serveur est systématique
et fonctionne
Le protocole SSL
comme cité précédemment, avec de légères variantes selon les algorithmes
utilisés.
Authentification du client. L’authentification du client est optionnelle
mais peut-être exigée par le serveur dans les cas sensibles (opérations boursières,…)
et fonctionne comme cité précédemment, avec de légères variantes selon les algorithmes
utilisés.
Connexion SSL cryptée. Juste après l’authentification le serveur peut,
s’il est interfacé avec un serveur LDAP (Lightweight Directory Access Protocol,
servant précisément à authentifier et valider les accès clients sur un serveur)
vérifier les droits d’accès du client. Ceci peut-être complémentaire à une authentification
client en mode digest, ou la remplacer. Vient ensuite l’échange de clé secrète
(générée par le client) et la communication s’établit.
Développement d’applications SSL 2.0, 3.0 et TLS 1.0. SSL 3.0 date de
mars 1996 et est un sur-ensemble de SSL 2.0. Certains algorithmes ont évolués,
de nouveaux sont apparus, et les mécanismes d’authentification sont devenus
encore plus rigoureux (notamment le protocole MD5 qui, sans changer de nom,
à fortement évolué en SSL 3.0 afin de corriger certaines failles dans l’algorithme
de hash). Mais fondamentalement, il n’y a pas eu de remise en cause profonde
entre SSL 2.0 et 3.0, à la différence de ce qui s’est passé avec TLS. TLS 1.0,
qui est amené à remplacer SSL à court ou moyen terme, est basé sur SSL 3.0 mais
apporte des changements sérieux dans les protocoles de communication, et ajoute
de nouveaux algorithmes de cryptage. Faut-il connaître ces différents protocoles
et les subtilités entre SSL 2.0, SSL 3.0 et TLS 1.0 pour pouvoir développer
une application les supportant tous ? Heureusement non. il faut simplement comprendre
les principes utilisés dans les algorithmes de cryptage. Ces différences n’ont
aucune conséquences sur les développements : les APIs de communication sécurisée
disponibles aussi bien en C qu’en Java, supportent indifféremment SSL 2.0, 3.0
et TLS 1.0 sans que le développeur n’ai besoin de préciser le protocole à employer
: la sélection du protocole et l’utilisation des algorithmes de cryptage est
interne et cachée par l’API.
Téléchargez cette ressource
Guide de Threat Intelligence contextuelle
Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Pourquoi les outils de sécurité ne suffisent plus face aux angles morts de la détection
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- L’analytique prédictive au service de la décarbonation en France
- Ofelia, ex-Bonitasoft, lance une solution d’orchestration IA agentique
Articles les + lus
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
À la une de la chaîne Tech
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
- Rhea1 : SiPearl allume le CPU européen le plus ambitieux pour le HPC et l’IA souveraine
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
