SSL & TLS Essentials Partie 1 - Partie1

3
SSL and TLS

Essentials
Securing the Web
SSL &TLSEssentials
Securing the Web
Contents
Chapter 1: Introduction 1
1.1 Web Security and Electronic Commerce 2

1.2 History of ssl and t l s 4
1.3 Approaches to Network Security 6
1.3.1 Separate Security Protocol 8
1.3.2 Application-Specific Security 9
1.3.3 Security within Core Protocols 10
1.3.4 Parallel Security Protocol 11
1.4 Protocol Limitations 12
1.4.1 Fundamental Protocol Limitations 12
1.4.2 Tool Limitations 13
1.4.3 Environmental Limitations 14
1.5 Organization of This Book 14
Chapter 2:BasicCryptography 17
2.1 Using Cryptography 18

2.1.1 Keeping Secrets 18
2.1.2 Proving Identity 19
2.1.3 Verifying Information 20
2.2 Types of Cryptography 21
2.2.1 Secret Key Cryptography 22
2.2.2 Public Key Cryptography 24
2.2.3 Combining Secret & Public Key Cryptography 27
2.3 Key Management 29
2.3.1 Public Key Certificates 29
2.3.2 Certificate Authorities 31
2.3.3 Certificate Hierarchies 33
2.3.4 Certificate Revocation Lists 35
ix
x SSL & TLSEssentials:Securing the Web
Chapter 3:SSL Operation 37
3.1 SSL Roles 37

3.2 SSL Messages 38
3.3 Establishing Encrypted Communications 39
3.3.1 ClientHello 41
3.3.2 ServerHello 43
3.3.3 ServerKeyExchange 45
3.3.4 ServerHelloDone 45
3.3.5 ClientKeyExchange 45
3.3.6 ChangeCipherSpec 46
3.3.7 Finished 51
3.4 Ending Secure Communications 52
3.5 Authenticating the Server’s Identity 52
3.5.1 Certificate 55
3.6 Separating Encryption from Authentication 56
3.7 Authenticating the Client’s Identity 60
3.7.1 CertificateRequest 61
3.7.3 CertificateVerify 63
3.8 Resuming a Previous Session 64
Chapter 4:Message Formats 67
4.1 Transport Requirements 68

4.2 Record Layer 69
4.3 ChangeCipherSpec Protocol 71
4.4 Alert Protocol 72
4.4.1 Severity Level 72
4.4.2 Alert Description 73
4.5 Handshake Protocol 74
4.5.1 HelloRequest 76
4.5.2 ClientHello 77
Contents xi
4.5.3 ServerHello 79
4.5.6 CertificateRequest 84
4.5.7 ServerHelloDone 85
4.5.10 Finished 90
4.6 Securing Messages 92
4.6.1 Message Authentication Code 93
4.6.2 Encryption 95
4.6.3 Creating Cryptographic Parameters 96
4.7 Cipher Suites 102
4.7.1 Key Exchange Algorithms 103
4.7.2 Encryption Algorithms 104
4.7.3 Hash Algorithms 104
Chapter 5:Advanced SSL 105
5.1 Compatibility with Previous Versions 105

5.1.1 Negotiating ssl Versions 106
5.1.2 SSL Version 2.0 ClientHello 109
5.1.3 SSL Version 2.0 Cipher Suites 110
5.2 Netscape International Step-Up 111
5.2.1 Server Components 112
5.2.2 Client Components 112
5.2.3 Controlling Full-Strength Encryption 113
5.3 Microsoft Server Gated Cryptography 115
5.3.1 Server Gated Cryptography Certificates 115
5.3.2 Cipher Suite Renegotiation 115
5.4 The Transport Layer Security Protocol 117
5.4.1 TLS Protocol Version 118
5.4.2 Alert Protocol Message Types 118
5.4.3 Message Authentication 121
5.4.4 Key Material Generation 123
5.4.6 Finished 126
xii SSL & TLSEssentials:Securing the Web
5.4.7 Baseline Cipher Suites 126

5.4.8 Interoperability with SSL 128
5.5 The Future of ssl and t l s 128
Appendix A:X.509 Certificates 131
A.1 X.509 Certificate Overview 132

A.1.1 Version 132
A.1.2 Serial Number 133
A.1.3 Algorithm Identifier 133
A.1.4 Issuer 133
A.1.5 Period of Validity 133
A.1.6 Subject 134
A.1.7 Subject’s Public Key 134
A.1.8 Issuer Unique Identifier 134
A.1.9 Subject Unique Identifier 134
A.1.10 Extensions 135
A.1.11 Signature 135
A.2 Abstract Syntax Notation One 135
A.2.1 Primitive Objects 136
A.2.2 Constructed Objects 136
A.2.3 The Object Identifier Hierarchy 137
A.2.4 Tagging 139
A.2.5 Encoding Rules 142
A.3 X.509 Certificate Definition 145
A.3.1 The Certificate Object 145
A.3.2 The Version Object 146
A.3.3 The CertificateSerialNumber Object 147
A.3.4 The AlgorithmIdentifier Object 147
A.3.5 The Validity Object 148
A.3.6 The SubjectPublicKeyInfo Object 148
A.3.7 The Time Object 149
A.3.8 The Extensions Object 149
A.3.9 The UniqueIdentifier Object 150
A.3.10 The Name Object 150
A.4 Example Certificate 152
Contents Appendix B:SSLSecurity Checklist xiii
161
B.1 Authentication Issues 161

B.1.1 Certificate Authority 162
B.1.2 Certificate Signature 163
B.1.3 Certificate Validity Times 163
B.1.4 Certificate Revocation Status 163
B.1.5 Certificate Subject 163
B.1.6 Diffie- Hellman Trapdoors 164
B.1.7 Algorithm Rollback 164
B.1.8 Dropped ChangeCipherSpec Messages 165
B.2 Encryption Issues 166
B.2.1 Encryption Key Size 166
B.2.2 Traffic Analysis 167
B.2.3 The Bleichenbacher Attack 168
B.3 General Issues 170
B.3.1 RSA Key Size 170
B.3.2 Version Rollback Attacks 171
B.3.3 Premature Closure 171
B.3.4 SessionID Values 172
B.3.5 Random Number Generation 172
B.3.6 Random Number Seeding 173
References 175
Protocol Standards 175

Certificate Formats 176
Cryptographic Algorithms 177
SSL Implementations 178
Glossary 179
Index 191
xiv SSL & TLSEssentials:Securing the Web
1
Introduction
Rien qu’aujourd’hui, Dell Computer vendra pour plus de 18 millions

de dollars d’équipements informatiques via Internet. En 1999, neuf
millions d’Américains ont échangé des actions en ligne, ce qui
représente un tiers de toutes les transactions boursières de détail. Et
plus de 200 000 sites Web dans le monde (y compris des sites
appartenant à 98 des entreprises du Fortune 100) peuvent accepter
des transactions de commerce électronique. L’utilisation
commerciale du Web continue de croître à un rythme soutenu, et la
sécurisation des transactions Web est devenue de plus en plus
essentielle pour les entreprises, les organisations et les utilisateurs
individuels. Heureusement, un protocole de communication
extrêmement efficace et largement déployé offre exactement cette
sécurité. Il s’agit du protocole Secure Sockets Layer, plus
communément appelé ssl. Le protocole ssl ainsi que son successeur,
le protocole Transport Layer Security (t l s), est le sujet de ce livre.
Ce chapitre présente ssl et t l s, et fournit le contexte essentiel pour
les deux. Il commence par un très bref aperçu de la sécurité Web et
du commerce électronique, en se concentrant sur les problèmes qui
ont conduit à la création de SSL. La section suivante suit avec un
historique rapide de ssl et de sa transformation en t l s. La relation
entre le SSL et les autres technologies de sécurité des réseaux
faitl’objet de la troisième section. La quatrième section, «
Limitations du protocole », est importante. Surtout avec les
technologies de sécurité, il est essentiel de comprendre ce qu’elles ne
peuvent pas faire. Le chapitre se termine par un aperçu du reste de ce
livre.
–
1
2 SSL & TLS Essentials : Securing the web
1.1 Web Security and ElectronicCommerce
Connaissez l’ennemi. Sun Tzu n’aurait pas pu offrir de conseils plus

appropriés aux professionnels de la sécurité. Les services de sécurité
spécifiques ne sont nécessairement efficaces que contre des menaces
spécifiques ; Ils peuvent être complètement inappropriés pour
d’autres menaces de sécurité. Pour comprendre le SSL, il est donc
essentiel de comprendre l’environnement pour lequel il a été conçu.
Même si ssl est un protocole flexible qui trouve une utilisation dans
de nombreuses applications différentes, la motivation initiale de son
développement était Internet. Les concepteurs du protocole devaient
sécuriser le commerce électronique et d’autres transactions Web. Cet
environnement est certainement assez périlleux. Prenons, par
exemple, ce qui se passe lorsqu’un utilisateur à Berlin passe une
commande en ligne à partir d’un site Web à San Jose, en Californie.
Le tableau 1-1 répertorie les systèmes par lesquels les messages de
l’utilisateur peuvent passer.
Table 1-1 Internet Systems in Path from Berlin to San Jose
Step IPAddress System Name (if known)
1 212.211.70.7
2 212.211.70.254
3 195.232.91.66 fra-ppp2-fas1-0-0.wan.wcom.net
4 212.211.30.29
5 206.175.73.45 hil-border1-atm4-0-2.wan.wcom.net
6 205.156.223.41 dub-border1-hss2-0.wan.wcom.net
7 204.70.98.101 borderx1-hssi2-0.northroyalton.cw.net
8 204.70.98.49 core2-fddi-0.northroyalton.cw.net
9 204.70.9.138 corerouter1.westorange.cw.net
10 204.70.4.101 core5.westorange.cw.net
11 204.70.10.230 sprint4-nap.westorange.cw.net
12 192.157.69.85 sprint-nap.home.net
13 24.7.72.113 c1-pos9-1.cmdnnj1.home.net
14 24.7.67.153 c1-pos6-2.clevoh1.home.net
15 24.7.64.173 c1-pos3-0.chcgil1.home.net
16 24.7.64.141 c1-pos1-0.omahne1.home.net
Introduction 3
Step IPAddress System Name (if known)

17 24.7.66.173 c1-pos8-3.lnmtco1.home.net
18 24.7.64.57 c1-pos1-0.slkcut1.home.net
19 24.7.66.77 c1-pos5-3.snjsca1.home.net
20 24.7.72.18 bb1-pos6-0-0.rdc1.sfba.home.net
21 172.16.6.194
22 10.252.84.3
23 10.252.10.150
24 209.219.157.152 www.sj-downtown.com
La figure 1-1 met en évidence le fait que les messages contenant des
informations de l’utilisateur, y compris des informations sensibles
telles que les numéros de carte de crédit, peuvent parcourir un
chemin complexe de l’Allemagne à la Californie, traversant de
nombreux pays, sur divers réseaux et sur de nombreuses installations
différentes. Certaines de ces installations sont susceptibles
d’appartenir à des entreprises privées, dont beaucoup ne sont
soumises à aucune réglementation ou autre loi régissant la
confidentialité des informations qu’elles transportent.
Ni l’utilisateur ni le serveur Web n’ont de contrôle sur le chemin
d’accès de leurs messages, ni qui examine le contenu du message le
long de l’itinéraire. Du point de vue de la sécurité, c’est comme si
l’utilisateur écrivait son numéro de carte de crédit sur une carte
postale puis la livrait
Web Server Web Browser
Figure 1-1 Messages travel complex paths through the Internet.

comme message dans une bouteille. L’utilisateur n’a aucun contrôle

sur la façon dont le message atteint sa destination, et n’importe qui en
cours de route peut facilement lire son contenu. Le commerce
électronique ne peut prospérer dans un environnement aussi peu sûr ;
les informations sensibles doivent rester confidentielles lorsqu’elles
circulent sur Internet.
L’écoute clandestine n’est pas la seule menace de sécurité pour les
internautes. Il est théoriquement possible de détourner des messages
Web vers un site Web contrefait. Un tel site contrefait pourrait
fournir de faux renseignements, recueillir des données telles que des
numéros de carte de crédit en toute impunité ou créer d’autres
méfaits. Internet a besoin d’un moyen de garantir aux utilisateurs la
véritable identité d’un site Web ; de même, de nombreux sites Web
doivent vérifier l’identité de leurs utilisateurs.
Un dernier défi de sécurité auquel sont confrontés les utilisateurs
Web est l’intégrité des messages. Un utilisateur plaçant une
transaction boursière en ligne ne voudrait certainement pas que ses
instructions soient brouillées de manière à changer « Vendre lorsque
le prix atteint 200 $ » en « Vendre lorsque le prix atteint 20 $ ». Le
zéro manquant peut faire une différence significative dans la fortune
de l’utilisateur.
1.2 History of SSL and TLS History

Heureusement, les ingénieurs réfléchissaient à ces problèmes de
sécurité dès les débuts du Web. Netscape Communications a
commencé à considérer la sécurité Web lors du développement de
son tout premier navigateur Web. Pour répondre aux préoccupations
de la section précédente, Netscape a conçu le protocole Secure
Sockets Layer.
La figure 1-2 montre l’évolution de SSL dans le contexte du
développement Web général. La chronologie commence en
novembre 1993, avec la sortie de Mosaic 1.0 par le National Center
for Supercomputing Applications (ncsa). Mosaic a été le premier
navigateur Web populaire. Seulement huit mois plus tard, Netscape
Communications a terminé la conception de
Introduction 5
SSL 1.0
design complete
SSL 2.0
product ships
PCT 1.0
published
SSL 3.0
published
TLSWG TLS 1.0

formed published
1993 1994 1995 1996 1997 1998 1999
NCSA Internet
Mosaic Explorer
released released
Netscape
Navigator
released
Figure 1-2 SSL was developed along with early Web browsers.
SSL version 1.0; cinq mois plus tard, Netscape a livré le premier
produit prenant en charge SSL version 2.0 : Netscape Navigator.
D’autres jalons dans la chronologie comprennent la publication de la
version 1.0 de la spécification Private Communication Technology
(pct). Microsoft a développé pct comme une amélioration mineure de
la version 2.0 de SSL. Il a corrigé certaines des faiblesses de SSL
2.0, et beaucoup de ses idées ont ensuite été incorporées dans la
version 3.0 de SSL.
Les événements ultérieurs de la chronologie représentent un
changement d’orientation pour la norme SSL. Netscape
Communications a développé les trois premières versions de SSL
avec l’aide significative de la communauté Web. Bien que le
développement de SSL ait été ouvert et que Netscape ait encouragé
d’autres acteurs de l’industrie à participer, le protocole appartenait
techniquement à Netscape. (En effet, Netscape a obtenu un brevet
américain pour le SSL.) À partir de mai 1996, cependant, le
développement de SSL est devenu la responsabilité d’une
organisation internationale de normalisation, l’Internet Engineering
Task Force (ietf). L’ietf développe un grand nombre de normes et
protocole pour l’Internet, y compris, par exemple, tcp et ip.
Pour éviter l’apparence de partialité envers une entreprise en SSL vs.TLS

