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 <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
7 This file is generated from xml source: DO NOT EDIT
8 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
10 <title>SSL/TLS Strong Encryption: An Introduction - Apache HTTP Server Version 2.5</title>
11 <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
12 <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
13 <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" />
14 <script src="../style/scripts/prettify.min.js" type="text/javascript">
17 <link href="../images/favicon.ico" rel="shortcut icon" /></head>
18 <body id="manual-page"><div id="page-header">
19 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p>
20 <p class="apache">Apache HTTP Server Version 2.5</p>
21 <img alt="" src="../images/feather.png" /></div>
22 <div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
24 <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.5</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS Strong Encryption: An Introduction</h1>
26 <p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" title="English"> en </a> |
27 <a href="../fr/ssl/ssl_intro.html" hreflang="fr" rel="alternate" title="Français"> fr </a> |
28 <a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p>
32 <p>As an introduction this chapter is aimed at readers who are familiar
33 with the Web, HTTP, and Apache, but are not security experts. It is not
34 intended to be a definitive guide to the SSL protocol, nor does it discuss
35 specific techniques for managing certificates in an organization, or the
36 important legal issues of patents and import and export restrictions.
37 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,
38 and examples as a starting point for further exploration.</p>
40 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cryptographictech">Cryptographic Techniques</a></li>
41 <li><img alt="" src="../images/down.gif" /> <a href="#certificates">Certificates</a></li>
42 <li><img alt="" src="../images/down.gif" /> <a href="#ssl">Secure Sockets Layer (SSL)</a></li>
43 <li><img alt="" src="../images/down.gif" /> <a href="#references">References</a></li>
44 </ul><h3>See also</h3><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
45 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
47 <h2><a name="cryptographictech" id="cryptographictech">Cryptographic Techniques</a></h2>
49 <p>Understanding SSL requires an understanding of cryptographic
50 algorithms, message digest functions (aka. one-way or hash functions), and
51 digital signatures. These techniques are the subject of entire books (see
52 for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy,
53 integrity, and authentication.</p>
55 <h3><a name="cryptographicalgo" id="cryptographicalgo">Cryptographic Algorithms</a></h3>
57 <p>Suppose Alice wants to send a message to her bank to transfer some
58 money. Alice would like the message to be private, since it will
59 include information such as her account number and transfer amount. One
60 solution is to use a cryptographic algorithm, a technique that would
61 transform her message into an encrypted form, unreadable until it is
62 decrypted. Once in this form, the message can only be
63 decrypted by using a secret key. Without the key the message is useless:
64 good cryptographic algorithms make it so difficult
65 for intruders to decode the original text that it isn't worth their
68 <p>There are two categories of cryptographic algorithms: conventional
72 <dt>Conventional cryptography</dt>
73 <dd>also known as symmetric cryptography, requires the sender and
74 receiver to share a key: a secret piece of information that may be
75 used to encrypt or decrypt a message. As long as this key is kept
76 secret, nobody other than the sender or recipient can read the message.
77 If Alice and the bank know a secret key, then they can send each other
78 private messages. The task of sharing a key between sender and recipient
79 before communicating, while also keeping it secret from others, can be
82 <dt>Public key cryptography</dt>
83 <dd>also known as asymmetric cryptography, solves the key exchange
84 problem by defining an algorithm which uses two keys, each of which
85 may be used to encrypt a message. If one key is used to encrypt a
86 message then the other must be used to decrypt it. This makes it
87 possible to receive secure messages by simply publishing one key
88 (the public key) and keeping the other secret (the private key).</dd>
91 <p>Anyone can encrypt a message using the public key, but only the
92 owner of the private key will be able to read it. In this way, Alice
93 can send private messages to the owner of a key-pair (the bank), by
94 encrypting them using their public key. Only the bank will be able to
98 <h3><a name="messagedigests" id="messagedigests">Message Digests</a></h3>
100 <p>Although Alice may encrypt her message to make it private, there
101 is still a concern that someone might modify her original message or
102 substitute it with a different one, in order to transfer the money
103 to themselves, for instance. One way of guaranteeing the integrity
104 of Alice's message is for her to create a concise summary of her
105 message and send this to the bank as well. Upon receipt of the message,
106 the bank creates its own summary and compares it with the one Alice
107 sent. If the summaries are the same then the message has been received
110 <p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way
111 function</em> or <em>hash function</em>. Message digests are used to create
112 a short, fixed-length representation of a longer, variable-length message.
113 Digest algorithms are designed to produce a unique digest for each
114 message. Message digests are designed to make it impractically difficult
115 to determine the message from the digest and (in theory) impossible to
116 find two different messages which create the same digest -- thus
117 eliminating the possibility of substituting one message for another while
118 maintaining the same digest.</p>
120 <p>Another challenge that Alice faces is finding a way to send the digest
121 to the bank securely; if the digest is not sent securely, its integrity may
122 be compromised and with it the possibility for the bank to determine the
123 integrity of the original message. Only if the digest is sent securely can
124 the integrity of the associated message be determined.</p>
126 <p>One way to send the digest securely is to include it in a digital
130 <h3><a name="digitalsignatures" id="digitalsignatures">Digital Signatures</a></h3>
131 <p>When Alice sends a message to the bank, the bank needs to ensure that the
132 message is really from her, so an intruder cannot request a transaction
133 involving her account. A <em>digital signature</em>, created by Alice and
134 included with the message, serves this purpose.</p>
136 <p>Digital signatures are created by encrypting a digest of the message and
137 other information (such as a sequence number) with the sender's private key.
138 Though anyone can <em>decrypt</em> the signature using the public key, only the
139 sender knows the private key. This means that only the sender can have signed
140 the message. Including the digest in the signature means the signature is only
141 good for that message; it also ensures the integrity of the message since no one
142 can change the digest and still sign it.</p>
143 <p>To guard against interception and reuse of the signature by an intruder at a
144 later date, the signature contains a unique sequence number. This protects
145 the bank from a fraudulent claim from Alice that she did not send the message
146 -- only she could have signed it (non-repudiation).</p>
148 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
149 <div class="section">
150 <h2><a name="certificates" id="certificates">Certificates</a></h2>
152 <p>Although Alice could have sent a private message to the bank, signed
153 it and ensured the integrity of the message, she still needs to be sure
154 that she is really communicating with the bank. This means that she needs
155 to be sure that the public key she is using is part of the bank's key-pair,
156 and not an intruder's. Similarly, the bank needs to verify that the message
157 signature really was signed by the private key that belongs to Alice.</p>
159 <p>If each party has a certificate which validates the other's identity,
160 confirms the public key and is signed by a trusted agency, then both
161 can be assured that they are communicating with whom they think they are.
162 Such a trusted agency is called a <em>Certificate Authority</em> and
163 certificates are used for authentication.</p>
165 <h3><a name="certificatecontents" id="certificatecontents">Certificate Contents</a></h3>
167 <p>A certificate associates a public key with the real identity of
168 an individual, server, or other entity, known as the subject. As
169 shown in <a href="#table1">Table 1</a>, information about the subject
170 includes identifying information (the distinguished name) and the
171 public key. It also includes the identification and signature of the
172 Certificate Authority that issued the certificate and the period of
173 time during which the certificate is valid. It may have additional
174 information (or extensions) as well as administrative information
175 for the Certificate Authority's use, such as a serial number.</p>
177 <h4><a name="table1" id="table1">Table 1: Certificate Information</a></h4>
182 <td>Distinguished Name, Public Key</td></tr>
184 <td>Distinguished Name, Signature</td></tr>
185 <tr><th>Period of Validity</th>
186 <td>Not Before Date, Not After Date</td></tr>
187 <tr><th>Administrative Information</th>
188 <td>Version, Serial Number</td></tr>
189 <tr><th>Extended Information</th>
190 <td>Basic Constraints, Netscape Flags, etc.</td></tr>
194 <p>A distinguished name is used to provide an identity in a specific
195 context -- for instance, an individual might have a personal
196 certificate as well as one for their identity as an employee.
197 Distinguished names are defined by the X.509 standard [<a href="#X509">X509</a>], which defines the fields, field names and
198 abbreviations used to refer to the fields (see <a href="#table2">Table
201 <h4><a name="table2" id="table2">Table 2: Distinguished Name Information</a></h4>
203 <table class="bordered">
205 <tr><th>DN Field</th>
208 <th>Example</th></tr>
209 <tr><td>Common Name</td>
211 <td>Name being certified</td>
212 <td>CN=Joe Average</td></tr>
213 <tr><td>Organization or Company</td>
215 <td>Name is associated with this<br />organization</td>
216 <td>O=Snake Oil, Ltd.</td></tr>
217 <tr><td>Organizational Unit</td>
219 <td>Name is associated with this <br />organization unit, such
221 <td>OU=Research Institute</td></tr>
222 <tr><td>City/Locality</td>
224 <td>Name is located in this City</td>
225 <td>L=Snake City</td></tr>
226 <tr><td>State/Province</td>
228 <td>Name is located in this State/Province</td>
229 <td>ST=Desert</td></tr>
232 <td>Name is located in this Country (ISO code)</td>
237 <p>A Certificate Authority may define a policy specifying which
238 distinguished field names are optional and which are required. It
239 may also place requirements upon the field contents, as may users of
240 certificates. For example, a Netscape browser requires that the
241 Common Name for a certificate representing a server matches a wildcard
242 pattern for the domain name of that server, such
243 as <code>*.snakeoil.com</code>.</p>
245 <p>The binary format of a certificate is defined using the ASN.1
246 notation [<a href="#ASN1">ASN1</a>] [<a href="#PKCS">PKCS</a>]. This
247 notation defines how to specify the contents and encoding rules
248 define how this information is translated into binary form. The binary
249 encoding of the certificate is defined using Distinguished Encoding
250 Rules (DER), which are based on the more general Basic Encoding Rules
251 (BER). For those transmissions which cannot handle binary, the binary
252 form may be translated into an ASCII form by using Base64 encoding
253 [<a href="#MIME">MIME</a>]. When placed between begin and end delimiter
254 lines (as below), this encoded version is called a PEM ("Privacy Enhanced
255 Mail") encoded certificate.</p>
257 <div class="example"><h3>Example of a PEM-encoded certificate (snakeoil.crt)</h3><pre>-----BEGIN CERTIFICATE-----
258 MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
259 FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
260 A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
261 cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
262 bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
263 MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
264 a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
265 cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
266 AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
267 gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
268 vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
269 lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
270 HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
271 gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
272 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
273 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
274 -----END CERTIFICATE-----</pre></div>
277 <h3><a name="certificateauthorities" id="certificateauthorities">Certificate Authorities</a></h3>
279 <p>By verifying the information in a certificate request
280 before granting the certificate, the Certificate Authority assures
281 itself of the identity of the private key owner of a key-pair.
282 For instance, if Alice requests a personal certificate, the
283 Certificate Authority must first make sure that Alice really is the
284 person the certificate request claims she is.</p>
286 <h4><a name="certificatechains" id="certificatechains">Certificate Chains</a></h4>
288 <p>A Certificate Authority may also issue a certificate for
289 another Certificate Authority. When examining a certificate,
290 Alice may need to examine the certificate of the issuer, for each
291 parent Certificate Authority, until reaching one which she has
292 confidence in. She may decide to trust only certificates with a
293 limited chain of issuers, to reduce her risk of a "bad" certificate
297 <h4><a name="rootlevelca" id="rootlevelca">Creating a Root-Level CA</a></h4>
299 <p>As noted earlier, each certificate requires an issuer to assert
300 the validity of the identity of the certificate subject, up to
301 the top-level Certificate Authority (CA). This presents a problem:
302 who can vouch for the certificate of the top-level
303 authority, which has no issuer? In this unique case, the
304 certificate is "self-signed", so the issuer of the certificate is
305 the same as the subject. Browsers are preconfigured to trust well-known
306 certificate authorities, but it is important to exercise extra care in
307 trusting a self-signed certificate. The wide publication of a
308 public key by the root authority reduces the risk in trusting this
309 key -- it would be obvious if someone else publicized a key
310 claiming to be the authority.</p>
312 <p>A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a>
313 have established themselves as Certificate Authorities. These
314 companies provide the following services:</p>
317 <li>Verifying certificate requests</li>
318 <li>Processing certificate requests</li>
319 <li>Issuing and managing certificates</li>
322 <p>It is also possible to create your own Certificate Authority.
323 Although risky in the Internet environment, it may be useful
324 within an Intranet where the organization can easily verify the
325 identities of individuals and servers.</p>
328 <h4><a name="certificatemanagement" id="certificatemanagement">Certificate Management</a></h4>
330 <p>Establishing a Certificate Authority is a responsibility which
331 requires a solid administrative, technical and management
332 framework. Certificate Authorities not only issue certificates,
333 they also manage them -- that is, they determine for how long
334 certificates remain valid, they renew them and keep lists of
335 certificates that were issued in the past but are no longer valid
336 (Certificate Revocation Lists, or CRLs).</p>
338 <p>For example, if Alice is entitled to a certificate as an
339 employee of a company but has now left
340 that company, her certificate may need to be revoked.
341 Because certificates are only issued after the subject's identity has
342 been verified and can then be passed around to all those with whom
343 the subject may communicate, it is impossible to tell from the
344 certificate alone that it has been revoked.
345 Therefore when examining certificates for validity
346 it is necessary to contact the issuing Certificate Authority to
347 check CRLs -- this is usually not an automated part of the process.</p>
349 <div class="note"><h3>Note</h3>
350 <p>If you use a Certificate Authority that browsers are not configured
351 to trust by default, it is necessary to load the Certificate
352 Authority certificate into the browser, enabling the browser to
353 validate server certificates signed by that Certificate Authority.
354 Doing so may be dangerous, since once loaded, the browser will
355 accept all certificates signed by that Certificate Authority.</p>
360 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
361 <div class="section">
362 <h2><a name="ssl" id="ssl">Secure Sockets Layer (SSL)</a></h2>
364 <p>The Secure Sockets Layer protocol is a protocol layer which may be
365 placed between a reliable connection-oriented network layer protocol
366 (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides
367 for secure communication between client and server by allowing mutual
368 authentication, the use of digital signatures for integrity and encryption
371 <p>The protocol is designed to support a range of choices for specific
372 algorithms used for cryptography, digests and signatures. This allows
373 algorithm selection for specific servers to be made based on legal, export
374 or other concerns and also enables the protocol to take advantage of new
375 algorithms. Choices are negotiated between client and server when
376 establishing a protocol session.</p>
378 <h3><a name="table4" id="table4">Table 4: Versions of the SSL protocol</a></h3>
380 <table class="bordered">
386 <tr><td>SSL v2.0</td>
387 <td>Vendor Standard (from Netscape Corp.)</td>
388 <td>First SSL protocol for which implementations exist</td>
390 <tr><td>SSL v3.0</td>
391 <td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3">SSL3</a>]</td>
392 <td>Revisions to prevent specific security attacks, add non-RSA
393 ciphers and support for certificate chains</td>
395 <tr><td>TLS v1.0</td>
396 <td>Proposed Internet Standard (from IETF) [<a href="#TLS1">TLS1</a>]</td>
397 <td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block
398 padding for block ciphers, message order standardization and more
401 <tr><td>TLS v1.1</td>
402 <td>Proposed Internet Standard (from IETF) [<a href="#TLS11">TLS11</a>]</td>
403 <td>Update of TLS 1.0 to add protection against Cipher block chaining
406 <tr><td>TLS v1.2</td>
407 <td>Proposed Internet Standard (from IETF) [<a href="#TLS12">TLS12</a>]</td>
408 <td>Update of TLS 1.2 deprecating MD5 as hash, and adding incompatibility
409 to SSL so it will never negotiate the use of SSLv2.</td>
414 <p>There are a number of versions of the SSL protocol, as shown in
415 <a href="#table4">Table 4</a>. As noted there, one of the benefits in
416 SSL 3.0 is that it adds support of certificate chain loading. This feature
417 allows a server to pass a server certificate along with issuer certificates
418 to the browser. Chain loading also permits the browser to validate the
419 server certificate, even if Certificate Authority certificates are not
420 installed for the intermediate issuers, since they are included in the
421 certificate chain. SSL 3.0 is the basis for the Transport Layer Security
422 [<a href="#TLS1">TLS</a>] protocol standard, currently in development by
423 the Internet Engineering Task Force (IETF).</p>
425 <h3><a name="session" id="session">Establishing a Session</a></h3>
427 <p>The SSL session is established by following a handshake sequence
428 between client and server, as shown in <a href="#figure1">Figure 1</a>. This sequence may vary, depending on whether the server
429 is configured to provide a server certificate or request a client
430 certificate. Although cases exist where additional handshake steps
431 are required for management of cipher information, this article
432 summarizes one common scenario. See the SSL specification for the full
433 range of possibilities.</p>
435 <div class="note"><h3>Note</h3>
436 <p>Once an SSL session has been established, it may be reused. This
437 avoids the performance penalty of repeating the many steps needed
438 to start a session. To do this, the server assigns each SSL session a
439 unique session identifier which is cached in the server and which the
440 client can use in future connections to reduce the handshake time
441 (until the session identifier expires from the cache of the server).</p>
445 <img src="../images/ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
446 <a id="figure1" name="figure1"><dfn>Figure 1</dfn></a>: Simplified SSL
447 Handshake Sequence</p>
449 <p>The elements of the handshake sequence, as used by the client and
450 server, are listed below:</p>
453 <li>Negotiate the Cipher Suite to be used during data transfer</li>
454 <li>Establish and share a session key between client and server</li>
455 <li>Optionally authenticate the server to the client</li>
456 <li>Optionally authenticate the client to the server</li>
459 <p>The first step, Cipher Suite Negotiation, allows the client and
460 server to choose a Cipher Suite supported by both of them. The SSL3.0
461 protocol specification defines 31 Cipher Suites. A Cipher Suite is
462 defined by the following components:</p>
465 <li>Key Exchange Method</li>
466 <li>Cipher for Data Transfer</li>
467 <li>Message Digest for creating the Message Authentication Code (MAC)</li>
470 <p>These three elements are described in the sections that follow.</p>
473 <h3><a name="keyexchange" id="keyexchange">Key Exchange Method</a></h3>
475 <p>The key exchange method defines how the shared secret symmetric
476 cryptography key used for application data transfer will be agreed
477 upon by client and server. SSL 2.0 uses RSA key exchange only, while
478 SSL 3.0 supports a choice of key exchange algorithms including
479 RSA key exchange (when certificates are used), and Diffie-Hellman key
480 exchange (for exchanging keys without certificates, or without prior
481 communication between client and server).</p>
483 <p>One variable in the choice of key exchange methods is digital
484 signatures -- whether or not to use them, and if so, what kind of
485 signatures to use. Signing with a private key provides protection
486 against a man-in-the-middle-attack during the information exchange
487 used to generating the shared key [<a href="#AC96">AC96</a>, p516].</p>
490 <h3><a name="ciphertransfer" id="ciphertransfer">Cipher for Data Transfer</a></h3>
492 <p>SSL uses conventional symmetric cryptography, as described earlier,
493 for encrypting messages in a session.
494 There are nine choices of how to encrypt, including the option not to
498 <li>No encryption</li>
501 <li>RC4 with 40-bit keys</li>
502 <li>RC4 with 128-bit keys</li>
504 <li>CBC Block Ciphers
505 <ul><li>RC2 with 40 bit key</li>
506 <li>DES with 40 bit key</li>
507 <li>DES with 56 bit key</li>
508 <li>Triple-DES with 168 bit key</li>
509 <li>Idea (128 bit key)</li>
510 <li>Fortezza (96 bit key)</li>
514 <p>"CBC" refers to Cipher Block Chaining, which means that a
515 portion of the previously encrypted cipher text is used in the
516 encryption of the current block. "DES" refers to the Data Encryption
517 Standard [<a href="#AC96">AC96</a>, ch12], which has a number of
518 variants (including DES40 and 3DES_EDE). "Idea" is currently one of
519 the best and cryptographically strongest algorithms available,
520 and "RC2" is a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>, ch13].</p>
523 <h3><a name="digestfuntion" id="digestfuntion">Digest Function</a></h3>
525 <p>The choice of digest function determines how a digest is created
526 from a record unit. SSL supports the following:</p>
529 <li>No digest (Null choice)</li>
530 <li>MD5, a 128-bit hash</li>
531 <li>Secure Hash Algorithm (SHA-1), a 160-bit hash</li>
534 <p>The message digest is used to create a Message Authentication Code
535 (MAC) which is encrypted with the message to verify integrity and to
536 protect against replay attacks.</p>
539 <h3><a name="handshake" id="handshake">Handshake Sequence Protocol</a></h3>
541 <p>The handshake sequence uses three protocols:</p>
544 <li>The <dfn>SSL Handshake Protocol</dfn>
545 for performing the client and server SSL session establishment.</li>
546 <li>The <dfn>SSL Change Cipher Spec Protocol</dfn> for actually
547 establishing agreement on the Cipher Suite for the session.</li>
548 <li>The <dfn>SSL Alert Protocol</dfn> for conveying SSL error
549 messages between client and server.</li>
552 <p>These protocols, as well as application protocol data, are
553 encapsulated in the <dfn>SSL Record Protocol</dfn>, as shown in
554 <a href="#figure2">Figure 2</a>. An encapsulated protocol is
555 transferred as data by the lower layer protocol, which does not
556 examine the data. The encapsulated protocol has no knowledge of the
557 underlying protocol.</p>
560 <img src="../images/ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
561 <a id="figure2" name="figure2"><dfn>Figure 2</dfn></a>: SSL Protocol Stack
564 <p>The encapsulation of SSL control protocols by the record protocol
565 means that if an active session is renegotiated the control protocols
566 will be transmitted securely. If there was no previous session,
567 the Null cipher suite is used, which means there will be no encryption and
568 messages will have no integrity digests, until the session has been
572 <h3><a name="datatransfer" id="datatransfer">Data Transfer</a></h3>
574 <p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>,
575 is used to transfer application and SSL Control data between the
576 client and server, where necessary fragmenting this data into smaller units,
577 or combining multiple higher level protocol data messages into single
578 units. It may compress, attach digest signatures, and encrypt these
579 units before transmitting them using the underlying reliable transport
580 protocol (Note: currently, no major SSL implementations include support
581 for compression).</p>
584 <img src="../images/ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
585 <a id="figure3" name="figure3"><dfn>Figure 3</dfn></a>: SSL Record Protocol
589 <h3><a name="securehttp" id="securehttp">Securing HTTP Communication</a></h3>
591 <p>One common use of SSL is to secure Web HTTP communication between
592 a browser and a webserver. This does not preclude the use of
593 non-secured HTTP - the secure version (called HTTPS) is the same as
594 plain HTTP over SSL, but uses the URL scheme <code>https</code>
595 rather than <code>http</code>, and a different server port (by default,
596 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>
598 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
599 <div class="section">
600 <h2><a name="references" id="references">References</a></h2>
603 <dt><a id="AC96" name="AC96">[AC96]</a></dt>
604 <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
605 1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for various other materials by Bruce
608 <dt><a id="ASN1" name="ASN1">[ASN1]</a></dt>
609 <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
610 One (ASN.1)</q>, last updated 2008. See <a href="http://www.itu.int/ITU-T/asn1/">http://www.itu.int/ITU-T/asn1/</a>.
613 <dt><a id="X509" name="X509">[X509]</a></dt>
614 <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
615 Framework</q>. For references, see <a href="http://en.wikipedia.org/wiki/X.509">http://en.wikipedia.org/wiki/X.509</a>.
618 <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
619 <dd><q>Public Key Cryptography Standards (PKCS)</q>,
620 RSA Laboratories Technical Notes, See <a href="http://www.rsasecurity.com/rsalabs/pkcs/">http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
622 <dt><a id="MIME" name="MIME">[MIME]</a></dt>
623 <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
624 (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
625 See for instance <a href="http://tools.ietf.org/html/rfc2045">http://tools.ietf.org/html/rfc2045</a>.</dd>
627 <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
628 <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
629 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>
631 <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
632 <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
633 1999. See <a href="http://ietf.org/rfc/rfc2246.txt">http://ietf.org/rfc/rfc2246.txt</a>.</dd>
635 <dt><a id="TLS11" name="TLS11">[TLS11]</a></dt>
636 <dd><q>The TLS Protocol Version 1.1</q>,
637 2006. See <a href="http://tools.ietf.org/html/rfc4346">http://tools.ietf.org/html/rfc4346</a>.</dd>
639 <dt><a id="TLS12" name="TLS12">[TLS12]</a></dt>
640 <dd><q>The TLS Protocol Version 1.2</q>,
641 2008. See <a href="http://tools.ietf.org/html/rfc5246">http://tools.ietf.org/html/rfc5246</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="../fr/ssl/ssl_intro.html" hreflang="fr" rel="alternate" title="Français"> fr </a> |
647 <a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p>
648 </div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Comments</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
649 <script type="text/javascript"><!--//--><![CDATA[//><!--
650 var comments_shortname = 'httpd';
651 var comments_identifier = 'http://httpd.apache.org/docs/trunk/ssl/ssl_intro.html';
653 if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
654 d.write('<div id="comments_thread"><\/div>');
655 var s = d.createElement('script');
656 s.type = 'text/javascript';
658 s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
659 (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
662 d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
664 })(window, document);
665 //--><!]]></script></div><div id="footer">
666 <p class="apache">Copyright 2016 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>
667 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
668 if (typeof(prettyPrint) !== 'undefined') {