granicus.if.org Git - apache/blob - docs/manual/ssl/ssl_intro.html.en

   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" />
   5 <!--
   6         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   7               This file is generated from xml source: DO NOT EDIT
   8         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   9       -->
  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">
  15 </script>
  16
  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="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div>
  23 <div id="path">
  24 <a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">HTTP Server</a> &gt; <a href="http://httpd.apache.org/docs/">Documentation</a> &gt; <a href="../">Version 2.5</a> &gt; <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS Strong Encryption: An Introduction</h1>
  25 <div class="toplang">
  26 <p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" title="English">&nbsp;en&nbsp;</a> |
  27 <a href="../fr/ssl/ssl_intro.html" hreflang="fr" rel="alternate" title="Français">&nbsp;fr&nbsp;</a> |
  28 <a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a></p>
  29 </div>
  30
  31
  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>
  39 </div>
  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>
  46 <div class="section">
  47 <h2><a name="cryptographictech" id="cryptographictech">Cryptographic Techniques</a></h2>
  48
  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>
  54
  55 <h3><a name="cryptographicalgo" id="cryptographicalgo">Cryptographic Algorithms</a></h3>
  56
  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
  66     effort.</p>
  67
  68     <p>There are two categories of cryptographic algorithms: conventional
  69     and public key.</p>
  70
  71     <dl>
  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
  80     problematic.</dd>
  81
  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>
  89     </dl>
  90
  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
  95     decrypt them.</p>
  96
  97
  98 <h3><a name="messagedigests" id="messagedigests">Message Digests</a></h3>
  99
 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
 108     intact.</p>
 109
 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>
 119
 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>
 125
 126     <p>One way to send the digest securely is to include it in a digital
 127     signature.</p>
 128
 129
 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>
 135
 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>
 147
 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>
 151
 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>
 158
 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>
 164
 165 <h3><a name="certificatecontents" id="certificatecontents">Certificate Contents</a></h3>
 166
 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>
 176
 177     <h4><a name="table1" id="table1">Table 1: Certificate Information</a></h4>
 178
 179     <table>
 180
 181     <tr><th>Subject</th>
 182         <td>Distinguished Name, Public Key</td></tr>
 183     <tr><th>Issuer</th>
 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>
 191     </table>
 192
 193
 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
 199     2</a>).</p>
 200
 201     <h4><a name="table2" id="table2">Table 2: Distinguished Name Information</a></h4>
 202
 203     <table class="bordered">
 204
 205     <tr><th>DN Field</th>
 206         <th>Abbrev.</th>
 207         <th>Description</th>
 208         <th>Example</th></tr>
 209     <tr><td>Common Name</td>
 210         <td>CN</td>
 211         <td>Name being certified</td>
 212         <td>CN=Joe Average</td></tr>
 213     <tr><td>Organization or Company</td>
 214         <td>O</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>
 218         <td>OU</td>
 219         <td>Name is associated with this <br />organization unit, such
 220         as a department</td>
 221         <td>OU=Research Institute</td></tr>
 222     <tr><td>City/Locality</td>
 223         <td>L</td>
 224         <td>Name is located in this City</td>
 225         <td>L=Snake City</td></tr>
 226     <tr><td>State/Province</td>
 227         <td>ST</td>
 228         <td>Name is located in this State/Province</td>
 229         <td>ST=Desert</td></tr>
 230     <tr><td>Country</td>
 231         <td>C</td>
 232         <td>Name is located in this Country (ISO code)</td>
 233         <td>C=XZ</td></tr>
 234     </table>
 235
 236
 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>
 244
 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>
 256
 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>
 275
 276
 277 <h3><a name="certificateauthorities" id="certificateauthorities">Certificate Authorities</a></h3>
 278
 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>
 285
 286     <h4><a name="certificatechains" id="certificatechains">Certificate Chains</a></h4>
 287
 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
 294         in the chain.</p>
 295
 296
 297     <h4><a name="rootlevelca" id="rootlevelca">Creating a Root-Level CA</a></h4>
 298
 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>
 311
 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>
 315
 316         <ul>
 317         <li>Verifying certificate requests</li>
 318         <li>Processing certificate requests</li>
 319         <li>Issuing and managing certificates</li>
 320         </ul>
 321
 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>
 326
 327
 328     <h4><a name="certificatemanagement" id="certificatemanagement">Certificate Management</a></h4>
 329
 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>
 337
 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>
 348
 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>
 356         </div>
 357
 358
 359
 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>
 363
 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
 369 for privacy.</p>
 370
 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>
 377
 378 <h3><a name="table4" id="table4">Table 4: Versions of the SSL protocol</a></h3>
 379
 380     <table class="bordered">
 381
 382     <tr><th>Version</th>
 383         <th>Source</th>
 384         <th>Description</th>
 385     </tr>
 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>
 389     </tr>
 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>
 394     </tr>
 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
 399         alert messages.</td>
 400     </tr>
 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
 404         (CBC) attacks.</td>
 405     </tr>
 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.1 deprecating MD5 as hash, and adding incompatibility
 409         to SSL so it will never negotiate the use of SSLv2.</td>
 410     </tr>
 411     </table>
 412
 413
 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>
 424
 425 <h3><a name="session" id="session">Establishing a Session</a></h3>
 426
 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>
 434
 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>
 442     </div>
 443
 444     <p class="figure">
 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>
 448
 449     <p>The elements of the handshake sequence, as used by the client and
 450     server, are listed below:</p>
 451
 452     <ol>
 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>
 457     </ol>
 458
 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>
 463
 464     <ul>
 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>
 468     </ul>
 469
 470     <p>These three elements are described in the sections that follow.</p>
 471
 472
 473 <h3><a name="keyexchange" id="keyexchange">Key Exchange Method</a></h3>
 474
 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>
 482
 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>
 488
 489
 490 <h3><a name="ciphertransfer" id="ciphertransfer">Cipher for Data Transfer</a></h3>
 491
 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
 495     encrypt:</p>
 496
 497     <ul>
 498     <li>No encryption</li>
 499     <li>Stream Ciphers
 500         <ul>
 501         <li>RC4 with 40-bit keys</li>
 502         <li>RC4 with 128-bit keys</li>
 503         </ul></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>
 511         </ul></li>
 512     </ul>
 513
 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>
 521
 522
 523 <h3><a name="digestfunction" id="digestfunction">Digest Function</a></h3>
 524
 525     <p>The choice of digest function determines how a digest is created
 526     from a record unit. SSL supports the following:</p>
 527
 528     <ul>
 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>
 532     </ul>
 533
 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>
 537
 538
 539 <h3><a name="handshake" id="handshake">Handshake Sequence Protocol</a></h3>
 540
 541     <p>The handshake sequence uses three protocols:</p>
 542
 543     <ul>
 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>
 550     </ul>
 551
 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>
 558
 559     <p class="figure">
 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
 562     </p>
 563
 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
 569     established.</p>
 570
 571
 572 <h3><a name="datatransfer" id="datatransfer">Data Transfer</a></h3>
 573
 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>
 582
 583     <p class="figure">
 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
 586     </p>
 587
 588
 589 <h3><a name="securehttp" id="securehttp">Securing HTTP Communication</a></h3>
 590
 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>
 597
 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>
 601
 602 <dl>
 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
 606 Schneier.</dd>
 607
 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>.
 611 </dd>
 612
 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>.
 616 </dd>
 617
 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>
 621
 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>
 626
 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>
 630
 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>
 634
 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>
 638
 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>
 642 </dl>
 643 </div></div>
 644 <div class="bottomlang">
 645 <p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" title="English">&nbsp;en&nbsp;</a> |
 646 <a href="../fr/ssl/ssl_intro.html" hreflang="fr" rel="alternate" title="Français">&nbsp;fr&nbsp;</a> |
 647 <a href="../ja/ssl/ssl_intro.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</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&amp;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';
 652 (function(w, d) {
 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';
 657         s.async = true;
 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);
 660     }
 661     else {
 662         d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
 663     }
 664 })(window, document);
 665 //--><!]]></script></div><div id="footer">
 666 <p class="apache">Copyright 2017 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') {
 669     prettyPrint();
 670 }
 671 //--><!]]></script>
 672 </body></html>