particulier, l’ietf a renommé ssl en Transport Layer Security (tls). La
Parce que SSL
version finale de la première spécification officielle a été publiée en est plus
janvier 1999. largement utilisé
et beaucoup
Malgré le changement de nom, t l s n’est rien de plus qu’une
plus connu que
nouvelle version de ssl. En fait, il y a beaucoup moins de différences TLS, le texte
entre t l s 1.0 et ssl 3.0 qu’entre ssl 3.0 et ssl 2.0. La section 5.4 principal de ce
détaille les différences entre SSL et t l s, mais consultez les barres livre décrit SSL
latérales pour plus d’informations. plutôt que TLS.
Les différences
La prise en charge de SSL est maintenant intégrée à presque tous les entre les deux
navigateurs et serveurs Web. Pour les utilisateurs de Netscape sont toutefois
Navigator ou d’Internet Explorer de Microsoft, SSL fonctionne de très mineures.
manière presque transparente. Les utilisateurs attentifs peuvent Des encadrés
remarquer le préfixe « https : » pour un SSL -sécurisé vous êtes url, comme celui-ci
ou ils peuvent voir une petite icône que chaque navigateur affiche noteront toutes
ces différences.
lorsque SSL est utilisé. (La figure 1-3 montre le symbole de cadenas
qu’Internet Explorer affiche dans la barre d’état inférieure ; Le
navigateur affiche une icône similaire.) Pour la plupart, cependant,
SSL fonctionne simplement, fournissant en toute sécurité la
confidentialité, l’authentification et l’intégrité des messages à ses
utilisateurs Web.
Les serveurs Web populaires d’aujourd’hui incluent également la
prise en charge de SSL. C’est généralement une tâche simple
d’activer SSL sur le serveur. Comme nous le verrons, cependant,
pour soutenir la navigation Web sécurisée, un serveur Web doit faire
plus que simplement activer le protocole ssl. Le serveur doit
également obtenir un certificat de clé publique auprès d’une
organisation approuvée par les navigateurs Web. Pour les utilisateurs
de l’Internet public, ces organisations sont généralement des autorités
publiques de certification. Les autorités de certification populaires
incluent un service de certification at&t, gte CyberTrust, KeyWitness
International, Microsoft, Thawte Consulting et VeriSign. Le chapitre
suivant comprend d’autres discussions sur les autorités de
certification (principalement à la section 2.3.2), et l’annexe a fourni
des détails sur les certificats de clé publique.
Introduction 7
1.3 Approaches to Network Security

Le protocole Secure Sockets Layer offre une sécurité efficace pour les transactions Web,
mais ce n’est pas la seule approche possible. L’architecture Inter-net repose sur des couches
de protocoles, chacun s’appuyant sur les services de ceux qui lui sont inférieurs. Bon nombre
de ces différentes couches de protocole peuvent
Figure 1-3 Web browsers such as Internet Explorer include SSL.

Soutenir les services de sécurité, bien que chacun ait ses propres
avantages et inconvénients. Comme nous le verrons dans cette
section, les concepteurs de SSL ont choisi de créer une couche de
protocole entièrement nouvelle pour la sécurité. Il est également
possible d’inclure des services de sécurité dans le protocole
d’application ou de les ajouter à un protocole réseau principal. Autre
alternative, les applications peuvent s’appuyer sur des protocoles
parallèles pour certains services de sécurité. Toutes ces options ont
été envisagées pour sécuriser les transactions Web, et des protocoles
actifs existent pour chaque alternative. Le tableau 1-2 résume les
avantages de chaque approche, et la présente section examine plus en
détail chacune des approches possibles.
Table 1-2 Different Approaches to Network Security

Protocol Architecture Example A B C D E
Separate Protocol Layer SSL ● ● ⃝ ⃝ ●
Application Layer S-HTTP ● ⃝ ● ⃝ ●
Integrated with Core IPSEC ● ● ⃝ ● ⃝
Parallel Protocol Kerberos ⃝ ● ⃝ ⃝ ●
Benefits: A – Sécurité complète B – Applications multiples C – Services sur
mesure D – Transparent pour l’application E – Facile à déployer
Introduction 9
1.3.1 Separate Security Protocol

Les concepteurs du Secure Sockets Layer ont décidé de créer un
protocole séparé juste pour la sécurité. En effet, ils ont ajouté une
couche à l’architecture de protocole d’Internet. Le côté gauche de la
figure 1-4 montre les principaux protocoles pour les communications
Web. En bas se trouve le protocole inter-net (ip). Ce protocole est
responsable du routage des messages sur les réseaux depuis leur
source jusqu’à leur destination. Le protocole de contrôle de
transmission (tcp) s’appuie sur les services d’ip pour garantir la
fiabilité de la communication. En haut se trouve le protocole de
transfert hypertexte ; h t t p comprend les détails de l’interaction
entre les navigateurs Web et les serveurs Web.
Comme l’indique le côté droit de la figure, ssl ajoute de la sécurité
en agissant comme un protocole de sécurité distinct, s’insérant entre
l’application h t p et t cp. En agissant comme un nouveau protocole,
ssl nécessite très peu de changements dans les protocoles ci-dessus et
ci-dessous. L’application h t t p intègre avec ssl presque de la même
manière qu’elle le ferait avec t cp en l’absence de sécurité. Et, en ce
qui concerne tcp, ssl n’est qu’une autre application utilisant ses
services.
En plus de nécessiter des modifications minimales aux
implémentations existantes, cette approche présente un autre
avantage important : elle permet à SSL de prendre en charge des
applications autres que h t t p. La principale motivation derrière le
développement de SSL était la sécurité Web, mais, comme le montre
la figure 1-5, SSL
Not Secure Secure
HTTP
HTTP SSL
TCP TCP
IP IP
Figure 1-4 SSL is aseparate protocol layer just for security.

HTTP NNTP FTP
SSL
TCP
IP
Figure 1-5 SSL can add security to applications other than HTTP.
est également utilisé pour renforcer la sécurité d’autres applications

Internet, y compris celles du Net News Transfer Protocol (nntp) et du
File Trans- fer Protocol (f t p).
1.3.2 Application-SpecificSecurity
Bien que les concepteurs de SSL aient choisi une stratégie différente,
il est également possible d’ajouter des services de sécurité
directement dans un protocole d’application. En effet, la norme
comprend certaines caractéristiques de sécurité extrêmement
rudimentaires ; Cependant, ces caractéristiques de sécurité n’offrent
pas une protection adéquate pour le commerce électronique réel. À
peu près au même moment où Netscape concevait ssl, un autre
groupe de concepteurs de protocoles travaillait sur une amélioration
de h t t p connue sous le nom de Secure h t t p. La figure 1-6 illustre
l’architecture de protocole résultante. La norme Secure http a été
publiée par l’ietf à titre expérimental
Not Secure Secure
HTTP HTTP
security
TCP TCP
IP IP
Figure 1-6 Security can be added directly within an application protocol.

Introduction 11
, et quelques produits le prennent en charge. Cependant, il n’a jamais

pris le même degré que le ssl, et il est rare aujourd’hui de trouver
Secure h t t p n’importe où sur Internet.
L’un des inconvénients de l’ajout de sécurité à une application

spécifique est que les services de sécurité ne sont disponibles que
pour cette application particulière. Contrairement à ssl, par exemple,
il n’est pas possible de sécuriser nntp, f t p ou d’autres protocoles
d’application avec Secure h t t p. Un autre inconvénient de cette
approche est qu’elle lie étroitement les services de sécurité à
l’application. Chaque fois que le protocole d’application change, les
implications en matière de sécurité doivent être soigneusement
examinées et, fréquemment, les fonctions de sécurité du protocole
doivent également être modifiées. Un protocole distinct comme SSL
isole les services de sécurité du protocole d’application, permettant à
chacun de se concentrer sur la résolution de ses propres problèmes le
plus efficacement possible.
1.3.3 Security within Core Protocols

L’approche de protocole séparé de SSL peut être poussée un peu plus
loin si les services de sécurité sont ajoutés directement à un protocole
réseau de base. C’est exactement l’approche de l’architecture de
sécurité IP (ipsec) ; Les services de sécurité complets deviennent une
partie facultative du protocole Internet lui-même. La figure 1-7
illustre l’architecture ipsec.
L’architecture ipsec présente bon nombre des mêmes avantages que
ssl. Il est indépendant du protocole d’application, de sorte que
n’importe quelle application peut l’utiliser. Dans la plupart des cas,
l’application n’a pas besoin de changer du tout pour
Not Secure Secure
HTTP HTTP
TCP TCP
IP IP with IPSec
Figure 1-7 IPSEC adds security to a core network protocol.

profiter d’IPSec. En fait, il peut même être complètement ignorant

que ipsec est impliqué. Cette fonctionnalité crée cependant ses
propres défis, car ipsec doit être suffisamment flexible pour prendre
en charge toutes les applications. Cette complexité peut être un
facteur important dans les retards dans le développement et le
déploiement d’ipsec.
Une autre préoccupation avec l’approche ipsec est qu’elle fournit
trop d’isolation entre l’application et les services de sécurité. Au
moins dans ses implémentations les plus simples, ipsec tend à
supposer que les exigences de sécurité sont fonction d’un système
particulier et que toutes les applications au sein de ce système
nécessitent les mêmes services de sécurité. L’approche SSL fournit
une isolation entre les applications et la sécurité, mais elle permet
une certaine interaction entre les deux. Le comportement interne
d’une application telle que h t t p n’a pas besoin de changer lorsque
la sécurité est ajoutée, mais l’application doit généralement prendre
la décision d’utiliser SSL ou non. Une telle interaction permet à
chaque application de diriger plus facilement les services de sécurité
les plus appropriés à ses besoins.
Malgré ces inconvénients, ipsec ajoute de nouveaux outils de sécurité
puissants à Internet, et il verra sans aucun doute un déploiement
généralisé. Le protocole SSL, cependant, présente également des
avantages significatifs, et son déploiement devrait également croître
considérablement à l’avenir.
1.3.4 Parallel Security Protocol

Il existe encore une quatrième approche pour ajouter des services de
sécurité à une application : un protocole de sécurité parallèle.
L’exemple le plus populaire de cette stratégie est le protocole
Kerberos développé par le Massachusetts Institute of Technology.
Les chercheurs ont développé Kerberos pour fournir une
authentification et un contrôle d’accès aux ressources dans un
environnement distribué. Le protocole Kerberos agit comme une
boîte à outils que d’autres protocoles peuvent utiliser pour ces
services de sécurité. Un protocole de connexion à distance tel que
Telnet, par exemple, peut utiliser Kerberos pour identifier son
utilisateur en toute sécurité.
Au tout début du développement des navigateurs Web, des efforts
ont été faits pour intégrer le support Kerberos dans h t tp. La figure
Introduction 13
1-8 montre l’architecture résultante. Ce travail n’a cependant jamais
été achevé. Au lieu de cela, il y a eu des efforts récents pour
combiner Kerberos avec t l s.
Not Secure Secure
HTTP HTTP Kerberos
TCP TCP and UDP
IP IP
Figure 1-8 Kerberos supplements application protocols.
Dans ces applications, Kerberos fournit un

mécanisme d’échange de clés approuvé pour
Transport Layer Security. Notez cependant que
Kerberos seul n’est pas une solution de sécurité
complète. Il n’a pas accès aux informations
effectivement échangées par les parties
communicantes. Sans cet accès, Kerberos ne
peut pas fournir de services de chiffrement et de
déchiffrement.
1.4 Protocol Limitations

Le protocole ssl, comme toute technologie, a ses limites. Et parce que SSL fournit des
services de sécurité, il est particulièrement important de dépasser ses limites. Après
tout, un faux sentiment de sécurité peut être pire que pas de sécurité. Les limites du
SSL se répartissent généralement en trois catégories. Tout d’abord, il y a les
contraintes fondamentales du protocole SSL lui-même. Ceux-ci sont une conséquence
de la conception de SSL et de son application prévue. Le protocole SSL hérite
également de certaines faiblesses des outils qu’il utilise, à savoir les algorithmes de
cryptage et de signature. Si ces algorithmes ont des faiblesses, ssl ne peut
généralement pas les réhabiliter. Enfin, les environnements dans lesquels le SSL est
déployé ont leurs propres lacunes et limites, dont certaines sont impuissantes à
corriger.
1.4.1 Fundamental Protocol Limitations

Bien que sa conception inclue des considérations pour de nombreuses applications
différentes, SSL est définitivement axé sur la sécurisation des transactions Web.
Certaines de ses caractéristiques reflètent cette concentration.
Par exemple, ssl nécessite un protocole de transport fiable tel que

tcp. C’est une exigence tout à fait raisonnable dans le monde des
transactions Web, car le protocole de transfert hypertexte lui-même
nécessite t cp. La décision signifie, cependant, que ssl ne peut pas
fonctionner à l’aide d’un protocole de transport sans connexion
comme udp. À cette exception près, les transactions Web sont
représentatives des environnements informatiques de réseau
généraux. Le protocole ssl peut donc très bien s’adapter efficacement
à la plupart des applications courantes. En effet, SSL est utilisé
aujourd’hui pour sécuriser diverses applications, y compris le
transfert de fichiers, la lecture de nouvelles réseau et la connexion à
distance. Un autre rôle que SSL ne remplit pas est la prise en charge
d’un service de sécurité particulier connu sous le nom de non-
répudiation. La non-répudiation associe l’équivalent numérique
d’une signature à des données et, lorsqu’elle est utilisée
correctement, elle empêche la partie qui crée et « signe » des données
de les nier avec succès après coup. Le protocole SSL ne fournit pas
de services de non-répudiation, donc ssl seul ne serait pas approprié
pour une application qui l’exige.
1.4.2 Tool Limitations

Le Secure Sockets Layer est simplement un protocole de
communication, et toute implémentation SSL s’appuiera sur d’autres
composants pour de nombreuses fonctions, y compris les algorithmes
cryptographiques. Ces algorithmes sont les outils mathématiques qui
effectuent réellement des tâches telles que l’encryption et le
décryptage. Aucune implémentation SSL ne peut être plus forte que
les outils cryptographiques sur lesquels elle est basée.
Au moment d’écrire ces lignes, SSL lui-même n’a pas de faiblesses
significatives connues. Certains algorithmes cryptographiques courants,
cependant, ont été attaqués avec succès, au moins dans le contexte
d’universitaires ou d’autres recherches. (Il n’y a pas de cas
publiquement reconnus de quiconque exploite ces faiblesses théoriques
dans un contexte commercial.) L’annexe b décrit plus en détail les
attaques signalées publiquement, mais, en général, les implémentations
SSL doivent tenir compte non seulement de la sécurité de SSL, mais
également de celle des services cryptographiques sur lesquels elle est
construite.
Introduction 15
1.4.3 Environmental Limitations

