home *** CD-ROM | disk | FTP | other *** search
/ Cricao de Sites - 650 Layouts Prontos / WebMasters.iso / Servidores / apache_2.2.8-win32-x86-no_ssl.msi / Data1.cab / _95A23EF4A1422CDD0624BE8AEBF6D947 < prev    next >
Extensible Markup Language  |  2007-12-06  |  35KB  |  650 lines
  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
  7.       -->
  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>
  18. <div id="path">
  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>
  20. <div class="toplang">
  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>
  23. </div>
  24.  
  25. <blockquote>
  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>
  29.  
  30. <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
  31. Computer Networks"</p>
  32. </blockquote>
  33.  
  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>
  41.  
  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>
  50. </div>
  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>
  55. </ul></div>
  56. <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
  57. <div class="section">
  58. <h2><a name="cryptographictech" id="cryptographictech">Cryptographic Techniques</a></h2>
  59.  
  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>
  65.  
  66. <h3><a name="cryptographicalgo" id="cryptographicalgo">Cryptographic Algorithms</a></h3>
  67.  
  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
  77.     effort.</p>
  78.  
  79.     <p>There are two categories of cryptographic algorithms: conventional
  80.     and public key.</p>
  81.  
  82.     <dl>
  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 
  91.     problematic.</dd>
  92.  
  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>
  100.     </dl>
  101.  
  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 them using their public key. Only the bank will be able to
  106.     decrypt them.</p>
  107.  
  108.  
  109. <h3><a name="messagedigests" id="messagedigests">Message Digests</a></h3>
  110.  
  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
  119.     intact.</p>
  120.  
  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>
  130.  
  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>
  136.     
  137.     <p>One way to send the digest securely is to include it in a digital 
  138.     signature.</p>
  139.  
  140.  
  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>
  146.  
  147. <p>Digital signatures are created by encrypting a digest of the message, and
  148. other information (such as a sequence number) with the sender's private key.
  149. Though anyone can <em>decrypt</em> the signature using the public key, only the
  150. sender knows the private key. This means that only the sender can have signed
  151. the message. Including the digest in the signature means the signature is only
  152. good for that message; it also ensures the integrity of the message since no one
  153. 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>
  158.  
  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>
  162.  
  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>
  169.  
  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>
  175.  
  176. <h3><a name="certificatecontents" id="certificatecontents">Certificate Contents</a></h3>
  177.  
  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>
  187.  
  188.     <h4><a name="table1" id="table1">Table 1: Certificate Information</a></h4>
  189.     
  190.     <table>
  191.     
  192.     <tr><th>Subject</th>
  193.         <td>Distinguished Name, Public Key</td></tr>
  194.     <tr><th>Issuer</th>
  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>
  202.     </table>
  203.     
  204.  
  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
  210.     2</a>).</p>
  211.  
  212.     <h4><a name="table2" id="table2">Table 2: Distinguished Name Information</a></h4>
  213.     
  214.     <table class="bordered">
  215.     
  216.     <tr><th>DN Field</th>
  217.         <th>Abbrev.</th>
  218.         <th>Description</th>
  219.         <th>Example</th></tr>
  220.     <tr><td>Common Name</td>
  221.         <td>CN</td>
  222.         <td>Name being certified</td>
  223.         <td>CN=Joe Average</td></tr>
  224.     <tr><td>Organization or Company</td>
  225.         <td>O</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>
  229.         <td>OU</td>
  230.         <td>Name is associated with this <br />organization unit, such
  231.         as a department</td>
  232.         <td>OU=Research Institute</td></tr>
  233.     <tr><td>City/Locality</td>
  234.         <td>L</td>
  235.         <td>Name is located in this City</td>
  236.         <td>L=Snake City</td></tr>
  237.     <tr><td>State/Province</td>
  238.         <td>ST</td>
  239.         <td>Name is located in this State/Province</td>
  240.         <td>ST=Desert</td></tr>
  241.     <tr><td>Country</td>
  242.         <td>C</td>
  243.         <td>Name is located in this Country (ISO code)</td>
  244.         <td>C=XZ</td></tr>
  245.     </table>
  246.     
  247.  
  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>
  255.  
  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>
  267.  
  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>
  286.  
  287.  
  288. <h3><a name="certificateauthorities" id="certificateauthorities">Certificate Authorities</a></h3>
  289.  
  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 request claims she is.</p>
  296.  
  297.     <h4><a name="certificatechains" id="certificatechains">Certificate Chains</a></h4>
  298.     
  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
  305.         in the chain.</p>
  306.     
  307.  
  308.     <h4><a name="rootlevelca" id="rootlevelca">Creating a Root-Level CA</a></h4>
  309.     
  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>
  322.  
  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>
  326.  
  327.         <ul>
  328.         <li>Verifying certificate requests</li>
  329.         <li>Processing certificate requests</li>
  330.         <li>Issuing and managing certificates</li>
  331.         </ul>
  332.  
  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>
  337.     
  338.  
  339.     <h4><a name="certificatemanagement" id="certificatemanagement">Certificate Management</a></h4>
  340.     
  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> 
  348.  
  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>
  359.  
  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>
  367.         </div>
  368.     
  369.  
  370.  
  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>
  374.  
  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
  380. for privacy.</p>
  381.  
  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>
  388.  
  389. <h3><a name="table4" id="table4">Table 4: Versions of the SSL protocol</a></h3>
  390.  
  391.     <table class="bordered">
  392.     
  393.     <tr><th>Version</th>
  394.         <th>Source</th>
  395.         <th>Description</th>
  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 />
  401.         - MS IE 3.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
  414.         alert messages.</td>
  415.         <td>- Lynx/2.8+OpenSSL</td></tr>
  416.     </table>
  417.  
  418.  
  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>
  429.  
  430. <h3><a name="session" id="session">Establishing a Session</a></h3>
  431.  
  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>
  439.  
  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>
  447.     </div>
  448.  
  449.     <p class="figure">
  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>
  453.  
  454.     <p>The elements of the handshake sequence, as used by the client and
  455.     server, are listed below:</p>
  456.  
  457.     <ol>
  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>
  462.     </ol>
  463.  
  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>
  468.  
  469.     <ul>
  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>
  473.     </ul>
  474.  
  475.     <p>These three elements are described in the sections that follow.</p>
  476.  
  477.  
  478. <h3><a name="keyexchange" id="keyexchange">Key Exchange Method</a></h3>
  479.  
  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>
  487.  
  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>
  493.  
  494.  
  495. <h3><a name="ciphertransfer" id="ciphertransfer">Cipher for Data Transfer</a></h3>
  496.  
  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
  500.     encrypt:</p>
  501.  
  502.     <ul>
  503.     <li>No encryption</li>
  504.     <li>Stream Ciphers
  505.         <ul>
  506.         <li>RC4 with 40-bit keys</li>
  507.         <li>RC4 with 128-bit keys</li>
  508.         </ul></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>
  516.         </ul></li>
  517.     </ul>
  518.  
  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>
  526.  
  527.  
  528. <h3><a name="digestfuntion" id="digestfuntion">Digest Function</a></h3>
  529.  
  530.     <p>The choice of digest function determines how a digest is created
  531.     from a record unit. SSL supports the following:</p>
  532.  
  533.     <ul>
  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>
  537.     </ul>
  538.  
  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>
  542.  
  543.  
  544. <h3><a name="handshake" id="handshake">Handshake Sequence Protocol</a></h3>
  545.  
  546.     <p>The handshake sequence uses three protocols:</p>
  547.  
  548.     <ul>
  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>
  555.     </ul>
  556.  
  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>
  563.  
  564.     <p class="figure">
  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
  567.     </p>
  568.  
  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
  574.     established.</p>
  575.  
  576.  
  577. <h3><a name="datatransfer" id="datatransfer">Data Transfer</a></h3>
  578.  
  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>
  587.  
  588.     <p class="figure">
  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
  591.     </p>
  592.  
  593.  
  594. <h3><a name="securehttp" id="securehttp">Securing HTTP Communication</a></h3>
  595.  
  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>
  602.  
  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>
  606.  
  607. <dl>
  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
  611. Schneier.</dd>
  612.  
  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>.
  616. </dd>
  617.  
  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>.
  621. </dd>
  622.  
  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>
  626.  
  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>
  631.  
  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>
  634.  
  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>
  638.  
  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>
  642. </dl>
  643. </div></div>
  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 2007 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>
  650. </body></html>