httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From n.@apache.org
Subject cvs commit: httpd-2.0/docs/manual/ssl ssl_howto.html.en ssl_howto.xml ssl_intro.html.en ssl_intro.xml index.html.en index.html.ja.jis index.xml ssl_compat.html.en ssl_compat.xml ssl_faq.html.en ssl_faq.xml ssl_glossary.html ssl_howto.html ssl_intro.html
Date Sun, 29 Sep 2002 00:11:28 GMT
nd          2002/09/28 17:11:28

  Modified:    docs/manual/ssl index.html.en index.html.ja.jis index.xml
                        ssl_compat.html.en ssl_compat.xml ssl_faq.html.en
                        ssl_faq.xml
  Added:       docs/manual/ssl ssl_howto.html.en ssl_howto.xml
                        ssl_intro.html.en ssl_intro.xml
  Removed:     docs/manual/ssl ssl_glossary.html ssl_howto.html
                        ssl_intro.html
  Log:
  New SSL XML, part two.
  
  Submitted by: Thomas Sjögren <thomas@northernsecurity.net>
  
  [This is also not the original submission. I revised a lot
  of things (structure, markup etc.)]
  
  other files: style & markup fine tuning
  
  Revision  Changes    Path
  1.5       +1 -1      httpd-2.0/docs/manual/ssl/index.html.en
  
  Index: index.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/index.html.en,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.html.en	28 Sep 2002 03:47:35 -0000	1.4
  +++ index.html.en	29 Sep 2002 00:11:28 -0000	1.5
  @@ -16,7 +16,7 @@
   <li><a href="ssl_compat.html">Compatibility</a></li>
   <li><a href="ssl_howto.html">How-To</a></li>
   <li><a href="ssl_faq.html">Frequently Asked Questions</a></li>
  -<li><a href="ssl_glossary.html">Glossary</a></li>
  +<li><a href="../glossary.html">Glossary</a></li>
   </ul>
   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="mod-ssl" id="mod-ssl">mod_ssl</a></h2>
   <p>Extensive documentation on the directives and environment variables
  
  
  
  1.3       +1 -1      httpd-2.0/docs/manual/ssl/index.html.ja.jis
  
  Index: index.html.ja.jis
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/index.html.ja.jis,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- index.html.ja.jis	26 Jul 2002 08:10:41 -0000	1.2
  +++ index.html.ja.jis	29 Sep 2002 00:11:28 -0000	1.3
  @@ -27,7 +27,7 @@
   <li><a href="ssl_compat.html">$B8_49@-(B</a></li>
   <li><a href="ssl_howto.html">How-To</a></li>
   <li><a href="ssl_faq.html">$B$h$/$"$k<ALd(B</a></li>
  -<li><a href="ssl_glossary.html">$BMQ8l(B</a></li>
  +<li><a href="../glossary.html">$BMQ8l(B</a></li>
   </ul>
   
   <p>$B$3$N%b%8%e!<%k$GDs6!$5$l$k%G%#%l%/%F%#%V$d4D6-JQ?t$K4X$9$k(B
  
  
  
  1.2       +1 -1      httpd-2.0/docs/manual/ssl/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml	28 Sep 2002 03:47:35 -0000	1.1
  +++ index.xml	29 Sep 2002 00:11:28 -0000	1.2
  @@ -21,7 +21,7 @@
   <li><a href="ssl_compat.html">Compatibility</a></li>
   <li><a href="ssl_howto.html">How-To</a></li>
   <li><a href="ssl_faq.html">Frequently Asked Questions</a></li>
  -<li><a href="ssl_glossary.html">Glossary</a></li>
  +<li><a href="../glossary.html">Glossary</a></li>
   </ul>
   </section>
   
  
  
  
  1.2       +61 -92    httpd-2.0/docs/manual/ssl/ssl_compat.html.en
  
  Index: ssl_compat.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_compat.html.en,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ssl_compat.html.en	28 Sep 2002 03:47:35 -0000	1.1
  +++ ssl_compat.html.en	29 Sep 2002 00:11:28 -0000	1.2
  @@ -8,7 +8,7 @@
   <blockquote>
   <p>All PCs are compatible. But some of
   them are more compatible than others.</p>
  -<p class="cite">--<cite>Unknown</cite></p>
  +<p class="cite">-- <cite>Unknown</cite></p>
   </blockquote>
   
   <p>
  @@ -42,74 +42,57 @@
   
   <h3><a name="table1" id="table1">Table 1: Configuration Directive Mapping</a></h3>
   
  -<table>
  -<tr><th>Old Directive</th><th>mod_ssl Directive</th><th>Comment</th></tr>
  -
  -<tr><th colspan="3">Apache-SSL 1.x &amp; mod_ssl 2.0.x compatibility:</th></tr>
  +<table><tr class="header"><th>Old Directive</th><th>mod_ssl Directive</th><th>Comment</th></tr>
  +<tr class="header"><th colspan="3">Apache-SSL 1.x &amp; mod_ssl 2.0.x compatibility:</th></tr>
   <tr><td><code>SSLEnable</code></td><td><code>SSLEngine on</code></td><td>compactified</td></tr>
  -<tr><td><code>SSLDisable</code></td><td><code>SSLEngine off</code></td><td>compactified</td></tr>
  +<tr class="odd"><td><code>SSLDisable</code></td><td><code>SSLEngine off</code></td><td>compactified</td></tr>
   <tr><td><code>SSLLogFile</code> <em>file</em></td><td><code>SSLLog</code> <em>file</em></td><td>compactified</td></tr>
  -
  -<tr><td><code>SSLRequiredCiphers</code> <em>spec</em></td><td><code>SSLCipherSuite</code> <em>spec</em></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSLRequiredCiphers</code> <em>spec</em></td><td><code>SSLCipherSuite</code> <em>spec</em></td><td>renamed</td></tr>
   <tr><td><code>SSLRequireCipher</code> <em>c1</em> ...</td><td><code>SSLRequire %{SSL_CIPHER} in {"</code><em>c1</em><code>", 
   ...}</code></td><td>generalized</td></tr>
  -
  -<tr><td><code>SSLBanCipher</code> <em>c1</em> ...</td><td><code>SSLRequire not (%{SSL_CIPHER} in {"</code><em>c1</em><code>", 
  +<tr class="odd"><td><code>SSLBanCipher</code> <em>c1</em> ...</td><td><code>SSLRequire not (%{SSL_CIPHER} in {"</code><em>c1</em><code>", 
   ...})</code></td><td>generalized</td></tr>
   <tr><td><code>SSLFakeBasicAuth</code></td><td><code>SSLOptions +FakeBasicAuth</code></td><td>merged</td></tr>
  -<tr><td><code>SSLCacheServerPath</code> <em>dir</em></td><td>-</td><td>functionality removed</td></tr>
  -
  +<tr class="odd"><td><code>SSLCacheServerPath</code> <em>dir</em></td><td>-</td><td>functionality removed</td></tr>
   <tr><td><code>SSLCacheServerPort</code> <em>integer</em></td><td>-</td><td>functionality removed</td></tr>
  -<tr><th colspan="3">Apache-SSL 1.x compatibility:</th></tr>
  -<tr><td><code>SSLExportClientCertificates</code></td><td><code>SSLOptions +ExportCertData</code></td><td>merged</td></tr>
  +<tr class="header"><th colspan="3">Apache-SSL 1.x compatibility:</th></tr>
  +<tr class="odd"><td><code>SSLExportClientCertificates</code></td><td><code>SSLOptions +ExportCertData</code></td><td>merged</td></tr>
   <tr><td><code>SSLCacheServerRunDir</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  -
  -<tr><th colspan="3">Sioux 1.x compatibility:</th></tr>
  -<tr><td><code>SSL_CertFile</code> <em>file</em></td><td><code>SSLCertificateFile</code> <em>file</em></td><td>renamed</td></tr>
  +<tr class="header"><th colspan="3">Sioux 1.x compatibility:</th></tr>
  +<tr class="odd"><td><code>SSL_CertFile</code> <em>file</em></td><td><code>SSLCertificateFile</code> <em>file</em></td><td>renamed</td></tr>
   <tr><td><code>SSL_KeyFile</code> <em>file</em></td><td><code>SSLCertificateKeyFile</code> <em>file</em></td><td>renamed</td></tr>
  -
  -<tr><td><code>SSL_CipherSuite</code> <em>arg</em></td><td><code>SSLCipherSuite</code> <em>arg</em></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CipherSuite</code> <em>arg</em></td><td><code>SSLCipherSuite</code> <em>arg</em></td><td>renamed</td></tr>
   <tr><td><code>SSL_X509VerifyDir</code> <em>arg</em></td><td><code>SSLCACertificatePath</code> <em>arg</em></td><td>renamed</td></tr>
  -<tr><td><code>SSL_Log</code> <em>file</em></td><td><code>SSLLogFile</code> <em>file</em></td><td>renamed</td></tr>
  -
  +<tr class="odd"><td><code>SSL_Log</code> <em>file</em></td><td><code>SSLLogFile</code> <em>file</em></td><td>renamed</td></tr>
   <tr><td><code>SSL_Connect</code> <em>flag</em></td><td><code>SSLEngine</code> <em>flag</em></td><td>renamed</td></tr>
  -<tr><td><code>SSL_ClientAuth</code> <em>arg</em></td><td><code>SSLVerifyClient</code> <em>arg</em></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_ClientAuth</code> <em>arg</em></td><td><code>SSLVerifyClient</code> <em>arg</em></td><td>renamed</td></tr>
   <tr><td><code>SSL_X509VerifyDepth</code> <em>arg</em></td><td><code>SSLVerifyDepth</code> <em>arg</em></td><td>renamed</td></tr>
  -
  -<tr><td><code>SSL_FetchKeyPhraseFrom</code> <em>arg</em></td><td>-</td><td>not directly mappable; use SSLPassPhraseDialog</td></tr>
  +<tr class="odd"><td><code>SSL_FetchKeyPhraseFrom</code> <em>arg</em></td><td>-</td><td>not directly mappable; use SSLPassPhraseDialog</td></tr>
   <tr><td><code>SSL_SessionDir</code> <em>dir</em></td><td>-</td><td>not directly mappable; use SSLSessionCache</td></tr>
  -<tr><td><code>SSL_Require</code> <em>expr</em></td><td>-</td><td>not directly mappable; use SSLRequire</td></tr>
  -
  +<tr class="odd"><td><code>SSL_Require</code> <em>expr</em></td><td>-</td><td>not directly mappable; use SSLRequire</td></tr>
   <tr><td><code>SSL_CertFileType</code> <em>arg</em></td><td>-</td><td>functionality not supported</td></tr>
  -<tr><td><code>SSL_KeyFileType</code> <em>arg</em></td><td>-</td><td>functionality not supported</td></tr>
  +<tr class="odd"><td><code>SSL_KeyFileType</code> <em>arg</em></td><td>-</td><td>functionality not supported</td></tr>
   <tr><td><code>SSL_X509VerifyPolicy</code> <em>arg</em></td><td>-</td><td>functionality not supported</td></tr>
  -
  -<tr><td><code>SSL_LogX509Attributes</code> <em>arg</em></td><td>-</td><td>functionality not supported</td></tr>
  -<tr><th colspan="3">Stronghold 2.x compatibility:</th></tr>
  +<tr class="odd"><td><code>SSL_LogX509Attributes</code> <em>arg</em></td><td>-</td><td>functionality not supported</td></tr>
  +<tr class="header"><th colspan="3">Stronghold 2.x compatibility:</th></tr>
   <tr><td><code>StrongholdAccelerator</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  -<tr><td><code>StrongholdKey</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  -
  +<tr class="odd"><td><code>StrongholdKey</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
   <tr><td><code>StrongholdLicenseFile</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  -<tr><td><code>SSLFlag</code> <em>flag</em></td><td><code>SSLEngine</code> <em>flag</em></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSLFlag</code> <em>flag</em></td><td><code>SSLEngine</code> <em>flag</em></td><td>renamed</td></tr>
   <tr><td><code>SSLSessionLockFile</code> <em>file</em></td><td><code>SSLMutex</code> <em>file</em></td><td>renamed</td></tr>
  -
  -<tr><td><code>SSLCipherList</code> <em>spec</em></td><td><code>SSLCipherSuite</code> <em>spec</em></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSLCipherList</code> <em>spec</em></td><td><code>SSLCipherSuite</code> <em>spec</em></td><td>renamed</td></tr>
   <tr><td><code>RequireSSL</code></td><td><code>SSLRequireSSL</code></td><td>renamed</td></tr>
  -<tr><td><code>SSLErrorFile</code> <em>file</em></td><td>-</td><td>functionality not supported</td></tr>
  -
  +<tr class="odd"><td><code>SSLErrorFile</code> <em>file</em></td><td>-</td><td>functionality not supported</td></tr>
   <tr><td><code>SSLRoot</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  -<tr><td><code>SSL_CertificateLogDir</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  +<tr class="odd"><td><code>SSL_CertificateLogDir</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
   <tr><td><code>AuthCertDir</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  -
  -<tr><td><code>SSL_Group</code> <em>name</em></td><td>-</td><td>functionality not supported</td></tr>
  +<tr class="odd"><td><code>SSL_Group</code> <em>name</em></td><td>-</td><td>functionality not supported</td></tr>
   <tr><td><code>SSLProxyMachineCertPath</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  -<tr><td><code>SSLProxyMachineCertFile</code> <em>file</em></td><td>-</td><td>functionality not supported</td></tr>
  -
  +<tr class="odd"><td><code>SSLProxyMachineCertFile</code> <em>file</em></td><td>-</td><td>functionality not supported</td></tr>
   <tr><td><code>SSLProxyCACertificatePath</code> <em>dir</em></td><td>-</td><td>functionality not supported</td></tr>
  -<tr><td><code>SSLProxyCACertificateFile</code> <em>file</em></td><td>-</td><td>functionality not supported</td></tr>
  +<tr class="odd"><td><code>SSLProxyCACertificateFile</code> <em>file</em></td><td>-</td><td>functionality not supported</td></tr>
   <tr><td><code>SSLProxyVerifyDepth</code> <em>number</em></td><td>-</td><td>functionality not supported</td></tr>
  -
  -<tr><td><code>SSLProxyCipherList</code> <em>spec</em></td><td>-</td><td>functionality not supported</td></tr>
  +<tr class="odd"><td><code>SSLProxyCipherList</code> <em>spec</em></td><td>-</td><td>functionality not supported</td></tr>
   </table>
   
   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="variables" id="variables">Environment Variables</a></h2>
  @@ -119,85 +102,71 @@
   
   <h3><a name="table2" id="table2">Table 2: Environment Variable Derivation</a></h3>
   
  -<table>
  -<tr><th>Old Variable</th><th>mod_ssl Variable</th><th>Comment</th></tr>
  -
  +<table><tr class="header"><th>Old Variable</th><th>mod_ssl Variable</th><th>Comment</th></tr>
   <tr><td><code>SSL_PROTOCOL_VERSION</code></td><td><code>SSL_PROTOCOL</code></td><td>renamed</td></tr>
  -<tr><td><code>SSLEAY_VERSION</code></td><td><code>SSL_VERSION_LIBRARY</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSLEAY_VERSION</code></td><td><code>SSL_VERSION_LIBRARY</code></td><td>renamed</td></tr>
   <tr><td><code>HTTPS_SECRETKEYSIZE</code></td><td><code>SSL_CIPHER_USEKEYSIZE</code></td><td>renamed</td></tr>
  -<tr><td><code>HTTPS_KEYSIZE</code></td><td><code>SSL_CIPHER_ALGKEYSIZE</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>HTTPS_KEYSIZE</code></td><td><code>SSL_CIPHER_ALGKEYSIZE</code></td><td>renamed</td></tr>
   <tr><td><code>HTTPS_CIPHER</code></td><td><code>SSL_CIPHER</code></td><td>renamed</td></tr>
  -
  -<tr><td><code>HTTPS_EXPORT</code></td><td><code>SSL_CIPHER_EXPORT</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>HTTPS_EXPORT</code></td><td><code>SSL_CIPHER_EXPORT</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_KEY_SIZE</code></td><td><code>SSL_CIPHER_ALGKEYSIZE</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_CERTIFICATE</code></td><td><code>SSL_SERVER_CERT</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_CERTIFICATE</code></td><td><code>SSL_SERVER_CERT</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_CERT_START</code></td><td><code>SSL_SERVER_V_START</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_CERT_END</code></td><td><code>SSL_SERVER_V_END</code></td><td>renamed</td></tr>
  -
  +<tr class="odd"><td><code>SSL_SERVER_CERT_END</code></td><td><code>SSL_SERVER_V_END</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_CERT_SERIAL</code></td><td><code>SSL_SERVER_M_SERIAL</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_SIGNATURE_ALGORITHM</code></td><td><code>SSL_SERVER_A_SIG</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_SIGNATURE_ALGORITHM</code></td><td><code>SSL_SERVER_A_SIG</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_DN</code></td><td><code>SSL_SERVER_S_DN</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_CN</code></td><td><code>SSL_SERVER_S_DN_CN</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_CN</code></td><td><code>SSL_SERVER_S_DN_CN</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_EMAIL</code></td><td><code>SSL_SERVER_S_DN_Email</code></td><td>renamed</td></tr>
  -
  -<tr><td><code>SSL_SERVER_O</code></td><td><code>SSL_SERVER_S_DN_O</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_O</code></td><td><code>SSL_SERVER_S_DN_O</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_OU</code></td><td><code>SSL_SERVER_S_DN_OU</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_C</code></td><td><code>SSL_SERVER_S_DN_C</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_C</code></td><td><code>SSL_SERVER_S_DN_C</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_SP</code></td><td><code>SSL_SERVER_S_DN_SP</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_L</code></td><td><code>SSL_SERVER_S_DN_L</code></td><td>renamed</td></tr>
  -
  +<tr class="odd"><td><code>SSL_SERVER_L</code></td><td><code>SSL_SERVER_S_DN_L</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_IDN</code></td><td><code>SSL_SERVER_I_DN</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_ICN</code></td><td><code>SSL_SERVER_I_DN_CN</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_ICN</code></td><td><code>SSL_SERVER_I_DN_CN</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_IEMAIL</code></td><td><code>SSL_SERVER_I_DN_Email</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_IO</code></td><td><code>SSL_SERVER_I_DN_O</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_IO</code></td><td><code>SSL_SERVER_I_DN_O</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_IOU</code></td><td><code>SSL_SERVER_I_DN_OU</code></td><td>renamed</td></tr>
  -
  -<tr><td><code>SSL_SERVER_IC</code></td><td><code>SSL_SERVER_I_DN_C</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_IC</code></td><td><code>SSL_SERVER_I_DN_C</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SERVER_ISP</code></td><td><code>SSL_SERVER_I_DN_SP</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SERVER_IL</code></td><td><code>SSL_SERVER_I_DN_L</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_IL</code></td><td><code>SSL_SERVER_I_DN_L</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_CERTIFICATE</code></td><td><code>SSL_CLIENT_CERT</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_CLIENT_CERT_START</code></td><td><code>SSL_CLIENT_V_START</code></td><td>renamed</td></tr>
  -
  +<tr class="odd"><td><code>SSL_CLIENT_CERT_START</code></td><td><code>SSL_CLIENT_V_START</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_CERT_END</code></td><td><code>SSL_CLIENT_V_END</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_CLIENT_CERT_SERIAL</code></td><td><code>SSL_CLIENT_M_SERIAL</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_CERT_SERIAL</code></td><td><code>SSL_CLIENT_M_SERIAL</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_SIGNATURE_ALGORITHM</code></td><td><code>SSL_CLIENT_A_SIG</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_CLIENT_DN</code></td><td><code>SSL_CLIENT_S_DN</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_DN</code></td><td><code>SSL_CLIENT_S_DN</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_CN</code></td><td><code>SSL_CLIENT_S_DN_CN</code></td><td>renamed</td></tr>
  -
  -<tr><td><code>SSL_CLIENT_EMAIL</code></td><td><code>SSL_CLIENT_S_DN_Email</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_EMAIL</code></td><td><code>SSL_CLIENT_S_DN_Email</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_O</code></td><td><code>SSL_CLIENT_S_DN_O</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_CLIENT_OU</code></td><td><code>SSL_CLIENT_S_DN_OU</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_OU</code></td><td><code>SSL_CLIENT_S_DN_OU</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_C</code></td><td><code>SSL_CLIENT_S_DN_C</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_CLIENT_SP</code></td><td><code>SSL_CLIENT_S_DN_SP</code></td><td>renamed</td></tr>
  -
  +<tr class="odd"><td><code>SSL_CLIENT_SP</code></td><td><code>SSL_CLIENT_S_DN_SP</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_L</code></td><td><code>SSL_CLIENT_S_DN_L</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_CLIENT_IDN</code></td><td><code>SSL_CLIENT_I_DN</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_IDN</code></td><td><code>SSL_CLIENT_I_DN</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_ICN</code></td><td><code>SSL_CLIENT_I_DN_CN</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_CLIENT_IEMAIL</code></td><td><code>SSL_CLIENT_I_DN_Email</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_IEMAIL</code></td><td><code>SSL_CLIENT_I_DN_Email</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_IO</code></td><td><code>SSL_CLIENT_I_DN_O</code></td><td>renamed</td></tr>
  -
  -<tr><td><code>SSL_CLIENT_IOU</code></td><td><code>SSL_CLIENT_I_DN_OU</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_IOU</code></td><td><code>SSL_CLIENT_I_DN_OU</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_IC</code></td><td><code>SSL_CLIENT_I_DN_C</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_CLIENT_ISP</code></td><td><code>SSL_CLIENT_I_DN_SP</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_ISP</code></td><td><code>SSL_CLIENT_I_DN_SP</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_CLIENT_IL</code></td><td><code>SSL_CLIENT_I_DN_L</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_EXPORT</code></td><td><code>SSL_CIPHER_EXPORT</code></td><td>renamed</td></tr>
  -
  +<tr class="odd"><td><code>SSL_EXPORT</code></td><td><code>SSL_CIPHER_EXPORT</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_KEYSIZE</code></td><td><code>SSL_CIPHER_ALGKEYSIZE</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_SECKEYSIZE</code></td><td><code>SSL_CIPHER_USEKEYSIZE</code></td><td>renamed</td></tr>
  +<tr class="odd"><td><code>SSL_SECKEYSIZE</code></td><td><code>SSL_CIPHER_USEKEYSIZE</code></td><td>renamed</td></tr>
   <tr><td><code>SSL_SSLEAY_VERSION</code></td><td><code>SSL_VERSION_LIBRARY</code></td><td>renamed</td></tr>
  -<tr><td><code>SSL_STRONG_CRYPTO</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  +<tr class="odd"><td><code>SSL_STRONG_CRYPTO</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
   <tr><td><code>SSL_SERVER_KEY_EXP</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  -
  -<tr><td><code>SSL_SERVER_KEY_ALGORITHM</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_KEY_ALGORITHM</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
   <tr><td><code>SSL_SERVER_KEY_SIZE</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  -<tr><td><code>SSL_SERVER_SESSIONDIR</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_SESSIONDIR</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
   <tr><td><code>SSL_SERVER_CERTIFICATELOGDIR</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  -<tr><td><code>SSL_SERVER_CERTFILE</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  -
  +<tr class="odd"><td><code>SSL_SERVER_CERTFILE</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
   <tr><td><code>SSL_SERVER_KEYFILE</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  -<tr><td><code>SSL_SERVER_KEYFILETYPE</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  +<tr class="odd"><td><code>SSL_SERVER_KEYFILETYPE</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
   <tr><td><code>SSL_CLIENT_KEY_EXP</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  -<tr><td><code>SSL_CLIENT_KEY_ALGORITHM</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
  +<tr class="odd"><td><code>SSL_CLIENT_KEY_ALGORITHM</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
   <tr><td><code>SSL_CLIENT_KEY_SIZE</code></td><td><code>-</code></td><td>Not supported by mod_ssl</td></tr>
   </table>
   
  
  
  
  1.2       +1 -1      httpd-2.0/docs/manual/ssl/ssl_compat.xml
  
  Index: ssl_compat.xml
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_compat.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ssl_compat.xml	28 Sep 2002 03:47:35 -0000	1.1
  +++ ssl_compat.xml	29 Sep 2002 00:11:28 -0000	1.2
  @@ -10,7 +10,7 @@
   <blockquote>
   <p>All PCs are compatible. But some of
   them are more compatible than others.</p>
  -<p class="cite">--<cite>Unknown</cite></p>
  +<p class="cite">-- <cite>Unknown</cite></p>
   </blockquote>
   
   <p>
  
  
  
  1.2       +7 -5      httpd-2.0/docs/manual/ssl/ssl_faq.html.en
  
  Index: ssl_faq.html.en
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_faq.html.en,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ssl_faq.html.en	28 Sep 2002 03:47:35 -0000	1.1
  +++ ssl_faq.html.en	29 Sep 2002 00:11:28 -0000	1.2
  @@ -8,7 +8,7 @@
   <blockquote>
   <p>The wise man doesn't give the right answers,
   he poses the right questions.</p>
  -<p class="cite">--<cite>Claude Levi-Strauss</cite></p>
  +<p class="cite">-- <cite>Claude Levi-Strauss</cite></p>
   
   </blockquote>
   <p>This chapter is a collection of frequently asked questions (FAQ) and
  @@ -381,8 +381,10 @@
       enabled for the context of your CGI/SSI requests.</p>
   
   
  -<h3><a name="relative" id="relative">How can I use relative hyperlinks to switch between HTTP and HTTPS?</a></h3>
  -<p>Usually you have to use fully-qualified hyperlinks because
  +<h3><a name="relative" id="relative">How can I use relative hyperlinks to switch between HTTP and
  +HTTPS?</a></h3>
  +
  +    <p>Usually you have to use fully-qualified hyperlinks because
       you have to change the URL scheme. But with the help of some URL
       manipulations through mod_rewrite you can achieve the same effect while
       you still can use relative URLs:</p>
  @@ -392,8 +394,8 @@
       RewriteRule   ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1  [R,L]
       </code></p></div>
   
  -    This rewrite ruleset lets you use hyperlinks of the form
  -    <div class="example"><p><code>&lt;a href="document.html:SSL"&gt;</code></p></div>
  +    <p>This rewrite ruleset lets you use hyperlinks of the form
  +    <code>&lt;a href="document.html:SSL"&gt;</code></p>
   
   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="aboutcerts" id="aboutcerts">About Certificates</a></h2>
   <ul>
  
  
  
  1.2       +7 -5      httpd-2.0/docs/manual/ssl/ssl_faq.xml
  
  Index: ssl_faq.xml
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/ssl/ssl_faq.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ssl_faq.xml	28 Sep 2002 03:47:35 -0000	1.1
  +++ ssl_faq.xml	29 Sep 2002 00:11:28 -0000	1.2
  @@ -10,7 +10,7 @@
   <blockquote>
   <p>The wise man doesn't give the right answers,
   he poses the right questions.</p>
  -<p class="cite">--<cite>Claude Levi-Strauss</cite></p>
  +<p class="cite">-- <cite>Claude Levi-Strauss</cite></p>
   
   </blockquote>
   <p>This chapter is a collection of frequently asked questions (FAQ) and
  @@ -400,8 +400,10 @@
       enabled for the context of your CGI/SSI requests.</p>
   </section>
   
  -<section id="relative"><title>How can I use relative hyperlinks to switch between HTTP and HTTPS?</title>
  -<p>Usually you have to use fully-qualified hyperlinks because
  +<section id="relative">
  +<title>How can I use relative hyperlinks to switch between HTTP and
  +HTTPS?</title>
  +    <p>Usually you have to use fully-qualified hyperlinks because
       you have to change the URL scheme. But with the help of some URL
       manipulations through mod_rewrite you can achieve the same effect while
       you still can use relative URLs:</p>
  @@ -411,8 +413,8 @@
       RewriteRule   ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1  [R,L]
       </example>
   
  -    This rewrite ruleset lets you use hyperlinks of the form
  -    <example>&lt;a href="document.html:SSL"&gt;</example>
  +    <p>This rewrite ruleset lets you use hyperlinks of the form
  +    <code>&lt;a href="document.html:SSL"&gt;</code></p>
   </section>
   </section>
   <!-- configuration -->
  
  
  
  1.1                  httpd-2.0/docs/manual/ssl/ssl_howto.html.en
  
  Index: ssl_howto.html.en
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                This file is generated from xml source: DO NOT EDIT
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        --><title>SSL/TLS Strong Encryption: How-To - Apache HTTP Server</title><link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /><link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /><link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link href="../images/favicon.ico" rel="shortcut icon" /></head><body id="manual-page"><div id="page-header"><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><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></div><div class="up"><a href="./"><img title="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div><div id="path"><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-project/">Documentation</a> &gt; <a href="../">Version 2.0</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS Strong Encryption: How-To</h1>
  <blockquote>
  <p>The solution of this problem is trivial
  and is left as an exercise for the reader.</p>
  
  <p class="cite">-- <cite>Standard textbook cookie</cite></p>
  </blockquote>
  
  <p>How to solve particular security constraints for an SSL-aware
  webserver is not always obvious because of the coherences between SSL,
  HTTP and Apache's way of processing requests. This chapter gives
  instructions on how to solve such typical situations. Treat is as a first
  step to find out the final solution, but always try to understand the 
  stuff before you use it. Nothing is worse than using a security solution
  without knowing its restrictions and coherences.</p>
  </div><div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#ciphersuites">Cipher Suites and Enforced Strong Security</a></li><li><img alt="" src="../images/down.gif" /> <a href="#accesscontrol">Client Authentication and Access Control</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="ciphersuites" id="ciphersuites">Cipher Suites and Enforced Strong Security</a></h2>
  
  <ul>
  <li><a href="#realssl">SSLv2 only server</a></li>
  <li><a href="#onlystrong">strong encryption only server</a></li>
  <li><a href="#upgradeenc">server gated cryptography</a></li>
  <li><a href="#strongurl">stronger per-directory requirements</a></li>
  </ul>
  
  <h3><a name="realssl" id="realssl">How can I create a real SSLv2-only server?</a></h3>
  
      <p>The following creates an SSL server which speaks only the SSLv2 protocol and
      its ciphers.</p>
  
      <div class="example"><h3>httpd.conf</h3><p><code>
        SSLProtocol -all +SSLv2<br />
        SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP<br />
      </code></p></div>
  
  
  <h3><a name="onlystrong" id="onlystrong">How can I create an SSL server which accepts strong encryption
  only?</a></h3>
  
      <p>The following enables only the seven strongest ciphers:</p>
      <div class="example"><h3>httpd.conf</h3><p><code>
        SSLProtocol all<br />
        SSLCipherSuite HIGH:MEDIUM<br />
      </code></p></div>
  
  
  <h3><a name="upgradeenc" id="upgradeenc">How can I create an SSL server which accepts strong encryption
  only, but allows export browsers to upgrade to stronger encryption?</a></h3>
  
      <p>This facility is called Server Gated Cryptography (SGC) and details
      you can find in the <code>README.GlobalID</code> document in the
      mod_ssl distribution. In short: The server has a Global ID server
      certificate, signed by a special CA certificate from Verisign which
      enables strong encryption in export browsers. This works as following:
      The browser connects with an export cipher, the server sends its Global
      ID certificate, the browser verifies it and subsequently upgrades the
      cipher suite before any HTTP communication takes place. The question
      now is: How can we allow this upgrade, but enforce strong encryption.
      Or in other words: Browser either have to initially connect with
      strong encryption or have to upgrade to strong encryption, but are
      not allowed to keep the export ciphers. The following does the trick:</p>
      <div class="example"><h3>httpd.conf</h3><p><code>
        # allow all ciphers for the inital handshake,<br />
        # so export browsers can upgrade via SGC facility<br />
        SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
        <br />
        &lt;Directory /usr/local/apache2/htdocs&gt;<br />
        # but finally deny all browsers which haven't upgraded<br />
        SSLRequire %{SSL_CIPHER_USEKEYSIZE} &gt;= 128<br />
        &lt;/Directory&gt;
      </code></p></div>
  
  
  <h3><a name="strongurl" id="strongurl">How can I create an SSL server which accepts all types of ciphers
  in general, but requires a strong ciphers for access to a particular
  URL?</a></h3>
  
      <p>Obviously you cannot just use a server-wide <code class="directive"><a href="../mod/mod_ssl.html#sslciphersuite">SSLCipherSuite</a></code> which restricts the
      ciphers to the strong variants. But mod_ssl allows you to reconfigure
      the cipher suite in per-directory context and automatically forces
      a renegotiation of the SSL parameters to meet the new configuration.
      So, the solution is:</p>
      <div class="example"><p><code>
        # be liberal in general<br />
        SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
        <br />
        &lt;Location /strong/area&gt;<br />
        # but https://hostname/strong/area/ and below<br />
        # requires strong ciphers<br />
        SSLCipherSuite HIGH:MEDIUM<br />
        &lt;/Location&gt;
      </code></p></div>
  
  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="accesscontrol" id="accesscontrol">Client Authentication and Access Control</a></h2>
  
  <ul>
  <li><a href="#allclients">simple certificate-based client authentication</a></li>
  <li><a href="#arbitraryclients">selective certificate-based client authentication</a></li>
  <li><a href="#certauthenticate">particular certificate-based client authentication</a></li>
  <li><a href="#intranet">intranet vs. internet authentication</a></li>
  </ul>
  
  <h3><a name="allclients" id="allclients">How can I authenticate clients based on certificates when I know
  all my clients?</a></h3>
  
      <p>When you know your user community (i.e. a closed user group
      situation), as it's the case for instance in an Intranet, you can
      use plain certificate authentication. All you have to do is to
      create client certificates signed by your own CA certificate
      <code>ca.crt</code> and then verifiy the clients against this
      certificate.</p>
      <div class="example"><h3>httpd.conf</h3><p><code>
        # require a client certificate which has to be directly<br />
        # signed by our CA certificate in ca.crt<br />
        SSLVerifyClient require<br />
        SSLVerifyDepth 1<br />
        SSLCACertificateFile conf/ssl.crt/ca.crt
      </code></p></div>
  
  
  <h3><a name="arbitraryclients" id="arbitraryclients">How can I authenticate my clients for a particular URL based on
  certificates but still allow arbitrary clients to access the remaining
  parts of the server?</a></h3>
  
      <p>For this we again use the per-directory reconfiguration feature
      of <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>:</p>
  
      <div class="example"><h3>httpd.conf</h3><p><code>
      SSLVerifyClient none<br />
      SSLCACertificateFile conf/ssl.crt/ca.crt<br />
      <br />
      &lt;Location /secure/area&gt;<br />
      SSLVerifyClient require<br />
      SSLVerifyDepth 1<br />
      &lt;/Location&gt;<br />
      </code></p></div>
  
  
  <h3><a name="certauthenticate" id="certauthenticate">How can I authenticate only particular clients for a some URLs based
  on certificates but still allow arbitrary clients to access the remaining
  parts of the server?</a></h3>
  
      <p>The key is to check for various ingredients of the client certficate.
      Usually this means to check the whole or part of the Distinguished
      Name (DN) of the Subject. For this two methods exists: The <code class="module"><a href="../mod/mod_auth.html">mod_auth</a></code> based variant and the <code class="directive"><a href="../mod/mod_ssl.html#sslrequire">SSLRequire</a></code> variant. The first method is good when the
      clients are of totally different type, i.e. when their DNs have no
      common fields (usually the organisation, etc.). In this case you've
      to establish a password database containing <em>all</em> clients. The
      second method is better when your clients are all part of a common
      hierarchy which is encoded into the DN. Then you can match them more
      easily.</p>
  
      <p>The first method:</p>
      <div class="example"><h3>httpd.conf</h3><pre>
  SSLVerifyClient      none
  &lt;Directory /usr/local/apache2/htdocs/secure/area&gt;
  
  SSLVerifyClient      require
  SSLVerifyDepth       5
  SSLCACertificateFile conf/ssl.crt/ca.crt
  SSLCACertificatePath conf/ssl.crt
  SSLOptions           +FakeBasicAuth
  SSLRequireSSL
  AuthName             "Snake Oil Authentication"
  AuthType             Basic
  AuthUserFile         /usr/local/apache2/conf/httpd.passwd
  require              valid-user
  &lt;/Directory&gt;</pre></div>
  
      <div class="example"><h3>httpd.passwd</h3><pre>
  /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
  /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
  /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA</pre></div>
  
      <p>The second method:</p>
  
      <div class="example"><h3>httpd.conf</h3><pre>
  SSLVerifyClient      none
  &lt;Directory /usr/local/apache2/htdocs/secure/area&gt;
  
    SSLVerifyClient      require
    SSLVerifyDepth       5
    SSLCACertificateFile conf/ssl.crt/ca.crt
    SSLCACertificatePath conf/ssl.crt
    SSLOptions           +FakeBasicAuth
    SSLRequireSSL
    SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
                 and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
  &lt;/Directory&gt;</pre></div>
  
  
  <h3><a name="intranet" id="intranet">How can I require HTTPS with strong ciphers and either basic
  authentication or client certificates for access to a subarea on the
  Intranet website for clients coming from the Internet but still allow
  plain HTTP access for clients on the Intranet?</a></h3>
  
     <p>Let us assume the Intranet can be distinguished through the IP
     network 192.160.1.0/24 and the subarea on the Intranet website has
     the URL <code>/subarea</code>. Then configure the following outside
     your HTTPS virtual host (so it applies to both HTTPS and HTTP):</p>
  
      <div class="example"><h3>httpd.conf</h3><pre>
  SSLCACertificateFile conf/ssl.crt/company-ca.crt
  
  &lt;Directory /usr/local/apache2/htdocs&gt;
  #   Outside the subarea only Intranet access is granted
  Order                deny,allow
  Deny                 from all
  Allow                from 192.168.1.0/24
  &lt;/Directory&gt;
  
  &lt;Directory /usr/local/apache2/htdocs/subarea&gt;
  #   Inside the subarea any Intranet access is allowed
  #   but from the Internet only HTTPS + Strong-Cipher + Password
  #   or the alternative HTTPS + Strong-Cipher + Client-Certificate
  
  #   If HTTPS is used, make sure a strong cipher is used.
  #   Additionally allow client certs as alternative to basic auth.
  SSLVerifyClient      optional
  SSLVerifyDepth       1
  SSLOptions           +FakeBasicAuth +StrictRequire
  SSLRequire           %{SSL_CIPHER_USEKEYSIZE} &gt;= 128
  
  #   Force clients from the Internet to use HTTPS
  RewriteEngine        on
  RewriteCond          %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
  RewriteCond          %{HTTPS} !=on
  RewriteRule          .* - [F]
  
  #   Allow Network Access and/or Basic Auth
  Satisfy              any
  
  #   Network Access Control
  Order                deny,allow
  Deny                 from all
  Allow                192.168.1.0/24
  
  #   HTTP Basic Authentication
  AuthType             basic
  AuthName             "Protected Intranet Area"
  AuthUserFile         conf/protected.passwd
  Require              valid-user
  &lt;/Directory&gt;</pre></div>
  
  </div></div><div id="footer"><p class="apache">Maintained by the <a href="http://httpd.apache.org/docs-project/">Apache HTTP Server Documentation Project</a></p><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></body></html>
  
  
  1.1                  httpd-2.0/docs/manual/ssl/ssl_howto.xml
  
  Index: ssl_howto.xml
  ===================================================================
  <?xml version='1.0' encoding='UTF-8' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
  <manualpage>
  <relativepath href=".."/>
  
    <title>SSL/TLS Strong Encryption: How-To</title>
  
  <summary>
  <blockquote>
  <p>The solution of this problem is trivial
  and is left as an exercise for the reader.</p>
  
  <p class="cite">-- <cite>Standard textbook cookie</cite></p>
  </blockquote>
  
  <p>How to solve particular security constraints for an SSL-aware
  webserver is not always obvious because of the coherences between SSL,
  HTTP and Apache's way of processing requests. This chapter gives
  instructions on how to solve such typical situations. Treat is as a first
  step to find out the final solution, but always try to understand the 
  stuff before you use it. Nothing is worse than using a security solution
  without knowing its restrictions and coherences.</p>
  </summary>
  
  <section id="ciphersuites">
  <title>Cipher Suites and Enforced Strong Security</title>
  <ul>
  <li><a href="#realssl">SSLv2 only server</a></li>
  <li><a href="#onlystrong">strong encryption only server</a></li>
  <li><a href="#upgradeenc">server gated cryptography</a></li>
  <li><a href="#strongurl">stronger per-directory requirements</a></li>
  </ul>
  
  <section id="realssl">
  <title>How can I create a real SSLv2-only server?</title>
      <p>The following creates an SSL server which speaks only the SSLv2 protocol and
      its ciphers.</p>
  
      <example><title>httpd.conf</title>
        SSLProtocol -all +SSLv2<br />
        SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP<br />
      </example>
  </section>
  
  <section id="onlystrong">
  <title>How can I create an SSL server which accepts strong encryption
  only?</title>
      <p>The following enables only the seven strongest ciphers:</p>
      <example><title>httpd.conf</title>
        SSLProtocol all<br />
        SSLCipherSuite HIGH:MEDIUM<br />
      </example>
  </section>
  
  <section id="upgradeenc">
  <title>How can I create an SSL server which accepts strong encryption
  only, but allows export browsers to upgrade to stronger encryption?</title>
      <p>This facility is called Server Gated Cryptography (SGC) and details
      you can find in the <code>README.GlobalID</code> document in the
      mod_ssl distribution. In short: The server has a Global ID server
      certificate, signed by a special CA certificate from Verisign which
      enables strong encryption in export browsers. This works as following:
      The browser connects with an export cipher, the server sends its Global
      ID certificate, the browser verifies it and subsequently upgrades the
      cipher suite before any HTTP communication takes place. The question
      now is: How can we allow this upgrade, but enforce strong encryption.
      Or in other words: Browser either have to initially connect with
      strong encryption or have to upgrade to strong encryption, but are
      not allowed to keep the export ciphers. The following does the trick:</p>
      <example><title>httpd.conf</title>
        # allow all ciphers for the inital handshake,<br />
        # so export browsers can upgrade via SGC facility<br />
        SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
        <br />
        &lt;Directory /usr/local/apache2/htdocs&gt;<br />
        # but finally deny all browsers which haven't upgraded<br />
        SSLRequire %{SSL_CIPHER_USEKEYSIZE} &gt;= 128<br />
        &lt;/Directory&gt;
      </example>
  </section>
  
  <section id="strongurl">
  <title>How can I create an SSL server which accepts all types of ciphers
  in general, but requires a strong ciphers for access to a particular
  URL?</title>
      <p>Obviously you cannot just use a server-wide <directive
      module="mod_ssl">SSLCipherSuite</directive> which restricts the
      ciphers to the strong variants. But mod_ssl allows you to reconfigure
      the cipher suite in per-directory context and automatically forces
      a renegotiation of the SSL parameters to meet the new configuration.
      So, the solution is:</p>
      <example>
        # be liberal in general<br />
        SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
        <br />
        &lt;Location /strong/area&gt;<br />
        # but https://hostname/strong/area/ and below<br />
        # requires strong ciphers<br />
        SSLCipherSuite HIGH:MEDIUM<br />
        &lt;/Location&gt;
      </example>
  </section>
  </section>
  <!-- /ciphersuites -->
  
  <section id="accesscontrol">
  <title>Client Authentication and Access Control</title>
  <ul>
  <li><a href="#allclients">simple certificate-based client authentication</a></li>
  <li><a href="#arbitraryclients">selective certificate-based client authentication</a></li>
  <li><a href="#certauthenticate">particular certificate-based client authentication</a></li>
  <li><a href="#intranet">intranet vs. internet authentication</a></li>
  </ul>
  
  <section id="allclients">
  <title>How can I authenticate clients based on certificates when I know
  all my clients?</title>
      <p>When you know your user community (i.e. a closed user group
      situation), as it's the case for instance in an Intranet, you can
      use plain certificate authentication. All you have to do is to
      create client certificates signed by your own CA certificate
      <code>ca.crt</code> and then verifiy the clients against this
      certificate.</p>
      <example><title>httpd.conf</title>
        # require a client certificate which has to be directly<br />
        # signed by our CA certificate in ca.crt<br />
        SSLVerifyClient require<br />
        SSLVerifyDepth 1<br />
        SSLCACertificateFile conf/ssl.crt/ca.crt
      </example>
  </section>
  
  <section id="arbitraryclients">
  <title>How can I authenticate my clients for a particular URL based on
  certificates but still allow arbitrary clients to access the remaining
  parts of the server?</title>
      <p>For this we again use the per-directory reconfiguration feature
      of <module>mod_ssl</module>:</p>
  
      <example><title>httpd.conf</title>
      SSLVerifyClient none<br />
      SSLCACertificateFile conf/ssl.crt/ca.crt<br />
      <br />
      &lt;Location /secure/area&gt;<br />
      SSLVerifyClient require<br />
      SSLVerifyDepth 1<br />
      &lt;/Location&gt;<br />
      </example>
  </section>
  
  <section id="certauthenticate">
  <title>How can I authenticate only particular clients for a some URLs based
  on certificates but still allow arbitrary clients to access the remaining
  parts of the server?</title>
      <p>The key is to check for various ingredients of the client certficate.
      Usually this means to check the whole or part of the Distinguished
      Name (DN) of the Subject. For this two methods exists: The <module
      >mod_auth</module> based variant and the <directive module="mod_ssl"
      >SSLRequire</directive> variant. The first method is good when the
      clients are of totally different type, i.e. when their DNs have no
      common fields (usually the organisation, etc.). In this case you've
      to establish a password database containing <em>all</em> clients. The
      second method is better when your clients are all part of a common
      hierarchy which is encoded into the DN. Then you can match them more
      easily.</p>
  
      <p>The first method:</p>
      <example><title>httpd.conf</title><pre>
  SSLVerifyClient      none
  &lt;Directory /usr/local/apache2/htdocs/secure/area&gt;
  
  SSLVerifyClient      require
  SSLVerifyDepth       5
  SSLCACertificateFile conf/ssl.crt/ca.crt
  SSLCACertificatePath conf/ssl.crt
  SSLOptions           +FakeBasicAuth
  SSLRequireSSL
  AuthName             "Snake Oil Authentication"
  AuthType             Basic
  AuthUserFile         /usr/local/apache2/conf/httpd.passwd
  require              valid-user
  &lt;/Directory&gt;</pre>
      </example>
  
      <example><title>httpd.passwd</title><pre>
  /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
  /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
  /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA</pre>
      </example>
  
      <p>The second method:</p>
  
      <example><title>httpd.conf</title><pre>
  SSLVerifyClient      none
  &lt;Directory /usr/local/apache2/htdocs/secure/area&gt;
  
    SSLVerifyClient      require
    SSLVerifyDepth       5
    SSLCACertificateFile conf/ssl.crt/ca.crt
    SSLCACertificatePath conf/ssl.crt
    SSLOptions           +FakeBasicAuth
    SSLRequireSSL
    SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
                 and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
  &lt;/Directory&gt;</pre>
      </example>
  </section>
  
  <section id="intranet">
  <title>How can I require HTTPS with strong ciphers and either basic
  authentication or client certificates for access to a subarea on the
  Intranet website for clients coming from the Internet but still allow
  plain HTTP access for clients on the Intranet?</title>
     <p>Let us assume the Intranet can be distinguished through the IP
     network 192.160.1.0/24 and the subarea on the Intranet website has
     the URL <code>/subarea</code>. Then configure the following outside
     your HTTPS virtual host (so it applies to both HTTPS and HTTP):</p>
  
      <example><title>httpd.conf</title><pre>
  SSLCACertificateFile conf/ssl.crt/company-ca.crt
  
  &lt;Directory /usr/local/apache2/htdocs&gt;
  #   Outside the subarea only Intranet access is granted
  Order                deny,allow
  Deny                 from all
  Allow                from 192.168.1.0/24
  &lt;/Directory&gt;
  
  &lt;Directory /usr/local/apache2/htdocs/subarea&gt;
  #   Inside the subarea any Intranet access is allowed
  #   but from the Internet only HTTPS + Strong-Cipher + Password
  #   or the alternative HTTPS + Strong-Cipher + Client-Certificate
  
  #   If HTTPS is used, make sure a strong cipher is used.
  #   Additionally allow client certs as alternative to basic auth.
  SSLVerifyClient      optional
  SSLVerifyDepth       1
  SSLOptions           +FakeBasicAuth +StrictRequire
  SSLRequire           %{SSL_CIPHER_USEKEYSIZE} &gt;= 128
  
  #   Force clients from the Internet to use HTTPS
  RewriteEngine        on
  RewriteCond          %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
  RewriteCond          %{HTTPS} !=on
  RewriteRule          .* - [F]
  
  #   Allow Network Access and/or Basic Auth
  Satisfy              any
  
  #   Network Access Control
  Order                deny,allow
  Deny                 from all
  Allow                192.168.1.0/24
  
  #   HTTP Basic Authentication
  AuthType             basic
  AuthName             "Protected Intranet Area"
  AuthUserFile         conf/protected.passwd
  Require              valid-user
  &lt;/Directory&gt;</pre>
      </example>
  </section>
  </section>
  <!-- /access control -->
  
  </manualpage>
  
  
  
  
  
  
  1.1                  httpd-2.0/docs/manual/ssl/ssl_intro.html.en
  
  Index: ssl_intro.html.en
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                This file is generated from xml source: DO NOT EDIT
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        --><title>SSL/TLS Strong Encryption: An Introduction - Apache HTTP Server</title><link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /><link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /><link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link href="../images/favicon.ico" rel="shortcut icon" /></head><body id="manual-page"><div id="page-header"><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><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></div><div class="up"><a href="./"><img title="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div><div id="path"><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-project/">Documentation</a> &gt; <a href="../">Version 2.0</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS Strong Encryption: An Introduction</h1>
  <blockquote>
  <p>The nice thing about standards is that there are so many to choose
  from. And if you really don't like all the standards you just have to
  wait another year until the one arises you are looking for.</p>
  
  <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
  Computer Networks"</p>
  </blockquote>
  
  <p>As an introduction this chapter is aimed at readers who are familiar
  with the Web, HTTP, and Apache, but are not security experts. It is not
  intended to be a definitive guide to the SSL protocol, nor does it discuss
  specific techniques for managing certificates in an organization, or the
  important legal issues of patents and import and export restrictions.
  Rather, it is intended to provide a common background to mod_ssl users by
  pulling together various concepts, definitions, and examples as a starting
  point for further exploration.</p>
  
  <p>The presented content is mainly derived, with permission by the author,
  from the article <a href="http://www.ultranet.com/~fhirsch/Papers/wwwj/index.html">Introducing
  SSL and Certificates using SSLeay</a> from <a href="http://www.ultranet.com/~fhirsch/">Frederick J. Hirsch</a>, of The
  Open Group Research Institute, which was published in <a href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
  Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
  Please send any postive feedback to <a href="mailto:fjh@alum.mit.edu">Frederick Hirsch</a> (the original
  article author) and all negative feedback to <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the
  <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> author).</p>
  </div><div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cryptographictech">Cryptographic Techniques</a></li><li><img alt="" src="../images/down.gif" /> <a href="#certificates">Certificates</a></li><li><img alt="" src="../images/down.gif" /> <a href="#ssl">Secure Sockets Layer (SSL)</a></li><li><img alt="" src="../images/down.gif" /> <a href="#references">References</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="cryptographictech" id="cryptographictech">Cryptographic Techniques</a></h2>
  
  <p>Understanding SSL requires an understanding of cryptographic
  algorithms, message digest functions (aka. one-way or hash functions), and
  digital signatures. These techniques are the subject of entire books (see
  for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy,
  integrity, and authentication.</p>
  
  <h3><a name="cryptographicalgo" id="cryptographicalgo">Cryptographic Algorithms</a></h3>
  
      <p>Suppose Alice wants to send a message to her bank to transfer some
      money. Alice would like the message to be private, since it will
      include information such as her account number and transfer amount. One
      solution is to use a cryptographic algorithm, a technique that would
      transform her message into an encrypted form, unreadable except by
      those it is intended for. Once in this form, the message may only be
      interpreted through the use of a secret key. Without the key the
      message is useless: good cryptographic algorithms make it so difficult
      for intruders to decode the original text that it isn't worth their
      effort.</p>
  
      <p>There are two categories of cryptographic algorithms: conventional
      and public key.</p>
  
      <dl>
      <dt>Conventional cryptography</dt>
      <dd>also known as symmetric cryptography, requires the sender and
      receiver to share a key: a secret piece of information that may be
      used to encrypt or decrypt a message. If this key is secret, then
      nobody other than the sender or receiver may read the message. If
      Alice and the bank know a secret key, then they may send each other
      private messages. The task of privately choosing a key before
      communicating, however, can be problematic.</dd>
  
      <dt>Public key cryptography</dt>
      <dd>also known as asymmetric cryptography, solves the key exchange
      problem by defining an algorithm which uses two keys, each of which
      may be used to encrypt a message. If one key is used to encrypt a
      message then the other must be used to decrypt it. This makes it
      possible to receive secure messages by simply publishing one key
      (the public key) and keeping the other secret (the private key).</dd>
      </dl>
  
      <p>Anyone may encrypt a message using the public key, but only the
      owner of the private key will be able to read it. In this way, Alice
      may send private messages to the owner of a key-pair (the bank), by
      encrypting it using their public key. Only the bank will be able to
      decrypt it.</p>
  
  
  <h3><a name="messagedigests" id="messagedigests">Message Digests</a></h3>
  
      <p>Although Alice may encrypt her message to make it private, there
      is still a concern that someone might modify her original message or
      substitute it with a different one, in order to transfer the money
      to themselves, for instance. One way of guaranteeing the integrity
      of Alice's message is to create a concise summary of her message and
      send this to the bank as well. Upon receipt of the message, the bank
      creates its own summary and compares it with the one Alice sent. If
      they agree then the message was received intact.</p>
  
      <p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way
  function</em> or <em>hash function</em>. Message digests are used to create
  short, fixed-length representations of longer, variable-length messages.
  Digest algorithms are designed to produce unique digests for different
  messages. Message digests are designed to make it too difficult to determine
  the message from the digest, and also impossible to find two different
  messages which create the same digest -- thus eliminating the possibility of
  substituting one message for another while maintaining the same digest.</p>
  <p>Another challenge that Alice faces is finding a way to send the digest to the
  bank securely; when this is achieved, the integrity of the associated message
  is assured. One way to to this is to include the digest in a digital
  signature.</p>
  
  
  <h3><a name="digitalsignatures" id="digitalsignatures">Digital Signatures</a></h3>
  <p>When Alice sends a message to the bank, the bank needs to ensure that the
  message is really from her, so an intruder does not request a transaction
  involving her account. A <em>digital signature</em>, created by Alice and
  included with the message, serves this purpose.</p>
  
  <p>Digital signatures are created by encrypting a digest of the message,
  and other information (such as a sequence number) with the sender's
  private key. Though anyone may <em>decrypt</em> the signature using the public
  key, only the signer knows the private key. This means that only they may
  have signed it. Including the digest in the signature means the signature is
  only good for that message; it also ensures the integrity of the message since
  no one can change the digest and still sign it.</p>
  <p>To guard against interception and reuse of the signature by an intruder at a
  later date, the signature contains a unique sequence number. This protects
  the bank from a fraudulent claim from Alice that she did not send the message
  -- only she could have signed it (non-repudiation).</p>
  
  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="certificates" id="certificates">Certificates</a></h2>
  
  <p>Although Alice could have sent a private message to the bank, signed
  it, and ensured the integrity of the message, she still needs to be sure
  that she is really communicating with the bank. This means that she needs
  to be sure that the public key she is using corresponds to the bank's
  private key. Similarly, the bank also needs to verify that the message
  signature really corresponds to Alice's signature.</p>
  
  <p>If each party has a certificate which validates the other's identity,
  confirms the public key, and is signed by a trusted agency, then they both
  will be assured that they are communicating with whom they think they are.
  Such a trusted agency is called a <em>Certificate Authority</em>, and
  certificates are used for authentication.</p>
  
  <h3><a name="certificatecontents" id="certificatecontents">Certificate Contents</a></h3>
  
      <p>A certificate associates a public key with the real identity of
      an individual, server, or other entity, known as the subject. As
      shown in <a href="#table1">Table 1</a>, information about the subject
      includes identifying information (the distinguished name), and the
      public key. It also includes the identification and signature of the
      Certificate Authority that issued the certificate, and the period of
      time during which the certificate is valid. It may have additional
      information (or extensions) as well as administrative information
      for the Certificate Authority's use, such as a serial number.</p>
  
      <h4><a name="table1" id="table1">Table 1: Certificate Information</a></h4>
      
      <table>
      <tr><th>Subject</th>
          <td>Distinguished Name, Public Key</td></tr>
      <tr><th>Issuer</th>
          <td>Distinguished Name, Signature</td></tr>
      <tr><th>Period of Validity</th>
          <td>Not Before Date, Not After Date</td></tr>
      <tr><th>Administrative Information</th>
          <td>Version, Serial Number</td></tr>
      <tr><th>Extended Information</th>
          <td>Basic Contraints, Netscape Flags, etc.</td></tr>
      </table>
      
  
      <p>A distinguished name is used to provide an identity in a specific
      context -- for instance, an individual might have a personal
      certificate as well as one for their identity as an employee.
      Distinguished names are defined by the X.509 standard [<a href="#X509">X509</a>], which defines the fields, field names, and
      abbreviations used to refer to the fields (see <a href="#table2">Table
      2</a>).</p>
  
      <h4><a name="table2" id="table2">Table 2: Distinguished Name Information</a></h4>
      
      <table class="bordered">
      <tr><th>DN Field</th>
          <th>Abbrev.</th>
          <th>Description</th>
          <th>Example</th></tr>
      <tr><td>Common Name</td>
          <td>CN</td>
          <td>Name being certified</td>
          <td>CN=Joe Average</td></tr>
      <tr><td>Organization or Company</td>
          <td>O</td>
          <td>Name is associated with this<br />organization</td>
          <td>O=Snake Oil, Ltd.</td></tr>
      <tr><td>Organizational Unit</td>
          <td>OU</td>
          <td>Name is associated with this <br />organization unit, such
          as a department</td>
          <td>OU=Research Institute</td></tr>
      <tr><td>City/Locality</td>
          <td>L</td>
          <td>Name is located in this City</td>
          <td>L=Snake City</td></tr>
      <tr><td>State/Province</td>
          <td>ST</td>
          <td>Name is located in this State/Province</td>
          <td>ST=Desert</td></tr>
      <tr><td>Country</td>
          <td>C</td>
          <td>Name is located in this Country (ISO code)</td>
          <td>C=XZ</td></tr>
      </table>
      
  
      <p>A Certificate Authority may define a policy specifying which
      distinguished field names are optional, and which are required. It
      may also place requirements upon the field contents, as may users of
      certificates. As an example, a Netscape browser requires that the
      Common Name for a certificate representing a server has a name which
      matches a wildcard pattern for the domain name of that server, such
      as <code>*.snakeoil.com</code>.</p>
  
      <p>The binary format of a certificate is defined using the ASN.1
      notation [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This
      notation defines how to specify the contents, and encoding rules
      define how this information is translated into binary form. The binary
      encoding of the certificate is defined using Distinguished Encoding
      Rules (DER), which are based on the more general Basic Encoding Rules
      (BER). For those transmissions which cannot handle binary, the binary
      form may be translated into an ASCII form by using Base64 encoding
      [<a href="#MIME">MIME</a>]. This encoded version is called PEM encoded
      (the name comes from "Privacy Enhanced Mail"), when placed between
      begin and end delimiter lines as illustrated in the following
      example.</p>
  
      <div class="example"><h3>Example of a PEM-encoded certificate (snakeoil.crt)</h3><pre>-----BEGIN CERTIFICATE-----
  MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
  FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
  A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
  cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
  bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
  MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
  a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
  cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
  AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
  gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
  vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
  lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
  HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
  gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
  2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
  dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
  -----END CERTIFICATE-----</pre></div>
  
  
  <h3><a name="certificateauthorities" id="certificateauthorities">Certificate Authorities</a></h3>
  
      <p>By first verifying the information in a certificate request
      before granting the certificate, the Certificate Authority assures
      the identity of the private key owner of a key-pair. For instance,
      if Alice requests a personal certificate, the Certificate Authority
      must first make sure that Alice really is the person the certificate
      request claims.</p>
  
      <h4><a name="certificatechains" id="certificatechains">Certificate Chains</a></h4>
      
          <p>A Certificate Authority may also issue a certificate for
          another Certificate Authority. When examining a certificate,
          Alice may need to examine the certificate of the issuer, for each
          parent Certificate Authority, until reaching one which she has
          confidence in. She may decide to trust only certificates with a
          limited chain of issuers, to reduce her risk of a "bad" certificate
          in the chain.</p>
      
  
      <h4><a name="rootlevelca" id="rootlevelca">Creating a Root-Level CA</a></h4>
      
          <p>As noted earlier, each certificate requires an issuer to assert
          the validity of the identity of the certificate subject, up to
          the top-level Certificate Authority (CA). This presents a problem:
          Since this is who vouches for the certificate of the top-level
          authority, which has no issuer? In this unique case, the
          certificate is "self-signed", so the issuer of the certificate is
          the same as the subject. As a result, one must exercise extra care
          in trusting a self-signed certificate. The wide publication of a
          public key by the root authority reduces the risk in trusting this
          key -- it would be obvious if someone else publicized a key
          claiming to be the authority. Browsers are preconfigured to trust
          well-known certificate authorities.</p>
  
          <p>A number of companies, such as <a href="http://www.thawte.com/">Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a>
          have established themselves as Certificate Authorities. These
          companies provide the following services:</p>
  
          <ul>
          <li>Verifying certificate requests</li>
          <li>Processing certificate requests</li>
          <li>Issuing and managing certificates</li>
          </ul>
  
          <p>It is also possible to create your own Certificate Authority.
          Although risky in the Internet environment, it may be useful
          within an Intranet where the organization can easily verify the
          identities of individuals and servers.</p>
      
  
      <h4><a name="certificatemanagement" id="certificatemanagement">Certificate Management</a></h4>
      
          <p>Establishing a Certificate Authority is a responsibility which
          requires a solid administrative, technical, and management
          framework. Certificate Authorities not only issue certificates,
          they also manage them -- that is, they determine how long
          certificates are valid, they renew them, and they keep lists of
          certificates that have already been issued but are no longer valid
          (Certificate Revocation Lists, or CRLs). Say Alice is entitled to
          a certificate as an employee of a company. Say too, that the
          certificate needs to be revoked when Alice leaves the company. Since
          certificates are objects that get passed around, it is impossible
          to tell from the certificate alone that it has been revoked. When
          examining certificates for validity, therefore, it is necessary to
          contact the issuing Certificate Authority to check CRLs -- this
          is not usually an automated part of the process.</p>
  
          <div class="note"><h3>Note</h3>
          <p>If you use a Certificate Authority that is not configured into
          browsers by default, it is necessary to load the Certificate
          Authority certificate into the browser, enabling the browser to
          validate server certificates signed by that Certificate Authority.
          Doing so may be dangerous, since once loaded, the browser will
          accept all certificates signed by that Certificate Authority.</p>
          </div>
      
  
  
  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="ssl" id="ssl">Secure Sockets Layer (SSL)</a></h2>
  
  <p>The Secure Sockets Layer protocol is a protocol layer which may be
  placed between a reliable connection-oriented network layer protocol
  (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides
  for secure communication between client and server by allowing mutual
  authentication, the use of digital signatures for integrity, and encryption
  for privacy.</p>
  
  <p>The protocol is designed to support a range of choices for specific
  algorithms used for cryptography, digests, and signatures. This allows
  algorithm selection for specific servers to be made based on legal, export
  or other concerns, and also enables the protocol to take advantage of new
  algorithms. Choices are negotiated between client and server at the start
  of establishing a protocol session.</p>
  
  <h3><a name="table4" id="table4">Table 4: Versions of the SSL protocol</a></h3>
  
      <table class="bordered">
      <tr><th>Version</th>
          <th>Source</th>
          <th>Description</th>
          <th>Browser Support</th></tr>
      <tr><td>SSL v2.0</td>
          <td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2">SSL2</a>]</td>
          <td>First SSL protocol for which implementations exists</td>
          <td>- NS Navigator 1.x/2.x<br />
          - MS IE 3.x<br />
          - Lynx/2.8+OpenSSL</td></tr>
      <tr><td>SSL v3.0</td>
          <td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3">SSL3</a>]</td>
          <td>Revisions to prevent specific security attacks, add non-RSA
          ciphers, and support for certificate chains</td>
          <td>- NS Navigator 2.x/3.x/4.x<br />
          - MS IE 3.x/4.x<br />
          - Lynx/2.8+OpenSSL</td></tr>
      <tr><td>TLS v1.0</td>
          <td>Proposed Internet Standard (from IETF) [<a href="#TLS1">TLS1</a>]</td>
          <td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block
          padding for block ciphers, message order standardization and more
          alert messages.</td>
          <td>- Lynx/2.8+OpenSSL</td></tr>
      </table>
  
  
  <p>There are a number of versions of the SSL protocol, as shown in 
  <a href="#table4">Table 4</a>. As noted there, one of the benefits in
  SSL 3.0 is that it adds support of certificate chain loading. This feature
  allows a server to pass a server certificate along with issuer certificates
  to the browser. Chain loading also permits the browser to validate the
  server certificate, even if Certificate Authority certificates are not
  installed for the intermediate issuers, since they are included in the
  certificate chain. SSL 3.0 is the basis for the Transport Layer Security 
  [<a href="#TLS1">TLS</a>] protocol standard, currently in development by
  the Internet Engineering Task Force (IETF).</p>
  
  <h3><a name="session" id="session">Session Establishment</a></h3>
  
      <p>The SSL session is established by following a handshake sequence
      between client and server, as shown in <a href="#figure1">Figure 1</a>. This sequence may vary, depending on whether the server
      is configured to provide a server certificate or request a client
      certificate. Though cases exist where additional handshake steps
      are required for management of cipher information, this article
      summarizes one common scenario: see the SSL specification for the full
      range of possibilities.</p>
  
      <div class="note"><h3>Note</h3>
      <p>Once an SSL session has been established it may be reused, thus
      avoiding the performance penalty of repeating the many steps needed
      to start a session. For this the server assigns each SSL session a
      unique session identifier which is cached in the server and which the
      client can use on forthcoming connections to reduce the handshake
      (until the session identifer expires in the cache of the server).</p>
      </div>
  
      <p class="figure">
      <img src="ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
      <a id="figure1" name="figure1"><dfn>Figure 1</dfn></a>: Simplified SSL
      Handshake Sequence</p>
  
      <p>The elements of the handshake sequence, as used by the client and
      server, are listed below:</p>
  
      <ol>
      <li>Negotiate the Cipher Suite to be used during data transfer</li>
      <li>Establish and share a session key between client and server</li>
      <li>Optionally authenticate the server to the client</li>
      <li>Optionally authenticate the client to the server</li>
      </ol>
  
      <p>The first step, Cipher Suite Negotiation, allows the client and
      server to choose a Cipher Suite supportable by both of them. The SSL3.0
      protocol specification defines 31 Cipher Suites. A Cipher Suite is
      defined by the following components:</p>
  
      <ul>
      <li>Key Exchange Method</li>
      <li>Cipher for Data Transfer</li>
      <li>Message Digest for creating the Message Authentication Code (MAC)</li>
      </ul>
  
      <p>These three elements are described in the sections that follow.</p>
  
  
  <h3><a name="keyexchange" id="keyexchange">Key Exchange Method</a></h3>
  
      <p>The key exchange method defines how the shared secret symmetric
      cryptography key used for application data transfer will be agreed
      upon by client and server. SSL 2.0 uses RSA key exchange only, while
      SSL 3.0 supports a choice of key exchange algorithms including the
      RSA key exchange when certificates are used, and Diffie-Hellman key
      exchange for exchanging keys without certificates and without prior
      communication between client and server.</p>
  
      <p>One variable in the choice of key exchange methods is digital
      signatures -- whether or not to use them, and if so, what kind of
      signatures to use. Signing with a private key provides assurance
      against a man-in-the-middle-attack during the information exchange
      used in generating the shared key [<a href="#AC96">AC96</a>, p516].</p>
  
  
  <h3><a name="ciphertransfer" id="ciphertransfer">Cipher for Data Transfer</a></h3>
  
      <p>SSL uses the conventional cryptography algorithm (symmetric
      cryptography) described earlier for encrypting messages in a session.
      There are nine choices, including the choice to perform no
      encryption:</p>
  
      <ul>
      <li>No encryption</li>
      <li>Stream Ciphers
          <ul>
          <li>RC4 with 40-bit keys</li>
          <li>RC4 with 128-bit keys</li>
          </ul></li>
      <li>CBC Block Ciphers
          <ul><li>RC2 with 40 bit key</li>
          <li>DES with 40 bit key</li>
          <li>DES with 56 bit key</li>
          <li>Triple-DES with 168 bit key</li>
          <li>Idea (128 bit key)</li>
          <li>Fortezza (96 bit key)</li>
          </ul></li>
      </ul>
  
      <p>Here "CBC" refers to Cipher Block Chaining, which means that a
      portion of the previously encrypted cipher text is used in the
      encryption of the current block. "DES" refers to the Data Encryption
      Standard [<a href="#AC96">AC96</a>, ch12], which has a number of
      variants (including DES40 and 3DES_EDE). "Idea" is one of the best
      and cryptographically strongest available algorithms, and "RC2" is
      a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>,
      ch13].</p>
  
  
  <h3><a name="digestfuntion" id="digestfuntion">Digest Function</a></h3>
  
      <p>The choice of digest function determines how a digest is created
      from a record unit. SSL supports the following:</p>
  
      <ul>
      <li>No digest (Null choice)</li>
      <li>MD5, a 128-bit hash</li>
      <li>Secure Hash Algorithm (SHA-1), a 160-bit hash</li>
      </ul>
  
      <p>The message digest is used to create a Message Authentication Code
      (MAC) which is encrypted with the message to provide integrity and to
      prevent against replay attacks.</p>
  
  
  <h3><a name="handshake" id="handshake">Handshake Sequence Protocol</a></h3>
  
      <p>The handshake sequence uses three protocols:</p>
  
      <ul>
      <li>The <dfn>SSL Handshake Protocol</dfn>
      for performing the client and server SSL session establishment.</li>
      <li>The <dfn>SSL Change Cipher Spec Protocol</dfn> for actually
      establishing agreement on the Cipher Suite for the session.</li>
      <li>The <dfn>SSL Alert Protocol</dfn> for conveying SSL error
      messages between client and server.</li>
      </ul>
  
      <p>These protocols, as well as application protocol data, are
      encapsulated in the <dfn>SSL Record Protocol</dfn>, as shown in
      <a href="#figure2">Figure 2</a>. An encapsulated protocol is
      transferred as data by the lower layer protocol, which does not
      examine the data. The encapsulated protocol has no knowledge of the
      underlying protocol.</p>
  
      <p class="figure">
      <img src="ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
      <a id="figure2" name="figure2"><dfn>Figure 2</dfn></a>: SSL Protocol Stack
      </p>
  
      <p>The encapsulation of SSL control protocols by the record protocol
      means that if an active session is renegotiated the control protocols
      will be transmitted securely. If there were no session before, then
      the Null cipher suite is used, which means there is no encryption and
      messages have no integrity digests until the session has been
      established.</p>
  
  
  <h3><a name="datatransfer" id="datatransfer">Data Transfer</a></h3>
  
      <p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>,
      is used to transfer application and SSL Control data between the
      client and server, possibly fragmenting this data into smaller units,
      or combining multiple higher level protocol data messages into single
      units. It may compress, attach digest signatures, and encrypt these
      units before transmitting them using the underlying reliable transport
      protocol (Note: currently all major SSL implementations lack support
      for compression).</p>
  
      <p class="figure">
      <img src="ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
      <a id="figure3" name="figure3"><dfn>Figure 3</dfn></a>: SSL Record Protocol
      </p>
  
  
  <h3><a name="securehttp" id="securehttp">Securing HTTP Communication</a></h3>
  
      <p>One common use of SSL is to secure Web HTTP communication between
      a browser and a webserver. This case does not preclude the use of
      non-secured HTTP. The secure version is mainly plain HTTP over SSL
      (named HTTPS), but with one major difference: it uses the URL scheme
      <code>https</code> rather than <code>http</code> and a different
      server port (by default 443). This mainly is what <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> provides to you for the Apache webserver...</p>
  
  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="references" id="references">References</a></h2>
  
  <dl>
  <dt><a id="AC96" name="AC96">[AC96]</a></dt>
  <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
  1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for various other materials by Bruce
  Schneier.</dd>
  
  <dt><a id="X208" name="X208">[X208]</a></dt>
  <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
  One (ASN.1)</q>, 1988. See for instance <a href="http://www.itu.int/rec/recommendation.asp?type=items&amp;lang=e&amp;parent=T-REC-X.208-198811-I">http://www.itu.int/rec/recommendation.asp?type=items&amp;lang=e&amp;parent=T-REC-X.208-198811-I</a>.
  </dd>
  
  <dt><a id="X509" name="X509">[X509]</a></dt>
  <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
  Framework</q>. See for instance <a href="http://www.itu.int/rec/recommendation.asp?type=folders&amp;lang=e&amp;parent=T-REC-X.509">http://www.itu.int/rec/recommendation.asp?type=folders&amp;lang=e&amp;parent=T-REC-X.509</a>.
  </dd>
  
  <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
  <dd><q>Public Key Cryptography Standards (PKCS)</q>, 
  RSA Laboratories Technical Notes, See <a href="http://www.rsasecurity.com/rsalabs/pkcs/">http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
  
  <dt><a id="MIME" name="MIME">[MIME]</a></dt>
  <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
  (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
  See for instance <a href="http://ietf.org/rfc/rfc2045.txt">http://ietf.org/rfc/rfc2045.txt</a>.</dd>
  
  <dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
  <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>
  
  <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
  <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
  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>
  
  <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
  <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
  1999. See <a href="http://ietf.org/rfc/rfc2246.txt">http://ietf.org/rfc/rfc2246.txt</a>.</dd>
  </dl>
  </div></div><div id="footer"><p class="apache">Maintained by the <a href="http://httpd.apache.org/docs-project/">Apache HTTP Server Documentation Project</a></p><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></body></html>
  
  
  1.1                  httpd-2.0/docs/manual/ssl/ssl_intro.xml
  
  Index: ssl_intro.xml
  ===================================================================
  <?xml version='1.0' encoding='UTF-8' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
  <manualpage>
  <relativepath href=".."/>
  
    <title>SSL/TLS Strong Encryption: An Introduction</title>
  
  <summary>
  <blockquote>
  <p>The nice thing about standards is that there are so many to choose
  from. And if you really don't like all the standards you just have to
  wait another year until the one arises you are looking for.</p>
  
  <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
  Computer Networks"</p>
  </blockquote>
  
  <p>As an introduction this chapter is aimed at readers who are familiar
  with the Web, HTTP, and Apache, but are not security experts. It is not
  intended to be a definitive guide to the SSL protocol, nor does it discuss
  specific techniques for managing certificates in an organization, or the
  important legal issues of patents and import and export restrictions.
  Rather, it is intended to provide a common background to mod_ssl users by
  pulling together various concepts, definitions, and examples as a starting
  point for further exploration.</p>
  
  <p>The presented content is mainly derived, with permission by the author,
  from the article <a
  href="http://www.ultranet.com/~fhirsch/Papers/wwwj/index.html">Introducing
  SSL and Certificates using SSLeay</a> from <a
  href="http://www.ultranet.com/~fhirsch/">Frederick J. Hirsch</a>, of The
  Open Group Research Institute, which was published in <a
  href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
  Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997.
  Please send any postive feedback to <a
  href="mailto:fjh@alum.mit.edu">Frederick Hirsch</a> (the original
  article author) and all negative feedback to <a
  href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (the
  <module>mod_ssl</module> author).</p>
  </summary>
  
  <section id="cryptographictech">
  <title>Cryptographic Techniques</title>
  <p>Understanding SSL requires an understanding of cryptographic
  algorithms, message digest functions (aka. one-way or hash functions), and
  digital signatures. These techniques are the subject of entire books (see
  for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy,
  integrity, and authentication.</p>
  
  <section id="cryptographicalgo">
  <title>Cryptographic Algorithms</title>
      <p>Suppose Alice wants to send a message to her bank to transfer some
      money. Alice would like the message to be private, since it will
      include information such as her account number and transfer amount. One
      solution is to use a cryptographic algorithm, a technique that would
      transform her message into an encrypted form, unreadable except by
      those it is intended for. Once in this form, the message may only be
      interpreted through the use of a secret key. Without the key the
      message is useless: good cryptographic algorithms make it so difficult
      for intruders to decode the original text that it isn't worth their
      effort.</p>
  
      <p>There are two categories of cryptographic algorithms: conventional
      and public key.</p>
  
      <dl>
      <dt>Conventional cryptography</dt>
      <dd>also known as symmetric cryptography, requires the sender and
      receiver to share a key: a secret piece of information that may be
      used to encrypt or decrypt a message. If this key is secret, then
      nobody other than the sender or receiver may read the message. If
      Alice and the bank know a secret key, then they may send each other
      private messages. The task of privately choosing a key before
      communicating, however, can be problematic.</dd>
  
      <dt>Public key cryptography</dt>
      <dd>also known as asymmetric cryptography, solves the key exchange
      problem by defining an algorithm which uses two keys, each of which
      may be used to encrypt a message. If one key is used to encrypt a
      message then the other must be used to decrypt it. This makes it
      possible to receive secure messages by simply publishing one key
      (the public key) and keeping the other secret (the private key).</dd>
      </dl>
  
      <p>Anyone may encrypt a message using the public key, but only the
      owner of the private key will be able to read it. In this way, Alice
      may send private messages to the owner of a key-pair (the bank), by
      encrypting it using their public key. Only the bank will be able to
      decrypt it.</p>
  </section>
  
  <section id="messagedigests">
  <title>Message Digests</title>
      <p>Although Alice may encrypt her message to make it private, there
      is still a concern that someone might modify her original message or
      substitute it with a different one, in order to transfer the money
      to themselves, for instance. One way of guaranteeing the integrity
      of Alice's message is to create a concise summary of her message and
      send this to the bank as well. Upon receipt of the message, the bank
      creates its own summary and compares it with the one Alice sent. If
      they agree then the message was received intact.</p>
  
      <p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way
  function</em> or <em>hash function</em>. Message digests are used to create
  short, fixed-length representations of longer, variable-length messages.
  Digest algorithms are designed to produce unique digests for different
  messages. Message digests are designed to make it too difficult to determine
  the message from the digest, and also impossible to find two different
  messages which create the same digest -- thus eliminating the possibility of
  substituting one message for another while maintaining the same digest.</p>
  <p>Another challenge that Alice faces is finding a way to send the digest to the
  bank securely; when this is achieved, the integrity of the associated message
  is assured. One way to to this is to include the digest in a digital
  signature.</p>
  </section>
  
  <section id="digitalsignatures"><title>Digital Signatures</title>
  <p>When Alice sends a message to the bank, the bank needs to ensure that the
  message is really from her, so an intruder does not request a transaction
  involving her account. A <em>digital signature</em>, created by Alice and
  included with the message, serves this purpose.</p>
  
  <p>Digital signatures are created by encrypting a digest of the message,
  and other information (such as a sequence number) with the sender's
  private key. Though anyone may <em>decrypt</em> the signature using the public
  key, only the signer knows the private key. This means that only they may
  have signed it. Including the digest in the signature means the signature is
  only good for that message; it also ensures the integrity of the message since
  no one can change the digest and still sign it.</p>
  <p>To guard against interception and reuse of the signature by an intruder at a
  later date, the signature contains a unique sequence number. This protects
  the bank from a fraudulent claim from Alice that she did not send the message
  -- only she could have signed it (non-repudiation).</p>
  </section>
  </section>
  <!-- /cryptographictech -->
  
  <section id="certificates">
  <title>Certificates</title>
  <p>Although Alice could have sent a private message to the bank, signed
  it, and ensured the integrity of the message, she still needs to be sure
  that she is really communicating with the bank. This means that she needs
  to be sure that the public key she is using corresponds to the bank's
  private key. Similarly, the bank also needs to verify that the message
  signature really corresponds to Alice's signature.</p>
  
  <p>If each party has a certificate which validates the other's identity,
  confirms the public key, and is signed by a trusted agency, then they both
  will be assured that they are communicating with whom they think they are.
  Such a trusted agency is called a <em>Certificate Authority</em>, and
  certificates are used for authentication.</p>
  
  <section id="certificatecontents">
  <title>Certificate Contents</title>
      <p>A certificate associates a public key with the real identity of
      an individual, server, or other entity, known as the subject. As
      shown in <a href="#table1">Table 1</a>, information about the subject
      includes identifying information (the distinguished name), and the
      public key. It also includes the identification and signature of the
      Certificate Authority that issued the certificate, and the period of
      time during which the certificate is valid. It may have additional
      information (or extensions) as well as administrative information
      for the Certificate Authority's use, such as a serial number.</p>
  
      <section id="table1">
      <title>Table 1: Certificate Information</title>
      <table>
      <tr><th>Subject</th>
          <td>Distinguished Name, Public Key</td></tr>
      <tr><th>Issuer</th>
          <td>Distinguished Name, Signature</td></tr>
      <tr><th>Period of Validity</th>
          <td>Not Before Date, Not After Date</td></tr>
      <tr><th>Administrative Information</th>
          <td>Version, Serial Number</td></tr>
      <tr><th>Extended Information</th>
          <td>Basic Contraints, Netscape Flags, etc.</td></tr>
      </table>
      </section>
  
      <p>A distinguished name is used to provide an identity in a specific
      context -- for instance, an individual might have a personal
      certificate as well as one for their identity as an employee.
      Distinguished names are defined by the X.509 standard [<a
      href="#X509">X509</a>], which defines the fields, field names, and
      abbreviations used to refer to the fields (see <a href="#table2">Table
      2</a>).</p>
  
      <section id="table2">
      <title>Table 2: Distinguished Name Information</title>
      <table border="1">
      <tr><th>DN Field</th>
          <th>Abbrev.</th>
          <th>Description</th>
          <th>Example</th></tr>
      <tr><td>Common Name</td>
          <td>CN</td>
          <td>Name being certified</td>
          <td>CN=Joe Average</td></tr>
      <tr><td>Organization or Company</td>
          <td>O</td>
          <td>Name is associated with this<br />organization</td>
          <td>O=Snake Oil, Ltd.</td></tr>
      <tr><td>Organizational Unit</td>
          <td>OU</td>
          <td>Name is associated with this <br />organization unit, such
          as a department</td>
          <td>OU=Research Institute</td></tr>
      <tr><td>City/Locality</td>
          <td>L</td>
          <td>Name is located in this City</td>
          <td>L=Snake City</td></tr>
      <tr><td>State/Province</td>
          <td>ST</td>
          <td>Name is located in this State/Province</td>
          <td>ST=Desert</td></tr>
      <tr><td>Country</td>
          <td>C</td>
          <td>Name is located in this Country (ISO code)</td>
          <td>C=XZ</td></tr>
      </table>
      </section>
  
      <p>A Certificate Authority may define a policy specifying which
      distinguished field names are optional, and which are required. It
      may also place requirements upon the field contents, as may users of
      certificates. As an example, a Netscape browser requires that the
      Common Name for a certificate representing a server has a name which
      matches a wildcard pattern for the domain name of that server, such
      as <code>*.snakeoil.com</code>.</p>
  
      <p>The binary format of a certificate is defined using the ASN.1
      notation [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>]. This
      notation defines how to specify the contents, and encoding rules
      define how this information is translated into binary form. The binary
      encoding of the certificate is defined using Distinguished Encoding
      Rules (DER), which are based on the more general Basic Encoding Rules
      (BER). For those transmissions which cannot handle binary, the binary
      form may be translated into an ASCII form by using Base64 encoding
      [<a href="#MIME">MIME</a>]. This encoded version is called PEM encoded
      (the name comes from "Privacy Enhanced Mail"), when placed between
      begin and end delimiter lines as illustrated in the following
      example.</p>
  
      <example>
      <title>Example of a PEM-encoded certificate (snakeoil.crt)</title>
      <pre>-----BEGIN CERTIFICATE-----
  MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
  FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
  A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
  cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
  bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
  MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
  a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
  cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
  AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
  gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
  vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
  lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
  HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
  gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
  2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
  dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
  -----END CERTIFICATE-----</pre>
      </example>
  </section>
  
  <section id="certificateauthorities">
  <title>Certificate Authorities</title>
      <p>By first verifying the information in a certificate request
      before granting the certificate, the Certificate Authority assures
      the identity of the private key owner of a key-pair. For instance,
      if Alice requests a personal certificate, the Certificate Authority
      must first make sure that Alice really is the person the certificate
      request claims.</p>
  
      <section id="certificatechains">
      <title>Certificate Chains</title>
          <p>A Certificate Authority may also issue a certificate for
          another Certificate Authority. When examining a certificate,
          Alice may need to examine the certificate of the issuer, for each
          parent Certificate Authority, until reaching one which she has
          confidence in. She may decide to trust only certificates with a
          limited chain of issuers, to reduce her risk of a "bad" certificate
          in the chain.</p>
      </section>
  
      <section id="rootlevelca">
      <title>Creating a Root-Level CA</title>
          <p>As noted earlier, each certificate requires an issuer to assert
          the validity of the identity of the certificate subject, up to
          the top-level Certificate Authority (CA). This presents a problem:
          Since this is who vouches for the certificate of the top-level
          authority, which has no issuer? In this unique case, the
          certificate is "self-signed", so the issuer of the certificate is
          the same as the subject. As a result, one must exercise extra care
          in trusting a self-signed certificate. The wide publication of a
          public key by the root authority reduces the risk in trusting this
          key -- it would be obvious if someone else publicized a key
          claiming to be the authority. Browsers are preconfigured to trust
          well-known certificate authorities.</p>
  
          <p>A number of companies, such as <a href="http://www.thawte.com/"
          >Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a>
          have established themselves as Certificate Authorities. These
          companies provide the following services:</p>
  
          <ul>
          <li>Verifying certificate requests</li>
          <li>Processing certificate requests</li>
          <li>Issuing and managing certificates</li>
          </ul>
  
          <p>It is also possible to create your own Certificate Authority.
          Although risky in the Internet environment, it may be useful
          within an Intranet where the organization can easily verify the
          identities of individuals and servers.</p>
      </section>
  
      <section id="certificatemanagement">
      <title>Certificate Management</title>
          <p>Establishing a Certificate Authority is a responsibility which
          requires a solid administrative, technical, and management
          framework. Certificate Authorities not only issue certificates,
          they also manage them -- that is, they determine how long
          certificates are valid, they renew them, and they keep lists of
          certificates that have already been issued but are no longer valid
          (Certificate Revocation Lists, or CRLs). Say Alice is entitled to
          a certificate as an employee of a company. Say too, that the
          certificate needs to be revoked when Alice leaves the company. Since
          certificates are objects that get passed around, it is impossible
          to tell from the certificate alone that it has been revoked. When
          examining certificates for validity, therefore, it is necessary to
          contact the issuing Certificate Authority to check CRLs -- this
          is not usually an automated part of the process.</p>
  
          <note><title>Note</title>
          <p>If you use a Certificate Authority that is not configured into
          browsers by default, it is necessary to load the Certificate
          Authority certificate into the browser, enabling the browser to
          validate server certificates signed by that Certificate Authority.
          Doing so may be dangerous, since once loaded, the browser will
          accept all certificates signed by that Certificate Authority.</p>
          </note>
      </section>
  </section>
  <!-- /certificateauthorities -->
  </section>
  <!-- /certificates -->
  
  <section id="ssl">
  <title>Secure Sockets Layer (SSL)</title>
  <p>The Secure Sockets Layer protocol is a protocol layer which may be
  placed between a reliable connection-oriented network layer protocol
  (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides
  for secure communication between client and server by allowing mutual
  authentication, the use of digital signatures for integrity, and encryption
  for privacy.</p>
  
  <p>The protocol is designed to support a range of choices for specific
  algorithms used for cryptography, digests, and signatures. This allows
  algorithm selection for specific servers to be made based on legal, export
  or other concerns, and also enables the protocol to take advantage of new
  algorithms. Choices are negotiated between client and server at the start
  of establishing a protocol session.</p>
  
  <section id="table4">
  <title>Table 4: Versions of the SSL protocol</title>
      <table border="1">
      <tr><th>Version</th>
          <th>Source</th>
          <th>Description</th>
          <th>Browser Support</th></tr>
      <tr><td>SSL v2.0</td>
          <td>Vendor Standard (from Netscape Corp.) [<a href="#SSL2"
          >SSL2</a>]</td>
          <td>First SSL protocol for which implementations exists</td>
          <td>- NS Navigator 1.x/2.x<br />
          - MS IE 3.x<br />
          - Lynx/2.8+OpenSSL</td></tr>
      <tr><td>SSL v3.0</td>
          <td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3"
          >SSL3</a>]</td>
          <td>Revisions to prevent specific security attacks, add non-RSA
          ciphers, and support for certificate chains</td>
          <td>- NS Navigator 2.x/3.x/4.x<br />
          - MS IE 3.x/4.x<br />
          - Lynx/2.8+OpenSSL</td></tr>
      <tr><td>TLS v1.0</td>
          <td>Proposed Internet Standard (from IETF) [<a href="#TLS1"
          >TLS1</a>]</td>
          <td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block
          padding for block ciphers, message order standardization and more
          alert messages.</td>
          <td>- Lynx/2.8+OpenSSL</td></tr>
      </table>
  </section>
  
  <p>There are a number of versions of the SSL protocol, as shown in 
  <a href="#table4">Table 4</a>. As noted there, one of the benefits in
  SSL 3.0 is that it adds support of certificate chain loading. This feature
  allows a server to pass a server certificate along with issuer certificates
  to the browser. Chain loading also permits the browser to validate the
  server certificate, even if Certificate Authority certificates are not
  installed for the intermediate issuers, since they are included in the
  certificate chain. SSL 3.0 is the basis for the Transport Layer Security 
  [<a href="#TLS1">TLS</a>] protocol standard, currently in development by
  the Internet Engineering Task Force (IETF).</p>
  
  <section id="session">
  <title>Session Establishment</title>
      <p>The SSL session is established by following a handshake sequence
      between client and server, as shown in <a href="#figure1"
      >Figure 1</a>. This sequence may vary, depending on whether the server
      is configured to provide a server certificate or request a client
      certificate. Though cases exist where additional handshake steps
      are required for management of cipher information, this article
      summarizes one common scenario: see the SSL specification for the full
      range of possibilities.</p>
  
      <note><title>Note</title>
      <p>Once an SSL session has been established it may be reused, thus
      avoiding the performance penalty of repeating the many steps needed
      to start a session. For this the server assigns each SSL session a
      unique session identifier which is cached in the server and which the
      client can use on forthcoming connections to reduce the handshake
      (until the session identifer expires in the cache of the server).</p>
      </note>
  
      <p class="figure">
      <img src="ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
      <a id="figure1" name="figure1"><dfn>Figure 1</dfn></a>: Simplified SSL
      Handshake Sequence</p>
  
      <p>The elements of the handshake sequence, as used by the client and
      server, are listed below:</p>
  
      <ol>
      <li>Negotiate the Cipher Suite to be used during data transfer</li>
      <li>Establish and share a session key between client and server</li>
      <li>Optionally authenticate the server to the client</li>
      <li>Optionally authenticate the client to the server</li>
      </ol>
  
      <p>The first step, Cipher Suite Negotiation, allows the client and
      server to choose a Cipher Suite supportable by both of them. The SSL3.0
      protocol specification defines 31 Cipher Suites. A Cipher Suite is
      defined by the following components:</p>
  
      <ul>
      <li>Key Exchange Method</li>
      <li>Cipher for Data Transfer</li>
      <li>Message Digest for creating the Message Authentication Code (MAC)</li>
      </ul>
  
      <p>These three elements are described in the sections that follow.</p>
  </section>
  
  <section id="keyexchange">
  <title>Key Exchange Method</title>
      <p>The key exchange method defines how the shared secret symmetric
      cryptography key used for application data transfer will be agreed
      upon by client and server. SSL 2.0 uses RSA key exchange only, while
      SSL 3.0 supports a choice of key exchange algorithms including the
      RSA key exchange when certificates are used, and Diffie-Hellman key
      exchange for exchanging keys without certificates and without prior
      communication between client and server.</p>
  
      <p>One variable in the choice of key exchange methods is digital
      signatures -- whether or not to use them, and if so, what kind of
      signatures to use. Signing with a private key provides assurance
      against a man-in-the-middle-attack during the information exchange
      used in generating the shared key [<a href="#AC96">AC96</a>, p516].</p>
  </section>
  
  <section id="ciphertransfer">
  <title>Cipher for Data Transfer</title>
      <p>SSL uses the conventional cryptography algorithm (symmetric
      cryptography) described earlier for encrypting messages in a session.
      There are nine choices, including the choice to perform no
      encryption:</p>
  
      <ul>
      <li>No encryption</li>
      <li>Stream Ciphers
          <ul>
          <li>RC4 with 40-bit keys</li>
          <li>RC4 with 128-bit keys</li>
          </ul></li>
      <li>CBC Block Ciphers
          <ul><li>RC2 with 40 bit key</li>
          <li>DES with 40 bit key</li>
          <li>DES with 56 bit key</li>
          <li>Triple-DES with 168 bit key</li>
          <li>Idea (128 bit key)</li>
          <li>Fortezza (96 bit key)</li>
          </ul></li>
      </ul>
  
      <p>Here "CBC" refers to Cipher Block Chaining, which means that a
      portion of the previously encrypted cipher text is used in the
      encryption of the current block. "DES" refers to the Data Encryption
      Standard [<a href="#AC96">AC96</a>, ch12], which has a number of
      variants (including DES40 and 3DES_EDE). "Idea" is one of the best
      and cryptographically strongest available algorithms, and "RC2" is
      a proprietary algorithm from RSA DSI [<a href="#AC96">AC96</a>,
      ch13].</p>
  </section>
  
  <section id="digestfuntion">
  <title>Digest Function</title>
      <p>The choice of digest function determines how a digest is created
      from a record unit. SSL supports the following:</p>
  
      <ul>
      <li>No digest (Null choice)</li>
      <li>MD5, a 128-bit hash</li>
      <li>Secure Hash Algorithm (SHA-1), a 160-bit hash</li>
      </ul>
  
      <p>The message digest is used to create a Message Authentication Code
      (MAC) which is encrypted with the message to provide integrity and to
      prevent against replay attacks.</p>
  </section>
  
  <section id="handshake">
  <title>Handshake Sequence Protocol</title>
      <p>The handshake sequence uses three protocols:</p>
  
      <ul>
      <li>The <dfn>SSL Handshake Protocol</dfn>
      for performing the client and server SSL session establishment.</li>
      <li>The <dfn>SSL Change Cipher Spec Protocol</dfn> for actually
      establishing agreement on the Cipher Suite for the session.</li>
      <li>The <dfn>SSL Alert Protocol</dfn> for conveying SSL error
      messages between client and server.</li>
      </ul>
  
      <p>These protocols, as well as application protocol data, are
      encapsulated in the <dfn>SSL Record Protocol</dfn>, as shown in
      <a href="#figure2">Figure 2</a>. An encapsulated protocol is
      transferred as data by the lower layer protocol, which does not
      examine the data. The encapsulated protocol has no knowledge of the
      underlying protocol.</p>
  
      <p class="figure">
      <img src="ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
      <a id="figure2" name="figure2"><dfn>Figure 2</dfn></a>: SSL Protocol Stack
      </p>
  
      <p>The encapsulation of SSL control protocols by the record protocol
      means that if an active session is renegotiated the control protocols
      will be transmitted securely. If there were no session before, then
      the Null cipher suite is used, which means there is no encryption and
      messages have no integrity digests until the session has been
      established.</p>
  </section>
  
  <section id="datatransfer">
  <title>Data Transfer</title>
      <p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>,
      is used to transfer application and SSL Control data between the
      client and server, possibly fragmenting this data into smaller units,
      or combining multiple higher level protocol data messages into single
      units. It may compress, attach digest signatures, and encrypt these
      units before transmitting them using the underlying reliable transport
      protocol (Note: currently all major SSL implementations lack support
      for compression).</p>
  
      <p class="figure">
      <img src="ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
      <a id="figure3" name="figure3"><dfn>Figure 3</dfn></a>: SSL Record Protocol
      </p>
  </section>
  
  <section id="securehttp">
  <title>Securing HTTP Communication</title>
      <p>One common use of SSL is to secure Web HTTP communication between
      a browser and a webserver. This case does not preclude the use of
      non-secured HTTP. The secure version is mainly plain HTTP over SSL
      (named HTTPS), but with one major difference: it uses the URL scheme
      <code>https</code> rather than <code>http</code> and a different
      server port (by default 443). This mainly is what <module
      >mod_ssl</module> provides to you for the Apache webserver...</p>
  </section>
  </section>
  <!-- /ssl -->
  
  <section id="references">
  <title>References</title>
  <dl>
  <dt><a id="AC96" name="AC96">[AC96]</a></dt>
  <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
  1996. See <a href="http://www.counterpane.com/"
  >http://www.counterpane.com/</a> for various other materials by Bruce
  Schneier.</dd>
  
  <dt><a id="X208" name="X208">[X208]</a></dt>
  <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
  One (ASN.1)</q>, 1988. See for instance <a
  href="http://www.itu.int/rec/recommendation.asp?type=items&amp;lang=e&amp;parent=T-REC-X.208-198811-I"
  >http://www.itu.int/rec/recommendation.asp?type=items&amp;lang=e&amp;parent=T-REC-X.208-198811-I</a>.
  </dd>
  
  <dt><a id="X509" name="X509">[X509]</a></dt>
  <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
  Framework</q>. See for instance <a
  href="http://www.itu.int/rec/recommendation.asp?type=folders&amp;lang=e&amp;parent=T-REC-X.509"
  >http://www.itu.int/rec/recommendation.asp?type=folders&amp;lang=e&amp;parent=T-REC-X.509</a>.
  </dd>
  
  <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
  <dd><q>Public Key Cryptography Standards (PKCS)</q>, 
  RSA Laboratories Technical Notes, See <a
  href="http://www.rsasecurity.com/rsalabs/pkcs/"
  >http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
  
  <dt><a id="MIME" name="MIME">[MIME]</a></dt>
  <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
  (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
  See for instance <a href="http://ietf.org/rfc/rfc2045.txt"
  >http://ietf.org/rfc/rfc2045.txt</a>.</dd>
  
  <dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
  <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>
  
  <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
  <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
  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>
  
  <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
  <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
  1999. See <a href="http://ietf.org/rfc/rfc2246.txt"
  >http://ietf.org/rfc/rfc2246.txt</a>.</dd>
  </dl>
  </section>
  <!-- /references -->
  
  </manualpage>
  
  
  

Mime
View raw message