Un protocole réseau seul ne peut assurer la sécurité des informations
que lorsqu’elles transitent par un réseau. Aucun protocole réseau ne
protège les données avant leur envoi ou après leur arrivée à
destination. C’est la seule faiblesse connue de la sécurité Web qui a
été exploitée avec succès dans un contexte commercial réel.
Malheureusement, il a été exploité plus d’une fois.
La sécurité de tout réseau informatique, qu’il s’agisse de l’Internet
public ou d’installations privées, est fonction de tous les éléments qui
composent ce réseau. Cela dépend des protocoles de sécurité du
réseau, des systèmes informatiques qui utilisent ces protocoles et des
êtres humains qui utilisent ces ordinateurs. Aucun protocole de
sécurité réseau ne peut protéger contre l’impression confidentielle
laissée négligemment sur une table de cafétéria.
Le protocole Secure Sockets Layer est un outil de sécurité puissant et
efficace, mais ce n’est qu’un outil unique. Une véritable sécurité
nécessite de nombreux outils de ce type et un plan complet pour les
utiliser.
1.5 Organization of This Book
Quatre autres chapitres et deux annexes composent le reste de ce

livre. Le chapitre 2 examine certains des principes essentiels de la
cryptographie et des algorithmes cryptographiques. Bien que, à
proprement parler, ces algorithmes ne fassent pas partie du protocole
ssl, une bonne partie de la conception du protocole dépend de
principes cryptographiques généraux. Sans aller trop loin dans les
mathématiques de la cryptographie, chapitre 2
examine ces principes essentiels. Le chapitre 3 commence

sérieusement l’examen du SSL. Il décrit le protocole SSL en
fonctionnement. Il discute du contenu des messages SSL, mais
seulement en termes généraux. Le chapitre explique ce que fait ssl
sans s’enliser dans les détails de la façon dont il le fait. Le chapitre 4,
en revanche, se concentre exclusivement sur ces détails. Il
documente le format de tous les messages ssl, ainsi que les calculs
cryptographiques utilisés par ssl pour les construire. Le chapitre 5
fournit des détails supplémentaires sur SSL. Il décrit comment la
version actuelle de SSL fonctionne avec les versions précédentes de
SSL, et comment Netscape et Microsoft ont chacun augmenté SSL
avec des techniques qui favorisent un cryptage fort dans le monde
entier, tout en respectant les restrictions d’exportation des États-Unis.
Ce chapitre fournit également une couverture complète de Transport
Layer Security, détaillant toutes les différences entre t l s et ssl.
L’annexe A fourni des détails supplémentaires sur les certificats de clé

publique. Ces certificats, conformes à la norme x.509, sont essentiels
au fonctionnement de ssl, même s’ils ne font pas partie du protocole
lui-même. L’annexe comprend une brève introduction à Abstract
Syntax Notation One, le langage utilisé par la norme x.509 pour les
certificats de documentation. L’annexe b présente une liste de
vérification de sécurité pour SSL. Il comprend une liste de bonnes
pratiques pour le développement de mises en œuvre SSL et de
défenses contre toutes les attaques connues contre les systèmes
sécurisés SSL.
2
Basic Cryptography
Le Web est peut-être un moyen relativement nouveau de

communiquer, mais la sécurisation du Web repose sur les mêmes
principes qui ont sécurisé d’autres médias de communication pendant
des milliers d’années. En fait, la nature numérique du Web facilite
l’application de ces techniques. En outre, les systèmes sur le Web
peuvent tirer parti de nouvelles technologies de sécurité puissantes.
Le présent chapitre examine brièvement les principes importants qui
régissent la sécurité des communications.
La discipline scientifique qui étudie la sécurité des communications
est la cryptographie, et plusieurs concepts de la cryptographie
moderne sont indispensables au protocole Secure Sockets Layer. La
première des trois sections suivantes décrit les utilisations de la
cryptographie. La section suivante examine plus en détail deux types
particuliers de cryptographie : la cryptographie à clé secrète et la
cryptographie à clé publique. Comme les noms l’indiquent, les clés
sont une partie importante des deux types, et ce chapitre conclut en
discutant de la gestion de ces clés. La gestion des clés joue un rôle
essentiel dans le fonctionnement de SSL.
Comme le texte suivant l’implique, la cryptographie repose
fortement sur une base mathématique. Mais comprendre les
mathématiques de la cryptographie n’est pas essentiel pour
comprendre ssl. Pour cette raison, ce chapitre contient très peu de
mathématiques. Les lecteurs intéressés par une compréhension plus
approfondie de la cryptographie sont invités à consulter les textes
décrits dans la section Références de ce livre.
17
18 SSL & TLSEssentials:Securing the Web
2.1 Using Cryptography
Le mot cryptographie est dérivé du grec pour « écriture secrète ». La

tâche de garder l’information secrète est probablement celle qui est le
plus souvent associée à la cryptographie. En effet, la protection des
informations secrètes est une mission importante pour les
cryptographes, mais, comme le montre cette section, la cryptographie
a également d’autres utilisations. Deux qui sont particulièrement
importants pour SSL sont la preuve de l’identité et la vérification des
informations. Le tableau 2-1 résume les principaux sujets abordés
dans cette section.
Table 2-1 Important Usesof Cryptography
Use Service Protects Against
Keeping secrets Confidentiality Eavesdropping
Proving identity Authentication Forgery and masquerade
Verifying information Message integrity Alteration
2.1.1 Keeping Secrets
Pour continuer avec une convention qui est devenue presque

universelle dans les textes de cryptographie, considérons le dilemme
auquel Alice et Bob sont confrontés dans la figure 2-1. Alice doit
envoyer des informations importantes à Bob.
Charles
Alice Bob
Figure 2-1 Cryptography can protect information from eavesdroppers.

BasicCryptography 19
L’information est extrêmement confidentielle et il est important que

personne d’autre que Bob ne la reçoive. Si, comme dans cet exemple,
la seule façon pour Alice de communiquer avec Bob est par carte
postale, comment peut-elle lui envoyer l’information sans l’exposer
aux facteurs, aux voisins fouineurs ou à toute autre personne qui voit
la carte postale vitale ?
La cryptographie donne à Alice et Bob les moyens de protéger leur
échange. Avant d’envoyer la carte postale, Alice utilise un code
secret, ou cipher, qu’elle et Bob seuls comprennent. Le chiffrement
brouille l’information, la rendant inintelligible pour des parties telles
que Charles qui ne connaissent pas le code secret. Bob, cependant,
connaît le code secret et peut déchiffrer les informations nécessaires.
2.1.2 Proving Identity
Considérons maintenant la situation dans la figure 2-2. Bob reçoit

une carte postale contenant des informations importantes,
prétendument d’Alice. Mais comment sait-il que la carte postale
vient vraiment d’Alice ? Charles aurait-il falsifié la carte pour la faire
apparaître comme si elle venait d’Alice ? Encore une fois, cryptogra-
phy fournit une solution.
Charles
Bob
Alice
Figure 2-2 Cryptography can help verify asender’s identity.

Grâce à l’utilisation de la cryptographie, Alice peut joindre des informations spéciales,

telles qu’une phrase secrète, à la carte postale. Cette phrase secrète est une information
que seuls elle et Bob connaissent. Comme Charles ne connaît pas la phrase secrète, il ne
pourra pas l’attacher à un faux. Maintenant, tout ce que Bob a à faire est de chercher la
phrase secrète. Si elle est présente, alors la carte postale est authentique ; S’il est absent,
il devrait se méfier.
2.1.3 Verifying Information

Prouver l’identité est une chose, mais supposons que Charles soit
capable d’intercepter un message authentique d’Alice à Bob. Charles
pourrait alors modifier le message et le transmettre à Bob, comme
dans la figure 2-3. Les changements de Charles pourraient modifier
le sens du message de manière significative, mais pas détruire la
phrase secrète qui « prouve » qu’Alice était l’expéditeur. Pour se
protéger contre ce type de comportement, il doit y avoir un moyen
non seulement de vérifier l’identité de la source du message, mais
aussi de s’assurer que le contenu du message n’a pas été modifié de
quelque manière que ce soit. Encore une fois, la cryptographie offre
une solution.
Pour valider les informations sur sa carte postale, Alice peut utiliser un type
spécial de fonction cryptographique connu sous le nom de fonction de
hachage. Une fonction de hachage crée un résumé mathématique spécial
d’informations. Si l’information est modifiée et que la fonction de hachage
est recalculée, il en résultera un résumé différent. Pour empêcher Charles de
réussir à falsifier sa carte postale, Alice calcule la fonction de hachage pour
les informations sur la carte, plus une valeur secrète qu’elle et Bob
connaissent.
Charles
Alice Bob
Figure 2-3 Cryptography can ensure information has not been altered.
Elle ajoute ensuite le résumé résultant à la carte postale. Lorsque Bob

reçoit la carte, il peut également calculer la fonction de hachage. Si
son résumé correspond à celui de la carte, l’information est valide.
Les fonctions de hachage cryptographique ressemblent à des sommes
de contrôle ou à des codes de contrôle de redondance cyclique (c r c)
qui sont des mécanismes de détection d’erreurs courants pour les
protocoles de communication traditionnels. Il y a cependant une
différence importante. Les sommes de contrôle et les codes c r c sont
conçus pour détecter les altérations accidentelles, telles que celles qui
pourraient se produire sur un support de transmission peu fiable. Les
hachages cryptographiques, en revanche, sont optimisés pour
détecter les altérations délibérées. Parce qu’elles supposent que
l’attaquant malveillant a une connaissance complète de l’algorithme
et peut donc exploiter toute faiblesse, les fonctions de hachage
efficaces sont beaucoup plus difficiles à concevoir que les
algorithmes de détection d’erreurs standard.
Deux fonctions de hachage particulières sont essentielles aux

implémentations SSL. Le premier est Message Digest 5 (md5), conçu
par Ron Rivest. L’autre fonction de hachage importante est
l’algorithme de hachage sécurisé (sha), proposé par le National
Institute of Science and Technology des États-Unis. Les deux feront
leur apparition dans les chapitres 4 et 5 lorsque nous examinerons les
détails des spécifications SSL et TLS.
2.2 Tyes of Cryptography
Comme même la brève introduction précédente l’indique clairement,

un élément essentiel de la cryptographie est l’utilisation de codes
secrets qui ne sont partagés que par les parties communicantes. Qu’il
s’agisse de garder des secrets, de prouver leur identité ou de vérifier
des informations, Alice et Bob doivent connaître des informations
secrètes que Charles ne connaît pas. Les cryptographes appellent
cette information une clé.
Les techniques cryptographiques se répartissent en deux catégories,
selon le type de clés qu’elles utilisent : la cryptographie à clé secrète
et la cryptographie à clé publique. Les sous-sections suivantes
décrivent chacune séparément, puis discutent de la façon dont les
mises en œuvre pratiques utilisent souvent une combinaison des deux
approches.
2.2.1 Key Cryptography

Avec la cryptographie à clé secrète, les deux parties connaissent la
même information – la clé – et les deux s’efforcent de garder cette
clé secrète de toute autre personne. C’est ainsi que la plupart des
gens pensent de la cryptographie en général, et, pour presque toute
l’histoire de plusieurs milliers d’années de codes secrets, c’était la
seule forme de cryptographie connue. L’aspect critique de la
cryptographie à clé secrète est que les deux parties connaissent les
mêmes informations secrètes. Pour cette raison, il porte le nom
technique de cryptage symétrique.
Les algorithmes de chiffrement, ou chiffrements, basés sur des
techniques de clé secrète ne sont généralement que des
transformations mathématiques sur les données à crypter, combinées
avec la clé secrète elle-même. L’approche ressemble à un jeu de
coquille de carnaval, avec la clé secrète servant de localisation
initiale du pois. Les bits sont échangés et combinés les uns aux autres
de manière très compliquée, et pourtant les différentes
transformations peuvent facilement être annulées, à condition de
connaître la clé. Comme indice des complexités impliquées, la figure
2-4 illustre l’un des algorithmes de chiffrement les plus courants. La
figure introduit également deux termes génériques courants : texte en
clair, information avant cryptage, et texte cipher, information sous sa
forme cryptée. Le texte en clair est vulnérable aux attaquants ; Le
texte chiffré, du moins en théorie, ne l’est pas.
Une qualité importante qui détermine l’efficacité d’un chiffrement
est la taille de la clé secrète. Plus la clé est grande, plus il est difficile
de casser le code. Pour comprendre pourquoi c’est le cas,
considérons un algorithme avec une taille de clé extrêmement petite :
2 bits. Dans cet exemple, l’algorithme lui-même n’aurait vraiment
pas d’importance. Après tout, avec 2 bits, il n’y a que quatre clés
possibles. Un attaquant qui obtiendrait des données chiffrées pourrait
simplement essayer les quatre possibilités.
Les cryptographes caractérisent également les algorithmes de chiffrement symétrique en
fonction de la façon dont ils traitent les données d’entrée. Les chiffrements peuvent être des
chiffrements de flux ou des chiffrements par blocs. Les chiffrements de flux traitent les
données d’entrée un octet à la fois et peuvent accepter n’importe quelle taille d’entrée pour le
chiffrement. Les consommateurs de blocs, en revanche, ne fonctionnent que sur des blocs de
données de taille fixe, généralement de 8 octets. Les chiffrements par blocs nécessitent
moins de ressources de calcul et sont généralement légèrement moins vulnérables aux
attaques.
plaintext
Data to
Protect
initial permutation
L0 R0
K1
+ f
L1 = R0 R1 = L0 + f(R0,K1)
K2
+ f
L2 = R1 R2 = L1 + f(R1,K2) Secret
Key
[repeated 12 more times]
K15
+ f
L15 = R14 R15 = L14 + f(R14,K15)

K16
+ f
R16 = L15 + f(R15,K16) L15 = R15
inverse permutation
Hidden
ciphertext
Data
Figure 2-4 The DEScipher hides data by scrambling it with asecret key.
(Et, par conséquent, sont de loin le type le plus commun). Ils sont
cependant légèrement moins pratiques à utiliser. Les données
d’entrée elles-mêmes sont la source du désagrément ; Il est rarement
de la même taille que le bloc de chiffrement. Le chiffrement des
données à l’aide d’un chiffrement par bloc nécessite de diviser les
données en blocs et, si le dernier bloc ne contient pas exactement la
bonne quantité de données, d’ajouter des données factices, connues
sous le nom de remplissage, pour les remplir.
Les chiffrements par blocs nécessitent également généralement un

