Technologie SSL/TLS

Table des matières

Présentation
Transport Layer Security (TLS), anciennement nommé Secure Sockets Layer
(SSL), est un protocole de sécurisation des échanges sur Internet, développé à
l'origine par Netscape (SSL version 2 et SSL version 3). Il a été renommé en
Transport Layer Security (TLS) par l'IETF suite au rachat du brevet de Netscape par
l'IETF en 2001. Le groupe de travail correspondant à l'IETF a permis la création des
RFC 2246 pour le TLS et RFC 4347 pour son équivalent en mode datagramme, le
DTLS. Depuis son rapatriement par l'IETF, le protocole TLS a vécu deux révisions
subséquentes : TLSv1.1 décrite dans la RFC 4346 et publiée en 2006 et TLSv1.2,
décrite par la RFC 5246 et publiée en 2008.

Il y a très peu de différences entre SSL version 3 et TLS version 1 (qui correspond à
la version 3.1 du protocole SSL) rendant les deux protocoles non interopérables,
mais TLS a mis en place un mécanisme de compatibilité ascendante avec SSL. En
outre, 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 des
faiblesses en cryptanalyse.

Par abus de langage, on parle de SSL pour désigner indifféremment SSL ou TLS.

TLS fonctionne suivant un mode client-serveur. Il fournit les objectifs de sécurité

suivants :

• l'authentification du serveur
• la confidentialité des données échangées (ou session chiffrée)
• l'intégrité des données échangées
• de manière optionnelle, l'authentification ou l'authentification forte du client
avec l'utilisation d'un certificat numérique
• la spontanéité, c.-à-d. qu'un client peut se connecter de façon transparente à
un serveur auquel il se connecte pour la première fois
• la transparence, qui a contribué certainement à sa popularité. Du fait que les
protocoles de la couche d'application n'aient pas à être modifiés pour utiliser
une connexion sécurisée par TLS. Par exemple, le protocole HTTP est
identique, que l'on se connecte à un schème http ou https.

SSL Simple ou Double authentification

Dans la majorité des cas, l'utilisateur authentifie le serveur TLS sur lequel il se
connecte. Cette authentification est réalisée par l'utilisation d'un certificat numérique
X.509 délivré par une autorité de certification (AC). Mais de plus en plus
d'applications web utilisent maintenant l'authentification du poste client en exploitant
TLS. Il est alors possible d'offrir une authentification mutuelle entre le client et le
serveur. Le certificat client peut être stocké au format logiciel sur le poste client ou au
format matériel (carte à puce, token USB) pour augmenter la sécurité du lien TLS.
Cette solution permet d'offrir des mécanismes d'authentification forte.

Texte de Référence
• Transport Layer Security version française simplifié
• Transport Layer Security version anglaise plus complète
• Certificat numérique
• Certificat SSL Howto
• Les certificats
• X.509 : La norme régissant les certificats (version française simplifié)
• X.509 (version anglaise plus complète)

Principe de fonctionnement
Pour faire simple, le protocole SSL (et maintenant TLS) repose essentiellement sur 2
mécanismes :

• un cryptage asymétrique : un couple de clef publique/clef privée

• un(des) certificat(s) de sécurité permettant d'associer une identité à la clef
publique.

Le couple clef publique/clef privée permet de crypter/décrypter un message (ou

inversement). Le serveur conservant sa clef privée, et publiant sa clef publique à
toutes parties voulant dialoguer avec lui.

La validité du certificat de sécurité est assuré par d'autres certificat de sécurité(ou

autorité de certification) que sont jugés sure, et qui sont installés sur le système.
C'est ce mécanisme que nous appelons une chaine de certification.

• Par défaut, les certificats des principales autorités de certification (Verisign,

Keynectis, etc...) sont installés sur les navigateurs.
• Tout les postes BNP contiennent un certificat BNP faisant office d'autorité de
certification sur toutes les applications de type intranet, certificat installé sur le
navigateur d'entreprise (Internet Explorer).
• Dans la JVM de Sun, le keystore ${JAVA_HOME}/jre/lib/security/cacerts
(password : 'changeit') contient les principales autorités de certification.

Dans le détail, l'emploi de SSL repose sur les processus suivants :

• L'identification est portée par le certificat de sécurité lui même.

o Introduction
o Structure
• L'authentification se fait lors de la validation des certificats de sécurité dans la
phase TLS Handshake.
o Handshake TLS
 Simple authentification
 Double authentification
 o Validation du certificat
• l'Habilitation, ou comment donner le droit à un client d'utiliser un service
• La révocation des certificats
• Le renouvellement des certificats

Habilitation

D'un point de vue serveur, la double authentification SSL v3 permet d'identifier et

d'authentifier les clients d'un service. Maintenant il faut trouver le moyen de
sélectionner les clients qui ont le droit d'utiliser un service (principe d'habilitation).

SSL nous donne comme moyen la hiérarchie des certificats. Les certificats clients
sont tous issue d'un certificat de niveau intermédiaire, permettant de filtrer par
rapport à ce certificat.

Mise en œuvre chez P.F. 2009

Dans notre infrastructure classique, le SSL est décrypter par les load-balancer F5,
puis nous sommes en HTTP des RPF jusqu'aux WebLogic. Si nous avons besoin
d'information en provenance des certificats clients utilisés, les load-balancer sont
capable de rajouter dans un header HTTP l'information dont nous avons besoin.
 Le problème de l'habilitation telle que possible via SSLv3 réside dans sa
complexité de gestion sur le long terme, et le fait que ce ne soit pas très souple
(habilitation de l'ensemble des certificats issue de la chaine de certificat du serveur,
et pas seulement le certificat de niveau intermédiaire).

Une solution est actuellement à l'étude chez ITPS/BP2I pour

• soit faire
l'habilitation a
d'un RPF blac
• soit au nivea
applicatif
• par liste blan
certificats clie
le load-balanc
complexifiant
phase de
renouvelleme

Pour le moment, nous ne disposons pas de CRL, solution à l'étude chez

ITPS/BP2I.

Gestion des certificats

Un certificat numérique n'est valable que par rapport à une autorité de certification.
L'autorité de certification peut-être privée ou publique. Les critères de choix sont
nombreux, mais il ne faut pas oublier que les clients doivent toujours avoir un accès
HTTP vers l'autorité de certification pour récupérer la liste des certificats révoqués.
Raison pour laquelle il est déconseillé d'installer en intranet des certificats d'une
autorité de certification publique, vu que par défaut en intranet nous n'avons pas
accès à internet.

1. Processus de génération d'un certificat SSL : basé sur RefWeb ?

2. Processus de renouvellement de certificat
1. Simple Authentification
1. Certificat Serveur
2. Autorité de certification
2. Double Authentification
1. Certificat Client
2. Certificat Serveur
3. Autorité de certification

Certificats Wildcard (omnidomaine en français)

Technologie inutilisée a priori chez BNPP à ce jour (4/2010).

cf info TBS : prix, compatibilité navigateurs, faq

Resource externe

• Oracle : Mutual Authentication

last update