1
<?xml version="1.0" encoding="ISO-8859-1"?>
2
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
4
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
5
This file is generated from xml source: DO NOT EDIT
6
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
8
<title>SSL/TLS Strong Encryption: An Introduction - Apache HTTP Server</title>
9
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
10
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
11
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
12
<link href="../images/favicon.ico" rel="shortcut icon" /></head>
13
<body id="manual-page"><div id="page-header">
14
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p>
15
<p class="apache">Apache HTTP Server Version 2.2</p>
16
<img alt="" src="../images/feather.gif" /></div>
17
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
19
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.2</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS Strong Encryption: An Introduction</h1>
21
<p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" title="English"> en </a> |
22
<a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p>
26
<p>The nice thing about standards is that there are so many to choose
27
from. And if you really don't like all the standards you just have to
28
wait another year until the one arises you are looking for.</p>
30
<p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
31
Computer Networks"</p>
34
<p>As an introduction this chapter is aimed at readers who are familiar
35
with the Web, HTTP, and Apache, but are not security experts. It is not
36
intended to be a definitive guide to the SSL protocol, nor does it discuss
37
specific techniques for managing certificates in an organization, or the
38
important legal issues of patents and import and export restrictions.
39
Rather, it is intended to provide a common background to <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> users by pulling together various concepts, definitions,
40
and examples as a starting point for further exploration.</p>
42
<p>The presented content is mainly derived, with the author's permission,
43
from the article <a href="http://home.comcast.net/~fjhirsch/Papers/wwwj/">Introducing
44
SSL and Certificates using SSLeay</a> by <a href="http://home.comcast.net/~fjhirsch/">Frederick J. Hirsch</a>, of The
45
Open Group Research Institute, which was published in <a href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
46
Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
47
Please send any positive feedback to <a href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> (the original
48
article author) and all negative feedback to <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the
49
<code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> author).</p>
51
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cryptographictech">Cryptographic Techniques</a></li>
52
<li><img alt="" src="../images/down.gif" /> <a href="#certificates">Certificates</a></li>
53
<li><img alt="" src="../images/down.gif" /> <a href="#ssl">Secure Sockets Layer (SSL)</a></li>
54
<li><img alt="" src="../images/down.gif" /> <a href="#references">References</a></li>
56
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
58
<h2><a name="cryptographictech" id="cryptographictech">Cryptographic Techniques</a></h2>
60
<p>Understanding SSL requires an understanding of cryptographic
61
algorithms, message digest functions (aka. one-way or hash functions), and
62
digital signatures. These techniques are the subject of entire books (see
63
for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy,
64
integrity, and authentication.</p>
66
<h3><a name="cryptographicalgo" id="cryptographicalgo">Cryptographic Algorithms</a></h3>
68
<p>Suppose Alice wants to send a message to her bank to transfer some
69
money. Alice would like the message to be private, since it will
70
include information such as her account number and transfer amount. One
71
solution is to use a cryptographic algorithm, a technique that would
72
transform her message into an encrypted form, unreadable until it is
73
decrypted. Once in this form, the message can only be
74
decrypted by using a secret key. Without the key the message is useless:
75
good cryptographic algorithms make it so difficult
76
for intruders to decode the original text that it isn't worth their
79
<p>There are two categories of cryptographic algorithms: conventional
83
<dt>Conventional cryptography</dt>
84
<dd>also known as symmetric cryptography, requires the sender and
85
receiver to share a key: a secret piece of information that may be
86
used to encrypt or decrypt a message. As long as this key is kept
87
secret, nobody other than the sender or recipient can read the message.
88
If Alice and the bank know a secret key, then they can send each other
89
private messages. The task of sharing a key between sender and recipient
90
before communicating, while also keeping it secret from others, can be
93
<dt>Public key cryptography</dt>
94
<dd>also known as asymmetric cryptography, solves the key exchange
95
problem by defining an algorithm which uses two keys, each of which
96
may be used to encrypt a message. If one key is used to encrypt a
97
message then the other must be used to decrypt it. This makes it
98
possible to receive secure messages by simply publishing one key
99
(the public key) and keeping the other secret (the private key).</dd>
102
<p>Anyone can encrypt a message using the public key, but only the
103
owner of the private key will be able to read it. In this way, Alice
104
can send private messages to the owner of a key-pair (the bank), by
105
encrypting it using their public key. Only the bank will be able to
109
<h3><a name="messagedigests" id="messagedigests">Message Digests</a></h3>
111
<p>Although Alice may encrypt her message to make it private, there
112
is still a concern that someone might modify her original message or
113
substitute it with a different one, in order to transfer the money
114
to themselves, for instance. One way of guaranteeing the integrity
115
of Alice's message is for her to create a concise summary of her
116
message and send this to the bank as well. Upon receipt of the message,
117
the bank creates its own summary and compares it with the one Alice
118
sent. If the summaries are the same then the message has been received
121
<p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way
122
function</em> or <em>hash function</em>. Message digests are used to create
123
a short, fixed-length representation of a longer, variable-length message.
124
Digest algorithms are designed to produce a unique digests for each
125
message. Message digests are designed to make it impractically difficult
126
to determine the message from the digest, and (in theory) impossible to
127
find two different messages which create the same digest -- thus
128
eliminating the possibility of substituting one message for another while
129
maintaining the same digest.</p>
131
<p>Another challenge that Alice faces is finding a way to send the digest
132
to the bank securely; if the digest is not sent securely, its integrity may
133
be compromised, and with it, the possibility for the bank to determine the
134
integrity of the original message. Only if the digest is sent securely can
135
the integrity of the associated message be determined.</p>
137
<p>One way to send the digest securely is to include it in a digital
141
<h3><a name="digitalsignatures" id="digitalsignatures">Digital Signatures</a></h3>
142
<p>When Alice sends a message to the bank, the bank needs to ensure that the
143
message is really from her, so an intruder cannot request a transaction
144
involving her account. A <em>digital signature</em>, created by Alice and
145
included with the message, serves this purpose.</p>
147
<p>Digital signatures are created by encrypting a digest of the message,
148
and other information (such as a sequence number) with the sender's
149
private key. Though anyone can <em>decrypt</em> the signature using the public
150
key, only the sender knows the private key. This means that only they can
151
have signed it. Including the digest in the signature means the signature is
152
only good for that message; it also ensures the integrity of the message since
153
no one can change the digest and still sign it.</p>
154
<p>To guard against interception and reuse of the signature by an intruder at a
155
later date, the signature contains a unique sequence number. This protects
156
the bank from a fraudulent claim from Alice that she did not send the message
157
-- only she could have signed it (non-repudiation).</p>
159
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
160
<div class="section">
161
<h2><a name="certificates" id="certificates">Certificates</a></h2>
163
<p>Although Alice could have sent a private message to the bank, signed
164
it, and ensured the integrity of the message, she still needs to be sure
165
that she is really communicating with the bank. This means that she needs
166
to be sure that the public key she is using is part of the bank's key-pair,
167
and not an intruder's. Similarly, the bank needs to verify that the message
168
signature really was signed by the private key that belongs to Alice.</p>
170
<p>If each party has a certificate which validates the other's identity,
171
confirms the public key, and is signed by a trusted agency, then both
172
can be assured that they are communicating with whom they think they are.
173
Such a trusted agency is called a <em>Certificate Authority</em>, and
174
certificates are used for authentication.</p>
176
<h3><a name="certificatecontents" id="certificatecontents">Certificate Contents</a></h3>
178
<p>A certificate associates a public key with the real identity of
179
an individual, server, or other entity, known as the subject. As
180
shown in <a href="#table1">Table 1</a>, information about the subject
181
includes identifying information (the distinguished name), and the
182
public key. It also includes the identification and signature of the
183
Certificate Authority that issued the certificate, and the period of
184
time during which the certificate is valid. It may have additional
185
information (or extensions) as well as administrative information
186
for the Certificate Authority's use, such as a serial number.</p>
188
<h4><a name="table1" id="table1">Table 1: Certificate Information</a></h4>
193
<td>Distinguished Name, Public Key</td></tr>
195
<td>Distinguished Name, Signature</td></tr>
196
<tr><th>Period of Validity</th>
197
<td>Not Before Date, Not After Date</td></tr>
198
<tr><th>Administrative Information</th>
199
<td>Version, Serial Number</td></tr>
200
<tr><th>Extended Information</th>
201
<td>Basic Constraints, Netscape Flags, etc.</td></tr>
205
<p>A distinguished name is used to provide an identity in a specific
206
context -- for instance, an individual might have a personal
207
certificate as well as one for their identity as an employee.
208
Distinguished names are defined by the X.509 standard [<a href="#X509">X509</a>], which defines the fields, field names, and
209
abbreviations used to refer to the fields (see <a href="#table2">Table
212
<h4><a name="table2" id="table2">Table 2: Distinguished Name Information</a></h4>
214
<table class="bordered">
216
<tr><th>DN Field</th>
219
<th>Example</th></tr>
220
<tr><td>Common Name</td>
222
<td>Name being certified</td>
223
<td>CN=Joe Average</td></tr>
224
<tr><td>Organization or Company</td>
226
<td>Name is associated with this<br />organization</td>
227
<td>O=Snake Oil, Ltd.</td></tr>
228
<tr><td>Organizational Unit</td>
230
<td>Name is associated with this <br />organization unit, such
232
<td>OU=Research Institute</td></tr>
233
<tr><td>City/Locality</td>
235
<td>Name is located in this City</td>
236
<td>L=Snake City</td></tr>
237
<tr><td>State/Province</td>
239
<td>Name is located in this State/Province</td>
240
<td>ST=Desert</td></tr>
243
<td>Name is located in this Country (ISO code)</td>
248
<p>A Certificate Authority may define a policy specifying which
249
distinguished field names are optional, and which are required. It
250
may also place requirements upon the field contents, as may users of
251
certificates. For example, a Netscape browser requires that the
252
Common Name for a certificate representing a server matches a wildcard
253
pattern for the domain name of that server, such
254
as <code>*.snakeoil.com</code>.</p>
256
<p>The binary format of a certificate is defined using the ASN.1
257
notation [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This
258
notation defines how to specify the contents, and encoding rules
259
define how this information is translated into binary form. The binary
260
encoding of the certificate is defined using Distinguished Encoding
261
Rules (DER), which are based on the more general Basic Encoding Rules
262
(BER). For those transmissions which cannot handle binary, the binary
263
form may be translated into an ASCII form by using Base64 encoding
264
[<a href="#MIME">MIME</a>]. When placed between begin and end delimiter
265
lines (as below), this encoded version is called a PEM ("Privacy Enhanced
266
Mail") encoded certificate.</p>
268
<div class="example"><h3>Example of a PEM-encoded certificate (snakeoil.crt)</h3><pre>-----BEGIN CERTIFICATE-----
269
MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
270
FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
271
A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
272
cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
273
bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
274
MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
275
a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
276
cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
277
AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
278
gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
279
vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
280
lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
281
HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
282
gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
283
2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
284
dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
285
-----END CERTIFICATE-----</pre></div>
288
<h3><a name="certificateauthorities" id="certificateauthorities">Certificate Authorities</a></h3>
290
<p>By verifying the information in a certificate request
291
before granting the certificate, the Certificate Authority assures
292
itself of the identity of the private key owner of a key-pair.
293
For instance, if Alice requests a personal certificate, the
294
Certificate Authority must first make sure that Alice really is the
295
person the certificate claims she is.</p>
297
<h4><a name="certificatechains" id="certificatechains">Certificate Chains</a></h4>
299
<p>A Certificate Authority may also issue a certificate for
300
another Certificate Authority. When examining a certificate,
301
Alice may need to examine the certificate of the issuer, for each
302
parent Certificate Authority, until reaching one which she has
303
confidence in. She may decide to trust only certificates with a
304
limited chain of issuers, to reduce her risk of a "bad" certificate
308
<h4><a name="rootlevelca" id="rootlevelca">Creating a Root-Level CA</a></h4>
310
<p>As noted earlier, each certificate requires an issuer to assert
311
the validity of the identity of the certificate subject, up to
312
the top-level Certificate Authority (CA). This presents a problem:
313
who can vouch for the certificate of the top-level
314
authority, which has no issuer? In this unique case, the
315
certificate is "self-signed", so the issuer of the certificate is
316
the same as the subject. Browsers are preconfigured to trust well-known
317
certificate authorities, but it is important to exercise extra care in
318
trusting a self-signed certificate. The wide publication of a
319
public key by the root authority reduces the risk in trusting this
320
key -- it would be obvious if someone else publicized a key
321
claiming to be the authority.</p>
323
<p>A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a>
324
have established themselves as Certificate Authorities. These
325
companies provide the following services:</p>
328
<li>Verifying certificate requests</li>
329
<li>Processing certificate requests</li>
330
<li>Issuing and managing certificates</li>
333
<p>It is also possible to create your own Certificate Authority.
334
Although risky in the Internet environment, it may be useful
335
within an Intranet where the organization can easily verify the
336
identities of individuals and servers.</p>
339
<h4><a name="certificatemanagement" id="certificatemanagement">Certificate Management</a></h4>
341
<p>Establishing a Certificate Authority is a responsibility which
342
requires a solid administrative, technical, and management
343
framework. Certificate Authorities not only issue certificates,
344
they also manage them -- that is, they determine for how long
345
certificates remain valid, they renew them, and they keep lists of
346
certificates that were issued in the past but are no longer valid
347
(Certificate Revocation Lists, or CRLs).</p>
349
<p>For example, if Alice is entitled to a certificate as an
350
employee of a company, but has now left
351
that company, her certificate may need to be revoked.
352
Because certificates are only issued after the subject's identity has
353
been verified, and can then be passed around to all those with whom
354
the subject may communicate, it is impossible to tell from the
355
certificate alone that it has been revoked.
356
When examining certificates for validity, therefore,
357
it is necessary to contact the issuing Certificate Authority to
358
check CRLs -- this is usually not an automated part of the process.</p>
360
<div class="note"><h3>Note</h3>
361
<p>If you use a Certificate Authority that browsers are not configured
362
to trust by default, it is necessary to load the Certificate
363
Authority certificate into the browser, enabling the browser to
364
validate server certificates signed by that Certificate Authority.
365
Doing so may be dangerous, since once loaded, the browser will
366
accept all certificates signed by that Certificate Authority.</p>
371
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
372
<div class="section">
373
<h2><a name="ssl" id="ssl">Secure Sockets Layer (SSL)</a></h2>
375
<p>The Secure Sockets Layer protocol is a protocol layer which may be
376
placed between a reliable connection-oriented network layer protocol
377
(e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides
378
for secure communication between client and server by allowing mutual
379
authentication, the use of digital signatures for integrity, and encryption
382
<p>The protocol is designed to support a range of choices for specific
383
algorithms used for cryptography, digests, and signatures. This allows
384
algorithm selection for specific servers to be made based on legal, export
385
or other concerns, and also enables the protocol to take advantage of new
386
algorithms. Choices are negotiated between client and server at the start
387
of establishing a protocol session.</p>
389
<h3><a name="table4" id="table4">Table 4: Versions of the SSL protocol</a></h3>
391
<table class="bordered">
396
<th>Browser Support</th></tr>
397
<tr><td>SSL v2.0</td>
398
<td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2">SSL2</a>]</td>
399
<td>First SSL protocol for which implementations exists</td>
400
<td>- NS Navigator 1.x/2.x<br />
402
- Lynx/2.8+OpenSSL</td></tr>
403
<tr><td>SSL v3.0</td>
404
<td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3">SSL3</a>]</td>
405
<td>Revisions to prevent specific security attacks, add non-RSA
406
ciphers, and support for certificate chains</td>
407
<td>- NS Navigator 2.x/3.x/4.x<br />
408
- MS IE 3.x/4.x<br />
409
- Lynx/2.8+OpenSSL</td></tr>
410
<tr><td>TLS v1.0</td>
411
<td>Proposed Internet Standard (from IETF) [<a href="#TLS1">TLS1</a>]</td>
412
<td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block
413
padding for block ciphers, message order standardization and more
415
<td>- Lynx/2.8+OpenSSL</td></tr>
419
<p>There are a number of versions of the SSL protocol, as shown in
420
<a href="#table4">Table 4</a>. As noted there, one of the benefits in
421
SSL 3.0 is that it adds support of certificate chain loading. This feature
422
allows a server to pass a server certificate along with issuer certificates
423
to the browser. Chain loading also permits the browser to validate the
424
server certificate, even if Certificate Authority certificates are not
425
installed for the intermediate issuers, since they are included in the
426
certificate chain. SSL 3.0 is the basis for the Transport Layer Security
427
[<a href="#TLS1">TLS</a>] protocol standard, currently in development by
428
the Internet Engineering Task Force (IETF).</p>
430
<h3><a name="session" id="session">Establishing a Session</a></h3>
432
<p>The SSL session is established by following a handshake sequence
433
between client and server, as shown in <a href="#figure1">Figure 1</a>. This sequence may vary, depending on whether the server
434
is configured to provide a server certificate or request a client
435
certificate. Although cases exist where additional handshake steps
436
are required for management of cipher information, this article
437
summarizes one common scenario. See the SSL specification for the full
438
range of possibilities.</p>
440
<div class="note"><h3>Note</h3>
441
<p>Once an SSL session has been established, it may be reused. This
442
avoids the performance penalty of repeating the many steps needed
443
to start a session. To do this, the server assigns each SSL session a
444
unique session identifier which is cached in the server and which the
445
client can use in future connections to reduce the handshake time
446
(until the session identifer expires from the cache of the server).</p>
450
<img src="../images/ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
451
<a id="figure1" name="figure1"><dfn>Figure 1</dfn></a>: Simplified SSL
452
Handshake Sequence</p>
454
<p>The elements of the handshake sequence, as used by the client and
455
server, are listed below:</p>
458
<li>Negotiate the Cipher Suite to be used during data transfer</li>
459
<li>Establish and share a session key between client and server</li>
460
<li>Optionally authenticate the server to the client</li>
461
<li>Optionally authenticate the client to the server</li>
464
<p>The first step, Cipher Suite Negotiation, allows the client and
465
server to choose a Cipher Suite supported by both of them. The SSL3.0
466
protocol specification defines 31 Cipher Suites. A Cipher Suite is
467
defined by the following components:</p>
470
<li>Key Exchange Method</li>
471
<li>Cipher for Data Transfer</li>
472
<li>Message Digest for creating the Message Authentication Code (MAC)</li>
475
<p>These three elements are described in the sections that follow.</p>
478
<h3><a name="keyexchange" id="keyexchange">Key Exchange Method</a></h3>
480
<p>The key exchange method defines how the shared secret symmetric
481
cryptography key used for application data transfer will be agreed
482
upon by client and server. SSL 2.0 uses RSA key exchange only, while
483
SSL 3.0 supports a choice of key exchange algorithms including
484
RSA key exchange (when certificates are used), and Diffie-Hellman key
485
exchange (for exchanging keys without certificates, or without prior
486
communication between client and server).</p>
488
<p>One variable in the choice of key exchange methods is digital
489
signatures -- whether or not to use them, and if so, what kind of
490
signatures to use. Signing with a private key provides protection
491
against a man-in-the-middle-attack during the information exchange
492
used to generating the shared key [<a href="#AC96">AC96</a>, p516].</p>
495
<h3><a name="ciphertransfer" id="ciphertransfer">Cipher for Data Transfer</a></h3>
497
<p>SSL uses conventional symmetric cryptography, as described earlier,
498
for encrypting messages in a session.
499
There are nine choices of how to encrypt, including the option not to
503
<li>No encryption</li>
506
<li>RC4 with 40-bit keys</li>
507
<li>RC4 with 128-bit keys</li>
509
<li>CBC Block Ciphers
510
<ul><li>RC2 with 40 bit key</li>
511
<li>DES with 40 bit key</li>
512
<li>DES with 56 bit key</li>
513
<li>Triple-DES with 168 bit key</li>
514
<li>Idea (128 bit key)</li>
515
<li>Fortezza (96 bit key)</li>
519
<p>"CBC" refers to Cipher Block Chaining, which means that a
520
portion of the previously encrypted cipher text is used in the
521
encryption of the current block. "DES" refers to the Data Encryption
522
Standard [<a href="#AC96">AC96</a>, ch12], which has a number of
523
variants (including DES40 and 3DES_EDE). "Idea" is currently one of
524
the best and cryptographically strongest algorithms available,
525
and "RC2" is a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>, ch13].</p>
528
<h3><a name="digestfuntion" id="digestfuntion">Digest Function</a></h3>
530
<p>The choice of digest function determines how a digest is created
531
from a record unit. SSL supports the following:</p>
534
<li>No digest (Null choice)</li>
535
<li>MD5, a 128-bit hash</li>
536
<li>Secure Hash Algorithm (SHA-1), a 160-bit hash</li>
539
<p>The message digest is used to create a Message Authentication Code
540
(MAC) which is encrypted with the message to verify integrity and to
541
protect against replay attacks.</p>
544
<h3><a name="handshake" id="handshake">Handshake Sequence Protocol</a></h3>
546
<p>The handshake sequence uses three protocols:</p>
549
<li>The <dfn>SSL Handshake Protocol</dfn>
550
for performing the client and server SSL session establishment.</li>
551
<li>The <dfn>SSL Change Cipher Spec Protocol</dfn> for actually
552
establishing agreement on the Cipher Suite for the session.</li>
553
<li>The <dfn>SSL Alert Protocol</dfn> for conveying SSL error
554
messages between client and server.</li>
557
<p>These protocols, as well as application protocol data, are
558
encapsulated in the <dfn>SSL Record Protocol</dfn>, as shown in
559
<a href="#figure2">Figure 2</a>. An encapsulated protocol is
560
transferred as data by the lower layer protocol, which does not
561
examine the data. The encapsulated protocol has no knowledge of the
562
underlying protocol.</p>
565
<img src="../images/ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
566
<a id="figure2" name="figure2"><dfn>Figure 2</dfn></a>: SSL Protocol Stack
569
<p>The encapsulation of SSL control protocols by the record protocol
570
means that if an active session is renegotiated the control protocols
571
will be transmitted securely. If there was no previous session,
572
the Null cipher suite is used, which means there will be no encryption and
573
messages will have no integrity digests, until the session has been
577
<h3><a name="datatransfer" id="datatransfer">Data Transfer</a></h3>
579
<p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>,
580
is used to transfer application and SSL Control data between the
581
client and server, where necessary fragmenting this data into smaller units,
582
or combining multiple higher level protocol data messages into single
583
units. It may compress, attach digest signatures, and encrypt these
584
units before transmitting them using the underlying reliable transport
585
protocol (Note: currently, no major SSL implementations include support
586
for compression).</p>
589
<img src="../images/ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
590
<a id="figure3" name="figure3"><dfn>Figure 3</dfn></a>: SSL Record Protocol
594
<h3><a name="securehttp" id="securehttp">Securing HTTP Communication</a></h3>
596
<p>One common use of SSL is to secure Web HTTP communication between
597
a browser and a webserver. This does not preclude the use of
598
non-secured HTTP - the secure version (called HTTPS) is the same as
599
plain HTTP over SSL, but uses the URL scheme <code>https</code>
600
rather than <code>http</code>, and a different server port (by default,
601
port 443). This functionality is a large part of what <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> provides for the Apache webserver.</p>
603
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
604
<div class="section">
605
<h2><a name="references" id="references">References</a></h2>
608
<dt><a id="AC96" name="AC96">[AC96]</a></dt>
609
<dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
610
1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for various other materials by Bruce
613
<dt><a id="X208" name="X208">[X208]</a></dt>
614
<dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
615
One (ASN.1)</q>, 1988. See for instance <a href="http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I">http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I</a>.
618
<dt><a id="X509" name="X509">[X509]</a></dt>
619
<dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
620
Framework</q>. See for instance <a href="http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509">http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509</a>.
623
<dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
624
<dd><q>Public Key Cryptography Standards (PKCS)</q>,
625
RSA Laboratories Technical Notes, See <a href="http://www.rsasecurity.com/rsalabs/pkcs/">http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
627
<dt><a id="MIME" name="MIME">[MIME]</a></dt>
628
<dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
629
(MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
630
See for instance <a href="http://ietf.org/rfc/rfc2045.txt">http://ietf.org/rfc/rfc2045.txt</a>.</dd>
632
<dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
633
<dd>Kipp E.B. Hickman, <q>The SSL Protocol</q>, 1995. See <a href="http://www.netscape.com/eng/security/SSL_2.html">http://www.netscape.com/eng/security/SSL_2.html</a>.</dd>
635
<dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
636
<dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
637
Version 3.0</q>, 1996. See <a href="http://www.netscape.com/eng/ssl3/draft302.txt">http://www.netscape.com/eng/ssl3/draft302.txt</a>.</dd>
639
<dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
640
<dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
641
1999. See <a href="http://ietf.org/rfc/rfc2246.txt">http://ietf.org/rfc/rfc2246.txt</a>.</dd>
644
<div class="bottomlang">
645
<p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" title="English"> en </a> |
646
<a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p>
647
</div><div id="footer">
648
<p class="apache">Copyright 2006 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
649
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div>
b'\\ No newline at end of file'
added
removed
docs/manual/ssl/ssl_intro.html.en