vecteur d’initialisation de données factices pour commencer le
processus de cryptage. Le vecteur d’initialisation amorce
l’algorithme avec des informations non pertinentes, ce qui permet au
chiffrement de s’accumuler jusqu’à sa pleine puissance avant que le
texte en clair n’apparaisse. Le tableau 2-2 répertorie les chiffrements
symétriques les plus couramment utilisés avec le protocole Secure
Sockets Layer.
Table 2-2 SymmetricEncryption Algorithms
Abbreviation Algorithm Type
DES DataEncryption Standard Block
3DES Triple-Strength DataEncryption Standard Block
RC2 Rivest Cipher 2 Block
RC4 Rivest Cipher 4 Stream
2.2.2 Public Key Cryptography

La plupart des difficultés avec la cryptographie traditionnelle à clé
secrète sont causées par les clés elles-mêmes. Alice et Bob doivent
avoir la même clé secrète, mais en aucun cas Charles ne doit avoir
cette clé aussi. Cela implique qu’avant qu’Alice et Bob puissent
communiquer des informations en toute sécurité, ils doivent être en
mesure de communiquer la clé secrète en toute sécurité. Le problème
imite le dilemme classique de la poule ou de l’œuf. Après tout, s’il
existe un moyen sûr pour Alice et Bob de communiquer la clé
secrète, pourquoi ne peuvent-ils pas utiliser la même méthode pour
communiquer l’information et se passer complètement des
complexités de la cryptographie ? (Dans certaines situations, telles
que l’espionnage de cape et de poignard, les deux parties peuvent se
mettre d’accord sur la clé à l’avance, alors qu’elles sont
physiquement ensemble ; pour des raisons évidentes, cette approche
n’est pas pratique pour les situations dans lesquelles les parties ne se
rencontrent jamais en face à face, comme le commerce sur le Web.)
Un développement relativement nouveau dans la cryptographie a
éliminé l’impasse de la distribution de clés et a rendu possible des
technologies telles que SSL et le commerce électronique. Ce
développement est la cryptographie à clé publique. La cryptographie
à clé publique ou, plus techniquement, le cryptage asymétrique,
permet à chacune des deux parties d’utiliser des clés distinctes, une
pour le cryptage et une autre pour le décryptage. L’aspect critique de
la cryptographie à clé publique est qu’une seule de ces deux clés doit
être conservée séparément. L’autre clé, la clé publique, n’a pas
besoin d’être secrète du tout.
Bien que cela ressemble un peu à de la magie, cela a une solide base
mathématique. Fondamentalement, le cryptage asymétrique est basé
sur des problèmes mathématiques qui sont plus faciles à générer qu’à
résoudre. Par exemple, toute personne disposant d’une calculatrice de
poche peut calculer le produit de 113 et 293 et obtenir la bonne
réponse de 33 109. Il est beaucoup plus difficile, cependant, d’utiliser
la même calculatrice de poche pour résoudre un problème similaire
en sens inverse. Lesquels deux nombres entiers, lorsqu’ils sont
multipliés, donnent le produit 29213 ?1
La figure 2-5 montre comment le chiffrement à clé publique peut
fonctionner. Lorsque Bob veut qu’Alice lui envoie des informations en
toute sécurité, il génère deux keys.
1
Create
keys.
2
3
Publish
Encipher public
with key.
public
key.
5
4
Decipher
Send with
encrypted private
message. key.
Alice Bob
Figure 2-5 Public key cryptography uses published keys to encrypt data.
1
The answer, for the insatiably curious, is 131 and 223.
L’une est la clé privée, que Bob garde complètement pour lui. À
l’inverse, Bob fait de la publicité pour la clé publique,
conceptuellement même en la publiant dans un journal. Alice lit le
journal pour trouver la clé publique, puis l’utilise pour chiffrer les
informations. Lorsque Bob reçoit la carte postale d’Alice, sa clé
privée lui permet de déchiffrer le message. Puisque seul Bob a sa clé
privée, seul Bob peut déchiffrer avec succès les informations. Même
Alice serait incapable de le faire.
Certains algorithmes de chiffrement à clé publique, notamment
l’algorithme Rivest Shamir Adleman (rsa) couramment utilisé avec
ssl, fonctionnent également en inverse. Les informations chiffrées
avec une clé privée peuvent être déchiffrées avec la clé publique
correspondante. Cette fonctionnalité a plusieurs applications
puissantes, surtout pour SSL, comme un moyen de prouver l’identité.
Imaginez, comme dans la figure 2-6, que Bob crypte une information
bien connue en utilisant sa clé privée et envoie le texte chiffré
résultant à Alice. Alice peut utiliser la clé publique de Bob pour
déchiffrer l’information. Elle compare ensuite le résultat avec les
informations bien connues qu’elle attendait. S’il y a une
correspondance, Alice est assurée que l’information a été cryptée
avec la clé privée de Bob. Seule cette clé aurait permis le décryptage
réussi. Et, puisque Bob est la seule personne qui connaît sa clé
privée, Alice est en outre assurée que Bob était le
1
Encipher
with
private
key.
3
2
Decipher
with Publish
public public
key. key.
Alice Bob
Figure 2-6 Public key ciphers verify identity using published keys.
celui qui a envoyé l’information. Grâce à cette approche, Bob a
prouvé son identité à Alice. Les algorithmes à clé publique
réversibles tels que rsa peuvent également fournir un autre service
important : l’équivalent numérique d’une signature. Supposons que
Bob ait besoin d’informations de la part d’Alice. Supposons en outre
qu’il soit important qu’Alice ne puisse pas nier plus tard lui avoir
envoyé l’information, que ce soit à Bob ou à un tiers indépendant (tel
qu’un juge). En effet, Bob a besoin d’Alice pour signer
l’information. Pour accompagner cela, Alice peut chiffrer les
informations avec sa clé privée. Puisque n’importe qui peut obtenir
sa clé publique, n’importe qui peut déchiffrer l’information. Seule
Alice, cependant, connaît sa clé privée, donc seule Alice aurait pu
chiffrer les informations en premier lieu.
Certains algorithmes à clé publique ne peuvent être utilisés que pour
les signatures numériques ; Ils ne peuvent pas fournir de services de
cryptage. L’un de ces algorithmes importants pour ssl est
l’algorithme de signature numérique (dsa).
2.2.3 Combining Secret and PublicKey Cryptography

Le chiffrement à clé publique est un outil puissant, mais dans la
plupart des mises en œuvre pratiques, il souffre d’un inconvénient
sérieux : l’opération d’enregistrement est extrêmement complexe.
Des opérations mathématiques complexes peuvent mettre à rude
épreuve certains systèmes, nécessitant une capacité de traitement
supérieure à celle dont les systèmes auraient autrement besoin. S’il
n’y avait pas d’alternatives, la plupart des implémentations
nécessitant une sécurité pourraient accepter le coût système plus
élevé ; Heureusement, il existe un moyen relativement simple
d’obtenir les avantages du chiffrement à clé publique tout en évitant
la plupart des coûts de performance du système. L’approche optimale
utilise une combinaison de clé secrète et de cryptographie à clé
publique.
La figure 2-7 montre comment cette combinaison peut fonctionner
dans la pratique. Pour commencer, Bob crée une clé publique et une
clé privée, puis il publie la clé publique. Il ne partage la clé privée
avec personne. Alice, qui souhaite envoyer des données
confidentielles à Bob, récupère sa clé publique. Elle génère également
une collection de nombres aléatoires. Une fois qu’Alice a la clé
publique de Bob, elle crypte ces nombres aléatoires et les envoie à
Bob. Puisque seul Bob a sa clé privée, seul Bob peut déchiffrer le
message d’Alice et extraire les nombres aléatoires.
2 1
Publish
Generate
public
random
key.
numbers
forsecret
keys.
3 4
Decipher
Encrypt
secret
secret
keyswith
keyswith
private
Bob's
key.
publickey.
5 5
Encipher Encipher
and and
decipher decipher
data with data with
secret keys. secret keys.
Alice Bob
Figure 2-7 Effective security combines secret and public key techniques.
Une fois qu’Alice et Bob ont échangé avec succès les numéros
aléatoires, ils n’ont plus besoin de cryptage à clé publique. Au lieu de
cela, ils peuvent utiliser les nombres aléatoires comme clés secrètes
pour l’encryption symétrique standard. Alice et Bob peuvent
communiquer en toute sécurité aussi longtemps qu’ils le souhaitent.
Et comme le cryptage symétrique n’a pas besoin d’autant de
puissance de traitement que le cryptage asymétrique, le cryptage a un
coût beaucoup plus faible.
Il existe une variation importante de ce processus qui repose sur un
type différent d’algorithme à clé publique. Le type spécial
d’algorithme est connu sous le nom d’algorithme d’échange de clés,
et l’exemple le plus célèbre est l’algorithme de Diffie-Hellman.
Diffie-Hellman est généralement considéré comme un algorithme à

clé publique, même s’il ne peut pas être utilisé pour le cryptage ou
pour les signatures numériques. Au contraire, Diffie-Hellman permet
à deux parties d’établir en toute sécurité un numéro secret en utilisant
uniquement des messages publics. Diffie-Hellman est une alternative
aux étapes 1 à 4 de la figure 2-7.
Une dernière remarque sur la figure 2-7 : Comme le chapitre suivant
le détaille, il s’agit en fait d’une vue simplifiée du fonctionnement
SSL de base. La figure 3-1 montre une version différente du même
procédé.
2.3 Management
La gestion des clés est un défi pour toutes les formes de
cryptographie. La cryptographie à clé publique améliore la situation ;
Au moins, les clés que les parties échangent n’ont pas à être gardées
secrètes du reste du monde. Néanmoins, la clé publique doit être
échangée de manière fiable. Dans les exemples précédents, Alice a
hypothétiquement récupéré les clés publiques de Bob dans le journal.
Supposons, cependant, que l’infâme Charles ait pu imprimer un faux
journal (avec une fausse clé publique pour Bob) et le glisser dans
l’allée d’Alice le matin à la place de son vrai journal. Comment Alice
aurait-elle connaissance de la fraude ?
C’est précisément ce problème qui a conduit à la création de
certificats de clé publique et d’autorités de certification. Bien qu’ils
ne soient pas remarqués par la plupart des utilisateurs occasionnels
d’Internet, ils sont essentiels au protocole Secure Sockets Layer et au
commerce Web.
2.3.1 Public Key Certificates
À bien des égards, les certificats à clé publique sont l’équivalent
numérique d’un permis de conduire. Bien que les certificats puissent
appartenir à des systèmes informatiques plutôt qu’à des individus, ils
partagent trois caractéristiques importantes avec les permis de
conduire. Tout d’abord, ils identifient chacun leurs sujets en incluant
les noms des sujets. Deuxièmement, ils affirment des informations
clés sur le sujet. Un permis de conduire déclare que le sujet a certains
privilèges (c’est-à-dire conduire une voiture), tandis qu’un certificat
affirme la clé publique du sujet (et peut-être d’autres privilèges).
Enfin, un certificat et un permis de conduire sont délivrés par une
organisation de confiance, soit une agence gouvernementale ou une
autorité de certification.
La figure 2-8 montre le contenu d’un certificat de clé publique

typique. L’annexe a traite en détail de ce format de certificat
particulier, mais seuls quelques-uns des champs sont vraiment
importants. Le premier est le champ émetteur, qui identifie
l’organisation qui a émis le certificat. Cette information est
essentielle pour une personne ou un système informatique qui extrait
un certificat, car elle détermine si le certificat peut être approuvé. Le
champ important suivant est la période de validité. Comme les
permis de conduire, les certificats expirent après un certain temps. Le
champ suivant identifie le sujet du certificat et est suivi de la clé
publique du sujet.
Le dernier champ du certificat est également important. Ce champ
est la signature de l’issuer, qui est une signature numérique du
contenu du certificat. L’émetteur crée cette signature en chiffrant un
hachage du certificat avec sa clé privée. Tout système connaissant la
clé publique de l’émetteur peut vérifier la signature et s’assurer de la
validité du certificat. Étant donné que ce champ peut être un peu
déroutant, il convient de souligner que l’émetteur crée la signature à
l’aide de sa propre clé privée, tandis que le certificat lui-même
contient la clé publique du sujet.
Version
Serial Number
Algorithm Identifier
Issuer
Period of Validity
Subject
Subject'sPublicKey
Issuer Unique ID
Subject Unique ID
Extensions
Signature
Figure 2-8 A public key certificate validatesasubject’s public key.

2.3.2 Certificate Authorities

L’émetteur d’un certificat de clé publique est traditionnellement
connu sous le nom d’autorité de certification (CA), et les autorités de
certification jouent un rôle essentiel dans l’établissement de la
confiance au sein d’une communauté d’utilisateurs. Comme l’indique
la sous-section précédente, l’autorité de certification signe
numériquement tous les certificats, attestant de la validité des clés
publiques qu’ils contiennent. Si les utilisateurs font confiance à
l’autorité de certification, ils peuvent approuver n’importe quel
certificat émis par CA.
Dans de nombreux cas, une autorité de certification peut être
identifiée comme une autorité de certification privée ou publique.
Les autorités privées comprennent les organisations qui poursuivent
les certificats strictement pour leurs propres utilisateurs. Une société,
par exemple, peut délivrer des certificats de clé publique à ses
employés. (En fait, ils émettraient les certificats pour les ordinateurs
des employés.) L’entreprise pourrait alors configurer son réseau
interne pour exiger des certificats appropriés avant d’accorder l’accès
aux données critiques. Bien que les systèmes du réseau informatique
de l’entreprise puissent faire confiance aux certificats de l’entreprise,
il est peu probable que des systèmes externes, y compris, par
exemple, des serveurs Web publics, le fassent. Une autorité de
certificat privée émet des certificats à utiliser sur ses propres réseaux
privés. Mais Internet est un réseau public, et la sécurité du Web
repose généralement sur les autorités de certification publiques. Une
autorité de certification publique poursuit les certificats auprès du
grand public et peut certifier l’identité des individus et des
organisations. Les autorités publiques agissent comme l’équivalent
numérique des notaires publics, certifiant l’identité de toute partie qui
présente les informations d’identification appropriées. Pour une
entreprise qui souhaite établir un site Web sécurisé, ces informations
d’identification peuvent inclure un numéro d-u-n-s de Dun &
Bradstreet, une licence commerciale, des statuts de société ou des
dépôts auprès de la SEC qui établissent l’identité de l’entreprise.
Les autorités de certification sont elles-mêmes fréquemment
identifiées par leurs certificats, mais leurs certificats diffèrent des
certificats standard sur un point important: le sujet et l’émetteur sont
une seule et même personne. L’autorité de certification certifie sa
propre identité. La figure 2-9 met en évidence le fait que la clé
publique dans un certificat d’autorité de certification est également la
clé publique qui vérifie la signature du certificat.
Version
Serial Number
Algorithm Identifier
Issuer
Issuer and
Period of Validity Subject are
thesame.
Subject
Subject'sPublicKey
Issuer Unique ID Subject's

PublicKey
Subject Unique ID verifies the
certificate's
Extensions Signature.
Signature
Figure 2-9 CA certificates have the same issuer and subject.
Il s’agit d’une distinction essentielle par rapport aux certificats

normaux. Toute partie qui reçoit un certificat normal peut vérifier la
signature du certificat pour décider d’approuver ou non la clé
publique dans ce certificat. Tant que la nature du certificat est valide
et que l’émetteur est digne de confiance, la partie réceptrice peut
faire confiance à la clé publique en toute sécurité. Avec un certificat
ca, en revanche, la vérification de la signature du certificat n’aide pas
à établir la confiance. Toute partie qui pourrait falsifier un certificat
ca connaîtrait la clé privée falsifiée et pourrait donc facilement
générer la signature correspondante. La validité des certificats ca doit
être établie par d’autres méthodes.
Dans le cas de la sécurité du commerce Web, la validité des
autorisations de certificat dépend en grande partie des fabricants de
navigateurs. Internet Explorer de Microsoft et Netscape Navigator
reconnaissent par défaut les certificats des autorisations de certificats
publiques importantes. La figure 2-10 montre certaines des autorités
de certification reconnues par Netscape. (La liste complète, au
moment d’écrire ces lignes, comprend plus de 50 autorités.) Bien que
Netscape et Microsoft permettent aux utilisateurs d’intégrer des
autorités de certification supplémentaires dans leurs navigateurs, la
plupart des sites Web sécurisés choisissent d’utiliser un certificat qui
ne nécessite pas cet avantage supplémentaire de la part de leurs
utilisateurs.
Figure 2-10 Netscape Navigator recognizes many certificate authorities.
2.3.3 Certificate Hierarchies

Parfois, il devient difficile pour une autorité de certification de suivre
efficacement toutes les parties dont elle certifie l’identité. D’autant
plus que le nombre de certificats augmente, une autorité unique peut
devenir un goulot d’étranglement inacceptable dans le processus de
certification. Heureusement, les certificats à clé publique prennent en
charge le concept de hiérarchie de certificats, ce qui atténue les
problèmes d’évolutivité d’une seule autorité monolithique.
Avec une hiérarchie en place, une autorité de certification n’a pas
besoin de certifier elle-même toutes les identités. Au lieu de cela, il
désigne une ou plusieurs autorités subsidiaires. Ces autorités peuvent,
à leur tour, désigner leurs propres filiales, la hiérarchie se
poursuivant jusqu’à ce qu’une autorité certifie effectivement les
utilisateurs finaux. La figure 2-11 illustre une hiérarchie simple à
trois niveaux, qui peut se produire au sein d’une grande société.
Comme le montre la figure, acme Corporation dispose d’une autorité
de certification principale et de deux autorités subordonnées, l’une
pour les ressources humaines et l’autre pour la recherche et le
développement. Les autorités subordonnées sont responsables des
entités relevant de leurs domaines.
Issuer:
ACMECorp.
Subject:
ACMECorp.
Issuer: Issuer:
ACMECorp. ACMECorp.
Subject: Subject:
HR Dept. R&D Dept.
Issuer: Issuer: Issuer: Issuer:

HR Dept. HR Dept. R&D Dept. R&D Dept.
Subject: Subject: Subject: Subject:

Intranet Benefits Software Documents
Figure 2-11 Certificate hierarchies divide responsibility for certificates.
Une caractéristique particulièrement puissante des hiérarchies de

certificats est qu’elles n’exigent pas que toutes les parties fassent
automatiquement confiance à toutes les autorités de certification. En
effet, la seule autorité dont la confiance doit être établie dans toute
l’entreprise est l’autorité de certification principale. En raison de sa
position dans la hiérarchie, cette autorité est généralement connue
sous le nom d’autorité racine.
Pour voir ce processus en action, considérez ce qui se passe
lorsqu’un client du département R&D doit vérifier l’identité du
serveur Benefits. Le serveur présente son certificat, émis (et signé)
par l’autorité du département hr. Cependant, le client de la R&D ne
fait pas confiance à l’autorité de hr, il demande donc à voir le
certificat de cette autorité. Lorsque le client reçoit le certificat de
l’autorité hr, il peut vérifier que l’autorité hr a été certifiée par
l’autorité racine de la société. Puisque le client r&d fait confiance à
l’autorité de certification racine, il peut faire confiance au serveur
Avantages.
2.3.4 Certificate Revocation Lists (-----------)
Avant de quitter le sujet des certificats de clé publique, il y a une

extrémité à régler. Jusqu’à présent, nous avons vu comment les
autorités de certification émettent des certificats, mais qu’en est-il du
processus inverse? Que se passe-t-il si une autorité de certification
émet un certificat par erreur et veut se corriger? Ou que se passe-t-il
si un sujet révèle accidentellement sa clé privée, de sorte que sa clé
publique certifiée n’est plus sûre à utiliser ? Pour résoudre ces types
de problèmes, les autorités de certificats utilisent des listes de
révocation de certificats. Une liste de révocation de certificats, ou c r
l en abrégé, est une liste de certificats que l’autorité a émis
précédemment, mais que l’autorité ne considère plus valides. Les
certificats eux-mêmes semblent toujours légitimes ; Leurs signatures
sont correctes et leurs périodes de validité sont appropriées.
Néanmoins, l’autorité compétente doit indiquer qu’on ne peut plus
leur faire confiance. L’autorité ne peut pas modifier les certificats
puisqu’ils ont déjà été émis, donc le mieux qu’elle puisse faire est de
maintenir une liste de ces certificats révoqués. Il est de la
responsabilité de toute partie qui fait confiance au certificat d’une
autre partie de vérifier auprès de l’autorité de certification pour
s’assurer que le certificat n’a pas été révoqué. Cette fonction n’est
pas la responsabilité du protocole ssl, nous n’en discuterons donc pas
en profondeur. Il convient toutefois de noter que l’infrastructure
actuelle du commerce Web ne dispose pas d’un moyen efficace (et
largement pris en charge) pour les systèmes de vérifier un certificat
par rapport à un c r l. Pour cette raison, il n’existe aucun moyen
pratique de révoquer un certificat de commerce Web traditionnel.
38 SSL & TLS Essentials : Securing the
Web
3
SSLOperation
Avec une compréhension de certains des concepts clés de la

cryptographie, nous pouvons maintenant examiner de près le
fonctionnement du protocole Secure Sockets Layer (SSL). Bien que
ssl ne soit pas un prototype extrêmement compliqué, il offre plusieurs
options et variantes. Ce chapitre explique ssl en commençant par le
cas le plus simple : établir un canal de communication crypté. Il
envisage ensuite successivement des options plus complexes, y
compris l’authentification des parties communicantes, la séparation
du cryptage de l’authentification et la reprise d’une session
précédemment établie. Dans ces sections, vous découvrirez toute la
puissance de ssl.
Le protocole SSL se compose d’un ensemble de messages et de
règles sur le moment d’envoyer (et de ne pas envoyer) chacun d’eux.
Dans ce chapitre, nous examinons ce que sont ces messages, les
informations générales qu’ils contiennent et comment les systèmes
utilisent les différents messages dans une session de communication.
Cependant, nous n’explorons pas les formats de message détaillés :
les bits et les octets qui composent les messages SSL lorsqu’ils
transitent sur un réseau. Ce détail fait l’objet du chapitre 4. Nous ne
passons pas non plus de temps ici sur les calculs cryptographiques
détaillés requis par ssl ; Ceux-ci sont également un sujet pour le
chapitre suivant. Ce chapitre se concentre sur la vue d’ensemble. Les
détails seront beaucoup plus faciles à comprendre une fois que vous
aurez une appréciation du fonctionnement global du Secure Sockets
Layer.
3.1 SSLRoles
SSLOperation 39
Le protocole Secure Sockets Layer définit deux rôles différents pour

les parties communicantes. Un système est toujours un client, tandis
que les 37 autres sont un serveur. La distinction est très importante,
car le SSL exige que les deux systèmes se comportent très
différemment. Le client est le système qui initie les communications
sécurisées ; Le serveur répond à la demande du client. Dans
l’utilisation la plus courante de ssl, la navigation Web sécurisée, le
navigateur Web est le client ssl et le site Web est le serveur ssl. Ces
deux mêmes rôles s’appliquent à toutes les applications qui utilisent
ssl, et les exemples de ce chapitre (en fait, tout au long du livre) les
distingueront clairement.
Pour SSL lui-même, les distinctions les plus importantes entre les
clients et les serveurs sont leurs actions lors de la négociation des
paramètres de sécurité. Puisque le client initie une communication, il
a la responsabilité de proposer un ensemble d’options SSL à utiliser
pour l’échange. Le serveur sélectionne parmi les options proposées
par le client, décidant de ce que les deux systèmes utiliseront
réellement. Bien que la décision finale appartienne au serveur, celui-
ci ne peut choisir que parmi les options initialement proposées par le
client.
3.2 SSL Messages

Lorsque les clients et les serveurs SSL communiquent, ils le font en
échangeant des messages SSL. Techniquement, ssl définit différents
niveaux de messages, mais il est préférable de laisser ce sujet au
chapitre 4. Étant donné que ce chapitre se concentre strictement sur
la fonctionnalité, il n’est pas essentiel de faire la distinction entre les
différents niveaux de SSL. Le tableau 3-1 répertorie les messages
SSL à tous les niveaux du protocole, par ordre alphabétique. Les
sections restantes de ce chapitre montrent comment les systèmes
utilisent ces messages dans leurs communications.
Table 3-1 SSL Messages
Message Description
Alert Informs the other party of a possible security
breach or communication failure.
ApplicationData Actual information that the two parties ex-
change, which is encrypted, authenticated,
and/or verified by SSL.
Certificate A message that carries the sender’s public key
certificate.
Web
Message Description
CertificateRequest A request by the server that the client provide
its public key certificate.
CertificateVerify A message from the client that verifies that it
knows the private key corresponding to its pub-
lic key certificate.
ChangeCipherSpec An indication to begin using agreed-upon secu-
rity services (such as encryption).
ClientHello A message from the client indicating the secu-
rity services it desiresand is capable of support-
ing.
ClientKeyExchange A message from the client carrying crypto-
graphic keys for the communications.
Finished An indication that all initial negotiationsare
complete and secure communications have
been established.
HelloRequest A request by the server that the client start (or
restart) the SSL negotiation process.
ServerHello A message from the server indicating the secu-
rity services that will be used for the communi-
cations.
ServerHelloDone An indication from the server that it has com-
pleted all its requests of the client for establish-
ing communications.
ServerKeyExchange A message from the server carrying crypto-
graphic keys for the communications.
3.3 Establishing Encrypted Communications

La fonction la plus élémentaire qu’un client et un serveur SSL
peuvent effectuer est d’établir un canal pour les communications
cryptées. La figure 3-1 illustre l’échange de messages SSL requis par
cette opération, et le tableau 3-2 résume les étapes de la figure. Cette
section examine ces étapes plus en détail en examinant chaque
message de l’échange.
SSLOperation 41
Client Server
1 ClientHello
ServerHello 2
ServerKeyExchange 3
ServerHelloDone 4
5 ClientKeyExchange
6 ChangeCipherSpec
7 Finished
ChangeCipherSpec 8
Finished 9
Figure 3-1 SSL uses 9 messages to establish encrypted communications.
Table 3-2 Negotiation of Encrypted Communications

Step Action
1 Client sendsClientHello message proposing SSL options.
2 Server responds with ServerHello message selecting the SSL
options.
3 Server sends its public key information in ServerKeyExchange
message.
4 Server concludes its part of the negotiation with ServerHello-
Done message.
5 Client sendssession key information (encrypted with server’s
public key) in ClientKeyExchange message.
6 Client sendsChangeCipherSpec message to activate the nego-
tiated options for all future messages it will send.
Web
Step Action
7 Client sends Finished message to let the server check the newly
activated options.
8 Server sendsChangeCipherSpec message to activate the nego-
9 Server sends Finished message to let the client check the newly
activated options.
3.3.1 ClientHello
Table 3-3 ClientHello Components
Le message ClientHello lance la communication SSL entre les deux
parties. Le client utilise ce message pour demander au serveur de
commencer à négocier les services de sécurité à l’aide de SSL. Le
tableau 3-3 répertorie les composants importants d’un message Client
Hello.
Field Use
Version Identifies the highest version of the SSL proto-
col that the client can support.
RandomNumber A 32-byte random number used to seed the
cryptographic calculations.
SessionID Identifiesaspecific SSLsession.
CipherSuites A list of cryptographic parameters that the cli-
ent can support.
CompressionMeth- Identifies data compression methods that the
ods client can support.
Le champ Version du message Client Hello contient le numéro de

version SSL le plus élevé que le client peut prendre en charge. La
version actuelle de SSL est 3.0, et c’est de loin la plus largement
déployée sur l’Inter-net. (Mais voir l’encadré pour plus
d’informations sur t l s.) Notez qu’un serveur peut supposer que le
client peut prendre en charge toutes les versions de SSL jusqu’à et y
compris la valeur de ce champ. Si, par exemple, un client envoie une
version 3.0 Client Hello à un serveur qui ne prend en charge que la
version 2.0 de SSL, le serveur peut répondre avec des messages de
version 2.0 qu’il attend du client qu’il comprend. Dans de tels cas,
ce client peut décider de poursuivre la session SSL à l’aide de la
fonctionnalité de la version 2.0.,
SSLOperation 43
ou il peut abandonner la tentative de communication. La section 5.1

comprend des informations supplémentaires sur la compatibilité avec
les versions précédentes.
Le champ RandomNumber, comme vous pouvez vous y attendre,
contient un nombre aléatoire. Cette valeur aléatoire, ainsi qu’une
valeur aléatoire similaire créée par le serveur, fournit la graine pour
les calculs cryptographiques critiques. Le chapitre 4 contient les
détails. La spécification ssl suggère que quatre des 32 octets de ce
champ sont constitués de l’heure et de la date. Le protocole ssl
n’exige pas un niveau particulier de précision pour cette valeur, car il
n’est pas destiné à fournir une indication précise de l’heure. Au lieu
de cela, la spécification suggère d’utiliser la date et l’heure comme
un moyen de s’assurer que le client n’utilise jamais la même valeur
aléatoire deux fois. Cette précaution protège contre un imposteur
copiant d’anciens messages SSL d’un client légitime et les réutilisant
pour établir une session contrefaite. Les 28 octets restants de cette
valeur doivent être un nombre aléatoire « cryptographiquement
sécurisé ». La sécurité n’est pas quelque chose que nous associons
habituellement au hasard, mais elle est importante dans ce cas. La
plupart des programmes informatiques utilisent une technique connue
sous le nom de génération de nombres pseudo-aléatoires pour créer
des nombres aléatoires. Lorsqu’elle est utilisée correctement, cette
approche donne des nombres qui ont l’apparence d’un caractère
aléatoire. Cependant, la technique présente un grave défaut
lorsqu’elle est utilisée dans un contexte de sécurité : si un attaquant
connaît l’algorithme exact et une valeur de random, cet attaquant
peut prédire correctement toutes les valeurs aléatoires futures. Cette
connaissance peut permettre à l’attaquant d’anticiper une valeur
future particulière et de préparer une attaque contre elle. Pour éviter
ce type d’attaque, les implémentations SSL doivent utiliser une
technique différente pour générer des nombres aléatoires ; En règle
générale, ils en utilisent un basé sur des algorithmes
cryptographiques.
Le champ suivant du message Client Hello est SessionID. Bien que tous les messages Client
Hello puissent inclure ce champ, dans cet exemple, le champ n’a pas de sens et serait vide.
La section 3.8 présente un exemple de la façon dont le champ SessionID peut être utilisé. Le
champ CipherSuites permet à un client de répertorier les différents services cryptographiques
qu’il peut prendre en charge, y compris les algorithmes exacts et les tailles de clé. Le serveur
prend en fait la décision finale quant aux services cryptographiques qui seront utilisés pour la
communication, mais il est
Web
limité à choisir dans cette liste. Le chapitre 4 décrit en détail le

format de ce champ, y compris les différents algorithmes et options
de taille de clé définis par ssl.
Le champ CompressionMethods est, en théorie, similaire au champ
Cipher-Suites. Dans celui-ci, le client peut énumérer toutes les
différentes méthodes de compréhension de données qu’il peut
prendre en charge. Les méthodes de compression sont une partie
importante de SSL parce que le cryptage a des conséquences
importantes sur l’efficacité de toutes les techniques de compression
de données. Encryption modifie les propriétés mathématiques de
l’information d’une manière qui rend la compression des données
pratiquement impossible. En fait, s’il était possible de compresser des
données cryptées, cela indiquerait probablement une faiblesse de
sécurité dans l’algorithme de cryptage. Pour cette raison, si deux
parties vont utiliser la compression de données pour une
communication, il est important qu’elles compressent leurs données
avant de les chiffrer. Le protocole SSL s’adapte à ce comportement
en incluant la capacité de compression des données et en s’assurant
que la compression se produit avant le chiffrement. Dans la version
actuelle de ssl, cependant, aucune méthode de compression active n’a
été définie. Ce champ est donc actuellement d’une utilité limitée. À
l’avenir, des méthodes de compression supplémentaires pourront être
définies et ajoutées aux spécifications t l s (mais pas ssl).
3.3.2 ServerHello
Lorsque le serveur reçoit le message Client Hello, il répond avec un

ServerHello. Comme le montre le tableau 3-4, le contenu d’un
ServerHello est sensiblement le même que celui d’un Client Hello. Il
existe cependant quelques différences importantes que nous
examinerons dans cette sous-section. En général, lorsque le client fait
des suggestions dans son message Client Hello, le serveur prend la
décision finale dans son ServerHello.
Table 3-4 ServerHello Components

Field Use
Version Identifies the version of the SSL protocol to be
used for this communication.
RandomNumber A 32-byte random number used to seed the
cryptographic calculations.
SSLOperation 45
Field Use
SessionID Identifies the specific SSLsession.
CipherSuite The cryptographic parameters to be used for this
communication.
Compression- The data compression method to be used for this
Method communication.
Le champ Version est le premier exemple d’un serveur prenant une SSL vs.TLS
décision finale pour les communications. La version de Client Hello Le protocole
identifie simplement les versions SSL que le client peut prendre en TLS utilise
charge. La version de ServerHello, d’autre part, détermine la version une valeur
SSL que la communication utilisera. Cependant, un serveur n’est pas de version
entièrement libre de choisir n’importe quelle version ssl; Il ne peut de 3.1 au
lieu de 3.0
pas choisir une version plus récente que la dernière que le client peut
prendre en charge. Si le client n’aime pas le choix du serveur, il peut
abandonner la communication. Au moment d’écrire ces lignes,
presque tous les clients et serveurs SSL prennent en charge la version
3.0 du protocole SSL.
Le champ RandomNumber de ServerHello est essentiellement le
même que dans Client Hello, bien que cette valeur aléatoire soit
choisie par le serveur. Avec la valeur du client, ce nombre entraîne
d’importants calculs cryptographiques. La valeur du serveur partage
les mêmes propriétés que dans Client Hello. Quatre des 32 octets
sont la date et l’heure (pour éviter de répéter des valeurs aléatoires);
Les octets restants doivent être créés par un générateur de nombres
aléatoires sécurisé par cryptographie. Le champ SessionID d’un
ServerHello peut contenir une valeur, contrairement au champ Client
Hello dont nous venons de parler. La valeur dans ce cas identifie de
manière unique cette communication ou session SSL particulière. La
principale raison d’identifier explicitement une session SSL
particulière est de s’y référer à nouveau plus tard. La section 3.8
montre un exemple de la façon dont un client peut utiliser cette
facilité pour accélérer le processus de négociation SSL. Si le serveur
n’a pas l’intention de réutiliser la session, il peut omettre le champ
SessionID de son message ServerHello.
Le champ CipherSuite (notez que le nom est singulier, et non pluriel,
comme dans le cas d’un client Hello) détermine les pa- ramètres
cryptographiques exacts, en particulier les algorithmes et les tailles
de clé, à utiliser pour la session. Le serveur doit sélectionner une
seule suite de chiffrement parmi celles répertoriées par le client dans
son message Client Hello.
Web
Le champ CompressionMethod est également singulier pour un

ServerHello. En théorie, le serveur utilise ce champ pour identifier
la compression de données à utiliser pour la session. Encore une
fois, le serveur doit choisir parmi ceux répertoriés dans le Client
Hello. Cependant, les versions actuelles de SSL n’ont défini
aucune méthode de compression, de sorte que ce champ n’a aucune
utilité pratique.
3.3.3 Server Key Exchange
Dans cet exemple, le serveur suit son message ServerHello avec un
message ServerKeyExchange. Ce message complète le champ
Cipher- Suite du serveur ServerHello. Alors que le champ
CipherSuite indique les algorithmes cryptographiques et les tailles de
clé, ce message contient les informations de clé publique elles-
mêmes. Le format exact de l’information clé dépend de l’algorithme
de clé publique utilisé. Pour l’algorithme rsa, par exemple, le serveur
inclut le module et l’exposant public de la clé publique rsa du
serveur.
Notez que le message ServerKeyExchange est transmis sans
cryptage, de sorte que seules les informations de clé publique
peuvent y être incluses en toute sécurité. Le client utilisera la clé
publique du serveur pour chiffrer une clé de session, que les parties
utiliseront pour chiffrer réellement les données d’application pour la
session.
3.3.4 Server HelloDone
Le message ServerHelloDone indique au client que le serveur a

terminé ses messages de négociation initiaux. Le message lui-même
ne contient aucune autre information, mais il est important pour le
client, car une fois que le client reçoit un ServerHelloDone, il peut
passer à la phase suivante de l’établissement des communications
sécurisées.
3.3.5 ClientKeyExchange
Lorsque le serveur a terminé sa partie de la négociation SSL initiale,

le client répond avec un message ClientKeyExchange. Tout comme
ServerKeyExchange fournit les informations de clé pour le serveur,
ClientKeyExchange indique au serveur les informations clés du
client.
SSLOperation 47
Dans ce cas, cependant, les informations clés concernent

l’algorithme de chiffrement symétrique que les deux parties
utiliseront pour la session. De plus, les informations contenues dans
le message du client sont chiffrées à l’aide de la clé publique du
serveur. Ce cryptage protège les informations de clé lors de la
traversée du réseau et permet au client de vérifier que le serveur
possède réellement la clé privée correspondant à sa clé publique.
Sinon, le serveur ne pourra pas déchiffrer ce message. Cette
opération est une protection importante contre un attaquant qui
intercepte des messages à partir d’un serveur légitime et prétend être
ce serveur en transférant les messages à un client sans méfiance.
Étant donné qu’un faux serveur ne connaîtra pas la clé privée du
serveur réel, il ne pourra pas décrypter le message
ClientKeyExchange. Sans les informations contenues dans ce
message, la communication entre les deux parties ne peut réussir.
3.3.6 ChangeCipherSpec
Une fois que le client a envoyé des informations clés dans un

message ClientKeyExchange, la négociation ssl préliminaire est
terminée. À ce stade, les parties sont prêtes à commencer à utiliser
les services de sécurité qu’elles ont négociés. Le protocole SSL
définit un message spécial (ChangeCipherSpec) pour indiquer
explicitement que les services de sécurité doivent maintenant être
appelés.
Étant donné que la transition vers une communication sécurisée est
essentielle et que les deux parties doivent faire exactement ce qu’il
faut, la spécification SSL est très précise dans la description du
processus. Tout d’abord, il identifie l’ensemble des informations qui
définissent les services de sécurité. Ces informations comprennent un
algorithme de cryptage symétrique spécifique, un algorithme
d’intégrité de message spécifique et des clés spécifiques pour ces
algorithmes. La spécification SSL reconnaît également que certaines
de ces informations (en particulier, le matériel clé) seront différentes
pour chaque direction de communication. En d’autres termes, un jeu
de clés sécurisera les données que le client envoie au serveur, et un
autre jeu de clés sécurisera les données que le serveur envoie au
client. (En principe, les algorithmes réels pourraient également
différer, mais ssl ne définit pas un moyen de négocier une telle
option.) Pour un système donné, qu’il s’agisse d’un client ou d’un
serveur, ssl définit un état d’écriture et un état de lecture. L’état
d’écriture définit les informations de sécurité
Web
pour les données envoyées par le système, et l’état de lecture définit

les informations de sécurité pour les données que le système reçoit.
Le message ChangeCipherSpec sert de repère pour qu’un système
commence à utiliser ses informations de sécurité. Avant qu’un client
ou un serveur envoie un message ChangeCipherSpec, il doit
connaître les informations de sécurité complètes qu’il est sur le point
d’activer. Dès que le système envoie ce message, il active son état
d’écriture. De même, dès qu’un système
Client
Write Read 1 ClientHello

Act Pnd Act Pnd
Encr null ? null ?
MAC null ? null ?
key null ? null ?
Write Read ServerHello 2

Act Pnd Act Pnd
Encr null DES null DES
ServerKeyExchange 3
MAC null MD5 null MD5
key null ? null ?
ServerHelloDone 4
Write Read 5 ClientKeyExchange

Act Pnd Act Pnd
key null xxx null xxx
Write Read 6 ChangeCipherSpec

Act Pnd Act Pnd
Encr DES ? null DES
7 Finished
MAC MD5 ? null MD5
key xxx ? null xxx
Write Read ChangeCipherSpec 8

Act Pnd Act Pnd
Encr DES ? DES ?
Finished 9
MAC MD5 ? MD5 ?
key xxx ? xxx ?
Figure 3-2 Clients build pending cipher suites while using active ones.
SSLOperation 49
reçoit un ChangeCipherSpec de son homologue, le système active

son état de lecture. Les figures 3-2 et 3-3 illustrent ce processus plus
en détail. Le premier montre comment le client voit le processus,
tandis que le second prend la perspective du serveur. Dans les deux
figures, les matrices sur le côté montrent les états de lecture et
d’écriture des systèmes. Les événements affichés en noir (par
opposition au gris) entraînent la mise à jour des états des systèmes.
Comme l’indiquent les figures, ssl définit en fait deux états de lecture
et d’écriture distincts pour chaque système.
Server
1 ClientHello Write Read
Act Pnd Act Pnd
Encr null ? null ?
MAC null ? null ?
key null ? null ?
ServerHello 2 Write Read

Act Pnd Act Pnd
ServerKeyExchange 3
key null ? null ?
ServerHelloDone 4
5 ClientKeyExchange Write Read

Act Pnd Act Pnd
6 ChangeCipherSpec Write Read

Act Pnd Act Pnd
7 Finished
ChangeCipherSpec 8 Write Read

Act Pnd Act Pnd
Encr DES ? DES ?
Finished 9
MAC MD5 ? MD5 ?
key xxx ? xxx ?
Figure 3-3 SSL serversalso build pending cipher suites.

Web
L’un des États est actif et le second est en attente. Par conséquent, le
client et le serveur conservent un total de quatre états différents :
l’état d’écriture actif, l’état d’écriture en attente, l’état de lecture actif
et l’état de lecture en attente. (Les chiffres utilisent les abréviations «
Act » et « Pnd » pour actif et en attente, respectivement.)
Les figures montrent également les éléments clés d’un État. Il s’agit
de l’algorithme d’encryption (abrégé « Encr »), de l’algorithme
d’intégrité du message (abrégé « mac » pour Message Authentication
Code) et du matériel clé. Dans les figures 3-2 et 3-3, les systèmes
conviennent d’utiliser la norme de cryptage des données (des) pour le
chiffrement symétrique et le Mes- sage Digest 5 (md5) pour
l’intégrité des messages.
Comme le montrent les chiffres, tous les systèmes démarrent dans
des états actifs sans aucun service de sécurité. Cette condition initiale
est nécessaire pour que les systèmes puissent commencer toute
communication ; Tant qu’ils n’ont pas négocié les services et les
paramètres de sécurité, une communication sécurisée n’est pas
possible. Au fur et à mesure que les systèmes échangent des
messages SSL, ils commencent à construire l’état pending. Ils
s’accordent d’abord sur le cryptage et l’intégrité des messages, puis
ils échangent des informations clés. Ce n’est qu’alors, lorsque le
client et le serveur ont des états en attente complets, que les systèmes
peuvent adapter ces états en attente avec des messages
ChangeCipherSpec. Le tableau 3-5 détaille le traitement des clients
illustré par la figure 3-2. Il décrit les étapes de la figure qui sont
montrées en noir uni ; Ce sont les étapes qui entraînent un
changement des états du client.
Table 3-5 Client State Processing

Step Description
1 When the client initiatesan SSLcommunication by sending a
ClientHello message, it sets both of itsactive states to null (no
security); initially, its pending statesare unknown.
2 When the client receivesaServerHello message, it knows the
algorithms that the server hasselected for the session.It up-
dates both of its pending statesaccordingly. Key information
for the pending states isstill unknown at this point.
5 Once the client has built and transmitted a ClientKeyExchange
message, it knows the key material that will be used for the
communication,so it updates the pending states.
SSLOperation 51
6 When the client sendsa ChangeCipherSpec message, it moves

its pending write state to the active write state and resets the
pending state to unknown.No changesare made to the read
states.From this point on,all data the client sends will use DES
encryption and MD5 authentication as indicated by the now ac-
tive write state.
8 When the client receivesa ChangeCipherSpec, it updates the
active read state with the pending valuesand resets the pend-
ing read state to unknown.From this point on, the client will
expect received data to be secured with DESencryption and
MD5 authentication.
Table 3-6 Server State Processing

Le tableau 3-6 décrit le traitement qui a lieu sur le serveur. Il correspond à la figure 3-3.
Step Description
1 When the server first receivesa ClientHello message, it sets
both of itsactive states to null; its pending statesare unknown.
2 When the server sends itsServerHello message, it knows the
algorithms that will be used for the session,and it updates both
of its pending statesaccordingly.Key information for the pend-
ing states isstill unknown at this point.
5 Once the server has received a ClientKeyExchange message, it
knows the key material that will be used for the communica-
tion,so it updates the pending statesappropriately.
6 When the server receivesa ChangeCipherSpec message, it
moves its pending read state to the active read state and resets
the pending state to unknown.No changesare made to the
write states.From this point on, the server will expect received
data to be secured with DESencryption and MD5 authentication.
8 When the server sends its own ChangeCipherSpec, it updates
the active write state with the pending valuesand resets the
pending state to unknown.From this point on,all data the
server sends will use DESencryption and MD5 authentication as
indicated by the now active write state.
Notez dans les figures que l’état d’écriture actif d’un système est le
même que l’état de lecture actif de l’autre système, à une exception
près. L’exception se produit lors de la transmission d’un
ChangeCipherSpec
Web
message. Dès qu’un système envoie ce message, il met à jour ses

états actifs. L’autre système, cependant, ne modifie pas ses états
actifs tant qu’il n’a pas reçu le message. Dans l’intervalle, les deux
systèmes sont temporairement désynchronisés.
3.3.7 Finished
Immédiatement après l’envoi de leurs messages ChangeCipherSpec,
chaque système envoie également un message Terminé. Les
messages Terminé permettent aux deux systèmes de vérifier que la
négociation a réussi et que la sécurité n’a pas été compromise. Deux
aspects du message Terminé contribuent à cette sécurité. Tout
d’abord, comme l’expliquait la sous-section précédente, le message
Terminé lui-même est soumis à la suite civique négociée. Cela
signifie qu’il est crypté et authentifié conformément à cette suite. Si
la partie réceptrice ne peut pas déchiffrer et vérifier le message, il est
clair que quelque chose a mal tourné avec la négociation de sécurité.
Le contenu du message Terminé sert également à protéger la sécurité
de la négociation ssl. Chaque message terminé contient un hachage
cryptographique d’informations importantes sur la négociation qui
vient de se terminer. Le tableau 3-7 détaille les informations
sécurisées par le hachage. Notez que les données protégées incluent
le contenu exact de tous les messages d’établissement de liaison
utilisés dans l’échange (bien que les messages ChangeCipher-Spec
ne soient pas considérés comme des messages de « handshake » au
sens strict du terme, et ne sont donc pas inclus). Cela protège contre
un attaquant qui parvient à insérer des messages fictifs ou à
supprimer des messages légitimes de la communication. Si un
attaquant était en mesure de le faire, les calculs de hachage du client
et du serveur ne correspondraient pas et ils détecteraient la
compromission. Le chapitre 4 décrit les détails du calcul du hachage.
Table 3-7 Information Authenticated by Finished Message
• Key information
• Contents of all previous SSL handshake messages exchanged by
the systems
• A special value indicating whether the sender isa client or server
SSLOperation 53
3.4 Ending Secure Communications

Bien que, dans la pratique, il soit rarement utilisé (principalement en
raison de la nature des sessions Web), SSL dispose d’une procédure
définie pour mettre fin à une communication sécurisée entre deux
parties. Comme le montre la figure 3-4, les deux systèmes envoient
chacun une alerte de fermeture spéciale à l’autre. La fermeture
explicite d’une session protège contre une attaque par troncation,
dans laquelle un attaquant est capable de compromettre la sécurité en
terminant prématurément une communication. Imaginez, par
exemple, qu’un attaquant soit capable de supprimer seulement la
deuxième phrase de la phrase suivante : « Veuillez détruire tous les
documents, à moins que vous n’ayez de mes nouvelles demain. » Le
message ClosureAlert aide les systèmes à détecter de telles attaques.
Si un système recevait le message « Veuillez détruire tous les
documents » mais n’avait pas reçu d’alerte de fermeture, il
reconnaîtrait que le message complet n’est peut-être pas arrivé.
Comme mentionné, il n’est pas toujours possible de recevoir des
messages ClosureAlert de manière fiable pour les transactions Web.
L’annexe b décrit les autres mesures que les serveurs Web et les
clients peuvent prendre pour se protéger contre ces attaques par
troncature. ********
3.5 Authenticating the Server’s Identity

Bien que la section 3.4 ait expliqué comment SSL peut établir des
communications cryptées entre deux parties, cela peut ne pas
vraiment ajouter beaucoup de sécurité à la communication. Avec le
cryptage seul non plus
Client Server
ClosureAlert
ClosureAlert
Figure 3-4 ClosureAlert messages indicate the end of asecure session.

Web
Le parti peut vraiment être sûr de l’identité de l’autre. La raison

typique de l’utilisation du cryptage en premier lieu est de garder les
informations secrètes d’un tiers. Mais si ce tiers était capable de se
faire passer pour le destinataire prévu de l’information, alors
l’encryption ne servirait à rien. Les données seraient chiffrées, mais
l’attaquant aurait toutes les données nécessaires pour les déchiffrer.
Pour éviter ce type d’attaque, SSL inclut des mécanismes qui
permettent à chaque partie d’authentifier l’identité de l’autre. Avec
ces mécanismes, chaque partie peut être sûre que l’autre est
authentique, et non un attaquant déguisé. Dans cette section, nous
verrons comment SSL permet à un serveur de s’authentifier.
Une question naturelle est, bien sûr, si l’authentification des identités
est si importante, pourquoi ne pas toujours authentifier les deux
parties? La réponse réside dans la nature du commerce Web. Lorsque
vous souhaitez acheter quelque chose à l’aide de votre navigateur
Web, il est très important que le site Web que vous naviguez soit
authentique. Vous ne voudriez pas envoyer votre numéro de carte de
crédit à un imposteur se faisant passer pour votre mer- chant préféré.
Le commerçant, quant à lui, dispose d’autres moyens pour
authentifier votre identité. Une fois qu’il reçoit un numéro de carte de
crédit, par exemple, il peut valider ce numéro. Étant donné que le
serveur n’a pas besoin de ssl pour authentifier votre identité, le
protocole ssl autorise uniquement l’authentification du serveur. (Le
protocole définit un processus d’authentification des clients. La
section 3.7 traite de ce processus.)
Le tableau 3-8 récapitule les actions effectuées par chaque système
pour authentifier un serveur. Les mêmes étapes sont illustrées
graphiquement à la figure 3-5. Le processus n’est pas si différent du
simple cryptage. (Comparez la figure 3-5 avec la figure 3-1.) Les
deux messages en noir sont différents lors de l’authentification d’un
serveur. Ces messages, le message Certificate et le message
ClientKeyExchange, sont abordés ci-après. Tous les autres
paramètres sont les mêmes que ceux décrits à la section 3.3.
Table 3-8 Authenticating a Server

Step Action
2 Server responds with ServerHello selecting the SSL options.
SSLOperation 55
Step Action
3 Server sends its public key certificate in Certificate message.
Done message.
5 Client sendssession key information (encrypted with server ’s
public key) in ClientKeyExchange message.
activated options.
activated options.
Client Server
1 ClientHello
ServerHello 2
Certificate 3
ServerHelloDone 4
5 ClientKeyExchange
6 ChangeCipherSpec
7 Finished
ChangeCipherSpec 8
Finished 9
Figure 3-5 Two SSL messages authenticate aserver's identity.

Web
3.5.1 Certificate
Lors de l’authentification de son identité, le serveur envoie un
message de certificat au lieu du message ServerKeyExchange section
3.3.3 décrit. Le message Certificate contient simplement une chaîne
de certificats qui commence par le certificat de clé publique du
serveur et se termine par le certificat racine de l’autorité de
certification.
Le client a la responsabilité de s’assurer qu’il peut faire confiance au
certificat qu’il reçoit du serveur. Cette responsabilité comprend la
vérification des signatures de certificat, des durées de validité et de
l’état de révocation. Cela signifie également s’assurer que l’autorité
de certification est une autorité de confiance du client. En règle
générale, les clients effectuent cette détermination en connaissant la
clé publique des autorités de certification approuvées à l’avance, par
des moyens fiables. Netscape et Microsoft, par exemple, préchargent
leur logiciel de navigation avec des clés publiques pour des
autorisations de certificats bien connues. Les serveurs Web qui
souhaitent s’appuyer sur ce mécanisme de confiance ne peuvent
obtenir leurs certificats (au moins indirectement) qu’auprès de l’une
de ces autorités bien connues.
Un détail supplémentaire dans le processus de vérification du
certificat peut parfois sembler subtil, mais il est néanmoins crucial
pour une sécurité réelle : le client doit s’assurer non seulement que le
certificat est délivré par une autorité de confiance, mais que le
certificat identifie également sans ambiguïté la partie avec laquelle il
souhaite communiquer. Prenons, par exemple, une entreprise
malveillante qui reçoit un certificat légitime d’une autorité de
certification de confiance sous son propre nom, mais qui se retourne
ensuite et utilise ce certificat de manière illégitime pour se faire
passer pour un concurrent. Le client sans méfiance qui communique
avec cette société malveillante (croyant qu’elle communique avec le
concurrent) recevra un certificat légitime dans le cadre de l’échange SSL.
Le client, cependant, doit être suffisamment intelligent pour détecter que
le certificat n’appartient pas au concurrent réel. Pour le commerce Web,
la clé pour résoudre ce problème repose normalement sur le nom de
domaine du serveur. Les autorités de certification respectées incluent le
nom de domaine Internet du serveur Web dans les certificats qu’elles
émettent. Et les navigateurs Web vérifient le nom de domaine dans les
certificats qu’ils reçoivent par rapport au nom de domaine que leurs
utilisateurs tentent de contacter.
SSLOperation 57
Si, par exemple, un navigateur tente de se connecter à

www.goodcompany.com et reçoit un certificat pour
www.badcompany.com, le navigateur sait que quelque chose ne va
pas, quelle que soit la validité du certificat. L’annexe b contient des
renseignements supplémentaires sur la vérification du certificat.
3.5.2 Client KeyExchange

Le message ClientKeyExchange du client diffère également dans l’authentification du
serveur, bien que la différence ne soit pas majeure. Lorsque le chiffrement doit uniquement
être utilisé, le client chiffre les informations dans le Client-KeyExchange à l’aide de la clé
publique fournie par le serveur dans son message ServerKeyExchange. Dans ce cas, bien sûr,
le serveur s’auto-valide et a donc envoyé un message de certificat au lieu d’un
ServerKeyExchange. Par conséquent, le client chiffre ses informations Client-KeyExchange
à l’aide de la clé publique contenue dans le certificat du serveur. Cette étape est importante
car elle permet au client de s’assurer que la partie avec laquelle il communique possède
réellement la clé privée du serveur. Seul un système avec la clé principale réelle sera capable
de décrypter ce message et de poursuivre avec succès la communication.
3.6 Separating Encryption from Authentication

La section précédente expliquait comment un serveur peut envoyer
un message de certificat au lieu d’un message ServerKeyExchange
pour s’authentifier lui-même. L’une des conséquences de cette
approche est que les mêmes informations de clé publique utilisées
pour vérifier l’identité du serveur sont également utilisées pour
chiffrer les éléments de clé dans le message ClientKeyExchange du
client. Cette contrainte n’est pas toujours souhaitable ; En effet, dans
certains cas, il est même impossible de le soutenir.
Les cas impossibles sont les plus faciles à décrire. Certains
algorithmes à clé publique (tels que l’algorithme de signature
numérique) ne peuvent être utilisés que pour la signature. De par leur
conception même, ils ne peuvent pas être utilisés pour le cryptage.
Dans de tels cas, il sera impossible pour le client de chiffrer ses
informations Cli- entKeyExchange à l’aide de la clé publique du
serveur.
Web
Cette limitation à elle seule serait suffisante pour exiger une plus grande
flexibilité du protocole SSL, mais il est utile de comprendre pourquoi la
combinaison de la signature et du cryptage peut ne pas être souhaitable,
même lorsque l’algorithme de clé publique prend en charge les deux
opérations. La raison la plus courante pour séparer le cryptage de la
signature n’est pas basée sur des considérations techniques, mais sur des
considérations juridiques. Certains pays, y compris les producteurs
importants de produits cryptographiques tels que les États-Unis (du moins
au moment de la rédaction du présent rapport), contrôlent l’utilisation ou
l’exportation de produits qui incluent la cryptographie. En particulier, les
États-Unis font en sorte qu’il est plus difficile pour les fournisseurs
d’exporter des produits cryptographiques qui utilisent des longueurs de clé
de chiffrement supérieures à un certain minimum. (Les longueurs de clé
inférieures ou égales à ces limites sont dites
Client Server
1 ClientHello
ServerHello 2
Certificate 3
ServerKeyExchange 4
ServerHelloDone 5
6 ClientKeyExchange
7 ChangeCipherSpec
8 Finished
ChangeCipherSpec 9
Finished 10
Figure 3-6 Three SSL messages isolate authentication from encryption.

SSLOperation 59
être exportable.) En principe, au moins, les États-Unis n’imposent

pas les mêmes restrictions sur les clés utilisées pour les signatures
numériques. Les systèmes qui relèvent de la juridiction américaine
peuvent donc préférer utiliser les clés pratiques les plus longues pour
authentifier leur identité (fournissant ainsi l’authentification pratique
la plus forte), mais utiliser des clés de chiffrement conformes aux
restrictions d’exportation plus faibles.
Quelle que soit la raison, SSL fournit un mécanisme pour séparer
l’authentification du serveur du cryptage. Le tableau 3-9 décrit les
étapes à suivre et la figure 3-6 illustre l’ensemble du processus. La
figure met en évidence les trois messages qui sont significatifs pour
séparer l’authentification de l’encryption et du serveur. Il s’agit des
messages Certificate, ServerKeyExchange et ClientKeyExchange.
Table 3-9 Separating Server Authentication from Encryption

Step Action
2 Server responds with ServerHello message selecting the SSL
options.
4 Server sends the public key that the client should use to en-
crypt the symmetric key information in aServerKeyExchange;
this public key issigned with the public key in the server ’s cer-
tificate.
Done message.
6 Client sendssession key information (encrypted with the public
key provided by the server) in a ClientKeyExchange message.
activated options.
activated options.
Web
3.6.1 Certificate
Le message Certificate de cet exemple est identique à celui de la section
3.5, sauf que la clé publique du certificat du serveur ne sera utilisée que
pour vérifier son identité. Cependant, le client a toujours toutes les
responsabilités discutées à la section 3.5.1. Il doit vérifier les signatures,
les durées de validité et l’état de révocation du certificat, et il doit
s’assurer que l’autorité de certification est digne de confiance et que le
certificat a été transmis à la partie avec laquelle il souhaite
communiquer.
3.6.2 ServerKeyExchange
Le serveur suit son message de certificat avec un message
ServerKeyExchange. C’est ce deuxième message qui contient la clé
publique que le client doit utiliser pour chiffrer les informations de clé
de session. Le ServerKeyExchange est le même message que celui que
nous avons vu lorsqu’aucune authentification n’était impliquée, et les
informations contenues dans le message sont les mêmes que celles
décrites dans la section 3.3.3, avec une différence significative :
contrairement à l’exemple de la section 3.3, dans lequel les clés de
serveur ont été envoyées par elles-mêmes, dans ce scénario, les
informations de clé sont signées à l’aide de la clé publique contenue
dans le certificat du serveur. Cette étape est essentielle pour donner au
client un moyen de vérifier que le serveur possède bien la clé privée
correspondant à son certificat de clé publique.
3.6.3 ClientKeyExchange
Le client utilise un message ClientKeyExchange pour terminer le
processus de négociation, comme il le fait dans d’autres scénarios.
Comme précédemment, ce message contient les informations clés de
l’algorithme de chiffrement symétrique sélectionné par les deux parties.
Comme précédemment, ces informations sont cryptées à l’aide de la clé
publique du serveur. Il est important de noter que la clé publique
utilisée pour ce chiffrement est la clé publique du message
ServerKeyExchange, et non la clé publique du message de certificat du
serveur (même si cet algorithme de clé publique prend en charge en-
cryption).
SSLOperation 61
3.7 Authenticating the Client ’s Identity
Étant donné que SSL inclut des mécanismes pour authentifier

l’identité d’un serveur, il est naturel de s’attendre à ce que le
protocole définisse également un moyen d’authentifier l’identité d’un
client. En effet, c’est le cas ; Le mécanisme est très similaire à celui
de l’authentification du serveur. Vous pouvez voir l’ensemble du
processus dans la figure 3-7, qui met en évidence les messages qui
sont significativement différents des flux de messages que nous
avons pris en compte jusqu’à présent. Ces messages sont
CertificateRequest, le message Certificate du client et
CertificateVerify. Le tableau 3-10 met en évidence le rôle de ces
messages en résumant l’ensemble du flux de messages. Le reste de
cette section les décrit plus en détail.
Table 3-10 Client Authentication
Step Action
2 Server responds with ServerHello selecting the SSL options.
4 Server sendsa CertificateRequest message to indicate that it
wants to authenticate the client.
Done message.
6 Client sends its public key certificate in a Certificate message.
7 Client sendssession key information (encrypted with the
server’s public key) in a ClientKeyExchange message.
8 Client sendsa CertificateVerify message, which signs importa-
tion information about the session using the client ’s private
key; the server uses the public key from the client ’s certificate
to verify the client ’s identity.
9 Client sendsa ChangeCipherSpec message to activate the ne-
gotiated options for all future messages it will send.
10 Client sendsa Finished message to let the server check the
newly activated options.
11 Server sendsa ChangeCipherSpec message to activate the ne-
12 Server sendsa Finished message to let the client check the
newly activated options.
Web
3.7.1 CertificateRequest
Dans tout échange SSL, le serveur détermine si l’authentification du
client est requise. Le client n’a pas le choix ; Il répond simplement
aux souhaits du serveur. Si le serveur requiert l’authentification du
client, il l’indique en envoyant un message CertificateRequest dans le
cadre de sa négociation hello.
Comme l’indique la figure 3-7, le serveur envoie CertificateRequest
après son propre message de certificat. Bien qu’il ne soit pas
représenté dans la figure,
Client Server
1 ClientHello
ServerHello 2
Certificate 3
CertificateRequest 4
ServerHelloDone 5
6 Certificate
7 ClientKeyExchange
8 CertificateVerify
9 ChangeCipherSpec
10 Finished
ChangeCipherSpec 11
Finished 12
Figure 3-7 Three SSL messages authenticate a client's identity.

SSLOperation 63
Le CertificateRequest suivrait également tous les messages

ServerKeyExchange envoyés par le serveur. Notez toutefois que la
spécification SSL interdit à un serveur d’envoyer un
CertificateRequest s’il ne s’authentifie pas également (en envoyant
un message de certificat). Cette restriction garantit que le client
connaîtra l’identité du serveur avant de révéler la sienne.
Le message CertificateRequest contient deux champs : une liste de
types de certificats et une liste de noms distinctifs, comme l’indique
le tableau 3-11.
Table 3-11 CertificateRequest Components
Field Use
CertificateTypes A list of certificate typesacceptable to the
server.
Distinguished- A list of distinguished names of certificate au-
Names thorities acceptable to the server.
Le champ CertificateTypes répertorie les différents types de

certificats (différenciés par l’algorithme de signature particulier
utilisé) que le serveur acceptera. Les types de certificats sont
répertoriés par ordre décroissant de préférence. Le champ
DistinguishedNames identifie les autorités de certification (désignées
par leur nom distinctif ; voir annexe a) que le serveur acceptera.
Aucune préférence n’est implicite par l’ordre dans lequel les
différentes autorités apparaissent dans cette liste.
3.7.2 Certificate
Un client répond normalement à la demande de certificat en

envoyant son propre message de certificat immédiatement après
avoir reçu le ServerHelloDone. Le format du message de certificat du
client est identique au message de certificat du serveur dont la
section 3.5.1 a parlé ; Les deux contiennent une chaîne de certificats
commençant par le certificat du système local et se terminant par le
certificat racine de l’autorité de certification. Si un client ne possède
pas de certificat qui répond aux critères du serveur (ou s’il n’a pas de
certificat du tout), il répond avec un NoCertificateAlert. Le serveur
peut choisir d’ignorer cette alerte et de poursuivre la communication
(bien qu’il ne puisse pas vérifier l’identité du client), ou il peut
mettre fin à la session à ce stade.
Web
Notez que ssl utilise uniquement la clé publique du client pour les
signatures numériques. Contrairement à la clé publique du serveur, il
n’existe aucune fonction de protocole qui utilise la clé publique du
client pour le chiffrement. Il n’est donc pas nécessaire de séparer
explicitement l’authentification du client du cryptage, de sorte que ssl
n’a pas d’équivalent client pour le message ServerKeyExchange. (Le
ClientKeyExchange, comme nous l’avons vu, transfère des
informations de clé symétrique, pas des informations de clé
publique.)
3.7.3 CertificateVerify
Le simple fait d’envoyer un message de certificat client ne termine
pas le processus d’authentification de l’identité du client. Le client
doit également prouver qu’il possède la clé privée correspondant à la
clé publique du certifié. Pour sa preuve, le client utilise un message
CertificateVerify. Ce message contient un hachage cryptographique
signé numériquement d’informations disponibles pour le client et le
serveur. Plus précisément, le client signe un hachage des listes de la
table d’informations 3 à 12. Le serveur dispose également de ces
informations, et il recevra (dans le message de certificat) la clé
publique du client. Le serveur peut alors vérifier la signature et
s’assurer que le client possède la clé privée appropriée.
Table 3-12 Information Authenticated by CertificateVerify Message
• Key information.
• Contents of all previous SSL handshake messages exchanged by
the systems.
En regardant la figure 3-7, vous vous demandez peut-être pourquoi le

message Certificat- eVerify ne suit pas immédiatement le message de
certificat. Au lieu de cet ordre apparemment naturel, ssl demande au
client d’envoyer un message Cli- entKeyExchange entre les deux. La
raison de cet ordre message est basée sur le contenu
cryptographique des messages. Le message CertificateVerify repose
sur des valeurs de chiffrement calculées et transférées au serveur
dans ClientKeyExchange. Tant que le serveur n’a pas reçu
ClientKeyExchange, il ne peut pas valider le message
CertificateVerify. (Le chapitre 4 contient une discussion plus
détaillée des calculs spécifiques utilisés par chaque partie.)
SSLOperation 65
3.8 Resuming a Previous Session
Comme ce chapitre l’a démontré, l’établissement d’une session SSL

peut être complexe, nécessitant des calculs cryptographiques
sophistiqués et un nombre important de messages de protocole. Pour
minimiser la surcharge de ces calculs et messages, ssl définit un
mécanisme par lequel deux parties peuvent réutiliser des paramètres
ssl précédemment négociés. Avec cette méthode, les parties n’ont pas
besoin de répéter les négociations cryptographiques ou les calculs
d’authentification ; Ils continuent simplement là où ils se sont arrêtés
auparavant. Comme le montrent les tableaux 3-13 et 3-8, la reprise
des sessions antérieures simplifie considérablement les négociations.
Table 3-13 Resuming a Session
Step Action
1 Client sendsClientHello message specifying a previously estab-
lished SessionID.
2 Server responds with ServerHello message agreeing to this
SessionID.
Client Server
1 ClientHello
ServerHello 2
ChangeCipherSpec 3
Finished 4
5 ChangeCipherSpec
6 Finished
Figure 3-8 It only takessix messages to resume an SSLsession.

Web
Step Action
3 Server sendsChangeCipherSpec message to reactivate the ses-
sion’ssecurity options for messages it will send.
reactivated options.
5 Client sendsChangeCipherSpec message to reactivate the ne-
reactivated options.
Comme l’indique la figure, une fois que le serveur lui a envoyé le

message ServerHello, il envoie immédiatement les messages
ChangeCipherSpec et Finished. De même, le client envoie
uniquement les messages ChangeCipherSpec et Finished une fois
qu’il reçoit ServerHello. Dans les deux cas, ChangeCipherSpec
demande à chaque partie de rendre la suite de chiffrement
précédemment active une fois de plus.
La clé de la reprise de session est le message Client Hello. Le client
propose de reprendre une session précédente en incluant la valeur
Ses- sionID de cette session dans son Bonjour Client. (Rappelez-vous
de la discussion dans la section 3.3.1 que cette valeur est laissée vide
lorsqu’une session SSL est établie pour la première fois; le serveur
peut fournir une valeur dans sa réponse ServerHello.) Si le serveur
souhaite accepter la proposition du client et reprendre la session
précédente, il indique son acceptation en incluant la même valeur
SessionID dans son propre ServerHello. Si le serveur choisit de ne
pas reprendre la session précédente, il envoie une valeur SessionID
différente et la négociation complète a alors lieu.
Bien que la reprise de session offre beaucoup de commodité et
d’efficacité aux systèmes qui l’utilisent, ces systèmes doivent faire
preuve d’une certaine prudence dans son utilisation. Lorsqu’une
seule clé est utilisée, l’enregistrement devient inévitablement moins
sûr, à la fois parce que plus d’informations sont protégées et que le
temps passe. Les attaquants potentiels obtiennent plus de données à
analyser et plus de temps pour effectuer l’analyse. Les systèmes qui
envisagent d’utiliser la reprise de session SSL doivent peser ces
considérations par rapport aux gains d’efficacité et de commodité
attendus.

SSL & TLS Essentials Partie 1 - Partie1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSL & TLS Essentials Partie 1 - Partie1

Uploaded by

Copyright:

Available Formats

3

SSL and TLS

1.1 Web Security and Electronic Commerce 2

2.1 Using Cryptography 18

Chapter 3:SSL Operation 37

3.1 SSL Roles 37

Chapter 4:Message Formats 67

4.1 Transport Requirements 68

Chapter 5:Advanced SSL 105

5.1 Compatibility with Previous Versions 105

5.4.7 Baseline Cipher Suites 126

Appendix A:X.509 Certificates 131

A.1 X.509 Certificate Overview 132

B.1 Authentication Issues 161

Protocol Standards 175

Rien qu’aujourd’hui, Dell Computer vendra pour plus de 18 millions

1.1 Web Security and ElectronicCommerce

Connaissez l’ennemi. Sun Tzu n’aurait pas pu offrir de conseils plus

Step IPAddress System Name (if known)

Web Server Web Browser

Figure 1-1 Messages travel complex paths through the Internet.

comme message dans une bouteille. L’utilisateur n’a aucun contrôle

1.2 History of SSL and TLS History

TLSWG TLS 1.0

1993 1994 1995 1996 1997 1998 1999

Pour éviter l’apparence de partialité envers une entreprise en SSL vs.TLS

1.3 Approaches to Network Security

Figure 1-3 Web browsers such as Internet Explorer include SSL.

Table 1-2 Different Approaches to Network Security

1.3.1 Separate Security Protocol

Figure 1-4 SSL is aseparate protocol layer just for security.

HTTP NNTP FTP

est également utilisé pour renforcer la sécurité d’autres applications

Not Secure Secure

Figure 1-6 Security can be added directly within an application protocol.

, et quelques produits le prennent en charge. Cependant, il n’a jamais

L’un des inconvénients de l’ajout de sécurité à une application

1.3.3 Security within Core Protocols

Not Secure Secure

Figure 1-7 IPSEC adds security to a core network protocol.

profiter d’IPSec. En fait, il peut même être complètement ignorant

1.3.4 Parallel Security Protocol

Not Secure Secure

HTTP HTTP Kerberos

TCP TCP and UDP

Figure 1-8 Kerberos supplements application protocols.

Dans ces applications, Kerberos fournit un

1.4 Protocol Limitations

1.4.1 Fundamental Protocol Limitations

Par exemple, ssl nécessite un protocole de transport fiable tel que

1.4.2 Tool Limitations

1.4.3 Environmental Limitations

1.5 Organization of This Book

Quatre autres chapitres et deux annexes composent le reste de ce

examine ces principes essentiels. Le chapitre 3 commence

L’annexe A fourni des détails supplémentaires sur les certificats de clé

Le Web est peut-être un moyen relativement nouveau de

2.1 Using Cryptography

Le mot cryptographie est dérivé du grec pour « écriture secrète ». La

2.1.1 Keeping Secrets

Pour continuer avec une convention qui est devenue presque

Figure 2-1 Cryptography can protect information from eavesdroppers.