<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
<li><a href="ssl_compat.html">\e$B8_49@-\e(B</a></li>
<li><a href="ssl_howto.html">How-To</a></li>
<li><a href="ssl_faq.html">
\e$B$h$/$"$k<ALd
\e(B</a></li>
-<li><a href="ssl_glossary.html">\e$BMQ8l\e(B</a></li>
+<li><a href="../glossary.html">\e$BMQ8l\e(B</a></li>
</ul>
<p>\e$B$3$N%b%8%e!<%k$GDs6!$5$l$k%G%#%l%/%F%#%V$d4D6-JQ?t$K4X$9$k\e(B
<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>
<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>
<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 & 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 & 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>
<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>
<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>
<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
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>
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><a href="document.html:SSL"></code></p></div>
+ <p>This rewrite ruleset lets you use hyperlinks of the form
+ <code><a href="document.html:SSL"></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>
<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
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>
RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L]
</example>
- This rewrite ruleset lets you use hyperlinks of the form
- <example><a href="document.html:SSL"></example>
+ <p>This rewrite ruleset lets you use hyperlinks of the form
+ <code><a href="document.html:SSL"></code></p>
</section>
</section>
<!-- configuration -->
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
-<title>Apache SSL/TLS Encryption: Glossary</title>
-<style type="text/css"><!--
-#H {
-}
-#D {
- background-color: #f0f0f0;
-}
---></style>
-</head>
-
-<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#000080" alink="#FF0000">
-<!--#include virtual="header.html" -->
-
-<h1 align="center">SSL/TLS Strong Encryption: Glossary</h1>
-
-<div align="right">
-<table cellspacing="0" cellpadding="0" width="300" summary="">
-<tr>
-<td>
-<em>
-``I know you believe you understand what you think I said, but I am not sure you
-realize that what you heard is not what I meant.''
-</em>
-</td>
-</tr>
-<tr>
-<td align="right">
-<font size="-1">
-Richard Nixon
-</font>
-</td>
-</tr>
-</table>
-</div>
-
-<dl>
-<dt>Authentication</dt>
-<dd>The positive identification of a network entity such as a server, a
- client, or a user. In SSL context the server and client
- <em>Certificate</em> verification process.
-</dd>
-</dl>
-
-<dl>
-<dt>Access Control</dt>
-<dd>The restriction of access to network realms. In Apache context
- usually the restriction of access to certain <em>URLs</em>.
-</dd>
-</dl>
-
-<dl>
-<dt>Algorithm</dt>
-<dd>An unambiguous formula or set of rules for solving a problem in a finite
- number of steps. Algorithms for encryption are usually called <em>Ciphers</em>.
-</dd>
-</dl>
-
-<dl>
-<dt>Certificate</dt>
-<dd>A data record used for authenticating network entities such
- as a server or a client. A certificate contains X.509 information pieces
- about its owner (called the subject) and the signing <em>Certificate
- Authority</em> (called the issuer), plus the owner's public key and the
- signature made by the CA. Network entities verify these signatures using
- CA certificates.
-</dd>
-</dl>
-
-<dl>
-<dt>Certification Authority (CA)</dt>
-<dd>A trusted third party whose purpose is to sign certificates for network
- entities it has authenticated using secure means. Other network entities
- can check the signature to verify that a CA has authenticated the bearer
- of a certificate.
-</dd>
-</dl>
-
-<dl>
-<dt>Certificate Signing Request (CSR)</dt>
-<dd>An unsigned certificate for submission to a <em>Certification Authority</em>,
- which signs it with the <em>Private Key</em> of their CA <em>Certificate</em>. Once
- the CSR is signed, it becomes a real certificate.
-</dd>
-</dl>
-
-<dl>
-<dt>Cipher</dt>
-<dd>An algorithm or system for data encryption. Examples are DES, IDEA, RC4, etc.
-</dd>
-</dl>
-
-<dl>
-<dt>Ciphertext</dt>
-<dd>The result after a <em>Plaintext</em> passed a <em>Cipher</em>.
-</dd>
-</dl>
-
-<dl>
-<dt>Configuration Directive</dt>
-<dd>A configuration command that controls one or more aspects of a program's
- behavior. In Apache context these are all the command names in the first
- column of the configuration files.
-</dd>
-</dl>
-
-<dl>
-<dt>CONNECT</dt>
-<dd>A HTTP command for proxying raw data channels over HTTP. It can be used to
- encapsulate other protocols, such as the SSL protocol.
-</dd>
-</dl>
-
-<dl>
-<dt>Digital Signature</dt>
-<dd>An encrypted text block that validates a certificate or other file. A
- <em>Certification Authority</em> creates a signature by generating a
- hash of the <em>Public Key</em> embedded in a <em>Certificate</em>, then
- encrypting the hash with its own <em>Private Key</em>. Only the CA's
- public key can decrypt the signature, verifying that the CA has
- authenticated the network entity that owns the <em>Certificate</em>.
-</dd>
-</dl>
-
-<dl>
-<dt>Export-Crippled</dt>
-<dd>Diminished in cryptographic strength (and security) in order to comply
- with the United States' Export Administration Regulations (EAR).
- Export-crippled cryptographic software is limited to a small key size,
- resulting in <em>Ciphertext</em> which usually can be decrypted by brute
- force.
-</dd>
-</dl>
-
-<dl>
-<dt>Fully-Qualified Domain-Name (FQDN)</dt>
-<dd>The unique name of a network entity, consisting of a hostname and a domain
- name that can resolve to an IP address. For example, <code>www</code> is a
- hostname, <code>whatever.com</code> is a domain name, and
- <code>www.whatever.com</code> is a fully-qualified domain name.
-</dd>
-</dl>
-
-<dl>
-<dt>HyperText Transfer Protocol (HTTP)</dt>
-<dd>The HyperText Transport Protocol is the standard transmission protocol used
- on the World Wide Web.
-</dd>
-</dl>
-
-<dl>
-<dt>HTTPS</dt>
-<dd>The HyperText Transport Protocol (Secure), the standard encrypted
- communication mechanism on the World Wide Web. This is actually just HTTP
- over SSL.
-</dd>
-</dl>
-
-<dl>
-<dt>Message Digest</dt>
-<dd>A hash of a message, which can be used to verify that the contents of
- the message have not been altered in transit.
-</dd>
-</dl>
-
-<dl>
-<dt>OpenSSL</dt>
-<dd>The Open Source toolkit for SSL/TLS;
- see <a href="http://www.openssl.org/">http://www.openssl.org/</a>
-</dd>
-</dl>
-
-<dl>
-<dt>Pass Phrase</dt>
-<dd>The word or phrase that protects private key files.
- It prevents unauthorized users from encrypting them. Usually it's just
- the secret encryption/decryption key used for <em>Ciphers</em>.
-</dd>
-</dl>
-
-<dl>
-<dt>Plaintext</dt>
-<dd>The unencrypted text.
-</dd>
-</dl>
-
-<dl>
-<dt>Private Key</dt>
-<dd>The secret key in a <em>Public Key Cryptography</em> system, used to
- decrypt incoming messages and sign outgoing ones.
-</dd>
-</dl>
-
-<dl>
-<dt>Public Key</dt>
-<dd>The publically available key in a <em>Public Key Cryptography</em> system, used to
- encrypt messages bound for its owner and to decrypt signatures made by its
- owner.
-</dd>
-</dl>
-
-<dl>
-<dt>Public Key Cryptography</dt>
-<dd>The study and application of asymmetric encryption systems, which use one
- key for encryption and another for decryption. A corresponding pair of
- such keys constitutes a key pair. Also called Asymmetric Crypography.
-</dd>
-</dl>
-
-<dl>
-<dt>Secure Sockets Layer (SSL)</dt>
-<dd>A protocol created by Netscape Communications Corporation for
- general communication authentication and encryption over TCP/IP networks.
- The most popular usage is <em>HTTPS</em>, i.e. the HyperText Transfer
- Protocol (HTTP) over SSL.
-</dd>
-</dl>
-
-<dl>
-<dt>Session</dt>
-<dd>The context information of an SSL communication.
-</dd>
-</dl>
-
-<dl>
-<dt>SSLeay</dt>
-<dd>The original SSL/TLS implementation library developed by
- Eric A. Young <eay@aus.rsa.com>;
- see <a href="http://www.ssleay.org/">http://www.ssleay.org/</a>
-</dd>
-</dl>
-
-<dl>
-<dt>Symmetric Cryptography</dt>
-<dd>The study and application of <em>Ciphers</em> that use a single secret key
- for both encryption and decryption operations.
-</dd>
-</dl>
-
-<dl>
-<dt>Transport Layer Security (TLS)</dt>
-<dd>The successor protocol to SSL, created by the Internet Engineering Task
- Force (IETF) for general communication authentication and encryption over
- TCP/IP networks. TLS version 1 and is nearly identical with SSL version 3.
-</dd>
-</dl>
-
-<dl>
-<dt>Uniform Resource Locator (URL)</dt>
-<dd>The formal identifier to locate various resources on the World Wide Web.
- The most popular URL scheme is <code>http</code>. SSL uses the
- scheme <code>https</code>
-</dd>
-</dl>
-
-<dl>
-<dt>X.509</dt>
-<dd>An authentication certificate scheme recommended by the International
- Telecommunication Union (ITU-T) which is used for SSL/TLS authentication.
-</dd>
-</dl>
-
- <!--#include virtual="footer.html" -->
- </body>
-</html>
\ No newline at end of file
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
-<title>Apache SSL/TLS Encryption: How-To</title>
-<style type="text/css"><!--
-#H {
-}
-#D {
- background-color: #f0f0f0;
-}
---></style>
-</head>
-
-<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#000080" alink="#FF0000">
-<!--#include virtual="header.html" -->
-
-<h1 align="center">SSL/TLS Strong Encryption: How-To</h1>
-
-
-<div align="right">
-<table cellspacing="0" cellpadding="0" width="200" summary="">
-<tr>
-<td>
-<em>
-``The solution of this problem is trivial
- and is left as an exercise for the reader.''
-</em>
-</td>
-</tr>
-<tr>
-<td align="right">
-<font size="-1">
-Standard textbook cookie
-</font>
-</td>
-</tr>
-</table>
-</div>
-
-<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>
-
-<ul>
-<li><a href="#ToC1">Cipher Suites and Enforced Strong Security</a></li>
-<li><a href="#ToC2">SSLv2 only server</a></li>
-<li><a href="#ToC3">strong encryption only server</a></li>
-<li><a href="#ToC4">server gated cryptography</a></li>
-<li><a href="#ToC5">stronger per-directory requirements</a></li>
-<li><a href="#ToC6">Client Authentication and Access Control</a></li>
-<li><a href="#ToC7">simple certificate-based client authentication</a></li>
-<li><a href="#ToC8">selective certificate-based client authentication</a></li>
-<li><a href="#ToC9">particular certificate-based client authentication</a></li>
-<li><a href="#ToC10">intranet vs. internet authentication</a></li>
-</ul>
-
-<h2><a name="ToC1">Cipher Suites and Enforced Strong Security</a></h2>
-<ul>
-<li><a name="ToC2"></a>
- <a name="cipher-sslv2"></a>
- <strong>
-How can I create a real SSLv2-only server?
-</strong>
- [<a href="http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html#cipher-sslv2"><b>L</b></a>]
- <p>The following creates an SSL server which speaks only the SSLv2 protocol and
- its ciphers.</p>
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- SSLProtocol -all +SSLv2
- SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-</li>
-<li><a name="ToC3"></a>
- <a name="cipher-strong"></a>
- <strong>
-How can I create an SSL server which accepts strong encryption only?
-</strong>
- [<a href="http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html#cipher-strong"><b>L</b></a>]
- <p>The following enables only the seven strongest ciphers:</p>
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- SSLProtocol all
- SSLCipherSuite HIGH:MEDIUM
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-</li>
-<li><a name="ToC4"></a>
- <a name="cipher-sgc"></a>
- <strong>
-How can I create an SSL server which accepts strong encryption only,
-but allows export browsers to upgrade to stronger encryption?
-</strong>
- [<a href="http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html#cipher-sgc"><b>L</b></a>]
- <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>
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- # allow all ciphers for the inital handshake,
- # so export browsers can upgrade via SGC facility
- SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
- <Directory /usr/local/apache/htdocs>
- # but finally deny all browsers which haven't upgraded
- SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
- </Directory>
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-</li>
-<li><a name="ToC5"></a>
- <a name="cipher-perdir"></a>
- <strong>
-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?
-</strong>
- [<a href="http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html#cipher-perdir"><b>L</b></a>]
- <p>Obviously you cannot just use a server-wide <code>SSLCipherSuite</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>
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- # be liberal in general
- SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
- <Location /strong/area>
- # but https://hostname/strong/area/ and below requires strong ciphers
- SSLCipherSuite HIGH:MEDIUM
- </Location>
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-</li>
-</ul>
-<h2><a name="ToC6">Client Authentication and Access Control</a></h2>
-<ul>
-<li><a name="ToC7"></a>
- <a name="auth-simple"></a>
- <strong>
-How can I authenticate clients based on certificates when I know all my
-clients?
-</strong>
- [<a href="http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html#auth-simple"><b>L</b></a>]
- <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>
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- # require a client certificate which has to be directly
- # signed by our CA certificate in ca.crt
- SSLVerifyClient require
- SSLVerifyDepth 1
- SSLCACertificateFile conf/ssl.crt/ca.crt
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-</li>
-<li><a name="ToC8"></a>
- <a name="auth-selective"></a>
- <strong>
-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?
-</strong>
- [<a href="http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html#auth-selective"><b>L</b></a>]
- <p>For this we again use the per-directory reconfiguration feature of mod_ssl:</p>
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- SSLVerifyClient none
- SSLCACertificateFile conf/ssl.crt/ca.crt
- <Location /secure/area>
- SSLVerifyClient require
- SSLVerifyDepth 1
- </Location>
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-</li>
-<li><a name="ToC9"></a>
- <a name="auth-particular"></a>
- <strong>
-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?
-</strong>
- [<a href="http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html#auth-particular"><b>L</b></a>]
- <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>mod_auth</code> based variant
- and the <code>SSLRequire</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>
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- SSLVerifyClient none
- <Directory /usr/local/apache/htdocs/secure/area>
- 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/apache/conf/httpd.passwd
- require valid-user
- </Directory>
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-<br />
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.passwd</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <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>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-
- <p>The second method:</p>
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- SSLVerifyClient none
- <Directory /usr/local/apache/htdocs/secure/area>
- 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"}
- </Directory>
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-</li>
-<li><a name="ToC10"></a>
- <a name="auth-intranet"></a>
- <strong> 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?
-</strong>
- [<a href="http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html#auth-intranet"><b>L</b></a>]
- <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
- <tt>/subarea</tt>. Then configure the following outside your HTTPS virtual
- host (so it applies to both HTTPS and HTTP):</p>
-
- <table border="0" cellpadding="0" cellspacing="0" summary="">
- <tr>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="8" align="bottom" border="0" /></td>
- <td rowspan="3"> <font face="Arial,Helvetica" color="#999999">httpd.conf</font> </td>
- <td colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc" colspan="2"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="40" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#ffffff"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="300" height="1" align="bottom" border="0" /></td>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="5" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- <td colspan="3" bgcolor="#ffffff">
- <table border="0" cellspacing="4" summary="">
- <tr>
- <td>
- <pre>
-
- SSLCACertificateFile conf/ssl.crt/company-ca.crt
-
- <Directory /usr/local/apache/htdocs>
- # Outside the subarea only Intranet access is granted
- Order deny,allow
- Deny from all
- Allow from 192.168.1.0/24
- </Directory>
-
- <Directory /usr/local/apache/htdocs/subarea>
- # 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} >= 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
- </Directory>
-
- </pre>
- </td>
- </tr>
- </table>
- </td>
-
- <td bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- <tr>
- <td colspan="5" bgcolor="#cccccc"><img src="ssl_template.imgdot-1x1-transp.gif" alt="" width="1" height="1" align="bottom" border="0" /></td>
- </tr>
- </table>
-</li>
-</ul>
-
- <!--#include virtual="footer.html" -->
- </body>
-</html>
--- /dev/null
+<?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="<-" alt="<-" src="../images/left.gif" /></a></div><div id="path"><a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <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 />
+ <Directory /usr/local/apache2/htdocs><br />
+ # but finally deny all browsers which haven't upgraded<br />
+ SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128<br />
+ </Directory>
+ </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 />
+ <Location /strong/area><br />
+ # but https://hostname/strong/area/ and below<br />
+ # requires strong ciphers<br />
+ SSLCipherSuite HIGH:MEDIUM<br />
+ </Location>
+ </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 />
+ <Location /secure/area><br />
+ SSLVerifyClient require<br />
+ SSLVerifyDepth 1<br />
+ </Location><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
+<Directory /usr/local/apache2/htdocs/secure/area>
+
+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
+</Directory></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
+<Directory /usr/local/apache2/htdocs/secure/area>
+
+ 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"}
+</Directory></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
+
+<Directory /usr/local/apache2/htdocs>
+# Outside the subarea only Intranet access is granted
+Order deny,allow
+Deny from all
+Allow from 192.168.1.0/24
+</Directory>
+
+<Directory /usr/local/apache2/htdocs/subarea>
+# 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} >= 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
+</Directory></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>
\ No newline at end of file
--- /dev/null
+<?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 />
+ <Directory /usr/local/apache2/htdocs><br />
+ # but finally deny all browsers which haven't upgraded<br />
+ SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128<br />
+ </Directory>
+ </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 />
+ <Location /strong/area><br />
+ # but https://hostname/strong/area/ and below<br />
+ # requires strong ciphers<br />
+ SSLCipherSuite HIGH:MEDIUM<br />
+ </Location>
+ </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 />
+ <Location /secure/area><br />
+ SSLVerifyClient require<br />
+ SSLVerifyDepth 1<br />
+ </Location><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
+<Directory /usr/local/apache2/htdocs/secure/area>
+
+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
+</Directory></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
+<Directory /usr/local/apache2/htdocs/secure/area>
+
+ 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"}
+</Directory></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
+
+<Directory /usr/local/apache2/htdocs>
+# Outside the subarea only Intranet access is granted
+Order deny,allow
+Deny from all
+Allow from 192.168.1.0/24
+</Directory>
+
+<Directory /usr/local/apache2/htdocs/subarea>
+# 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} >= 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
+</Directory></pre>
+ </example>
+</section>
+</section>
+<!-- /access control -->
+
+</manualpage>
+
+
+
+++ /dev/null
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
-<title>Apache SSL/TLS Encryption: An Introduction</title>
-<style type="text/css"><!--
-#H {
-}
-#D {
- background-color: #f0f0f0;
-}
---></style>
-</head>
-
-<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#000080" alink="#FF0000">
-<!--#include virtual="header.html" -->
-
-<h1 align="center">SSL/TLS Strong Encryption: An Introduction</h1>
-
-<div align="right">
-<table cellspacing="0" cellpadding="0" width="400" summary="">
-<tr>
-<td>
-<em>
-``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.''
-</em>
-</td>
-</tr>
-<tr>
-<td align="right">
-<font size="-1">
-A. Tanenbaum, ``Introduction to Computer Networks''
-</font>
-</td>
-</tr>
-</table>
-</div>
-<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"><em>Introducing SSL
-and Certificates using SSLeay</em></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/"><em>Web Security: A Matter of
-Trust</em></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 mod_ssl
-author).</p>
-
-<ul>
-<li><a href="#ToC1">Cryptographic Techniques</a></li>
-<li><a href="#ToC2">Cryptographic Algorithms</a></li>
-<li><a href="#ToC3">Message Digests</a></li>
-<li><a href="#ToC4">Digital Signatures</a></li>
-<li><a href="#ToC5">Certificates</a></li>
-<li><a href="#ToC6">Certificate Contents</a></li>
-<li><a href="#ToC7">Certificate Authorities</a></li>
-<li><a href="#ToC8">Certificate Chains</a></li>
-<li><a href="#ToC9">Creating a Root-Level CA</a></li>
-<li><a href="#ToC10">Certificate Management</a></li>
-<li><a href="#ToC11">Secure Sockets Layer (SSL)</a></li>
-<li><a href="#ToC12">Session Establishment</a></li>
-<li><a href="#ToC13">Key Exchange Method</a></li>
-<li><a href="#ToC14">Cipher for Data Transfer</a></li>
-<li><a href="#ToC15">Digest Function</a></li>
-<li><a href="#ToC16">Handshake Sequence Protocol</a></li>
-<li><a href="#ToC17">Data Transfer</a></li>
-<li><a href="#ToC18">Securing HTTP Communication</a></li>
-<li><a href="#ToC19">References</a></li>
-</ul>
-
-<h2><a name="ToC1">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="ToC2">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>
-<ul>
-<li><em>Conventional cryptography</em>, 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.<br />
-<br />
-</li>
-<li><em>Public key cryptography</em>, 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).
-</li>
-</ul>
-<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="ToC3">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 <em>message digest</em>, <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="ToC4">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>
-<h2><a name="ToC5">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="ToC6">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>
-<div align="center">
-<a name="table1"></a>
-<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
- <caption align="bottom">Table 1: Certificate Information</caption>
- <tr>
- <td bgcolor="#cccccc">
- <table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
- <tr>
- <td valign="top" align="center" bgcolor="#ffffff">
- <table summary="">
- <tr valign="top">
- <td><b>Subject:</b></td>
- <td>Distinguished Name, Public Key</td>
- </tr>
- <tr valign="top">
- <td><b>Issuer:</b></td>
- <td>Distinguished Name, Signature</td>
- </tr>
- <tr>
- <td><b>Period of Validity:</b></td>
- <td>Not Before Date, Not After Date</td>
- </tr>
- <tr>
- <td><b>Administrative Information:</b></td>
- <td>Version, Serial Number</td>
- </tr>
- <tr>
- <td><b>Extended Information:</b></td>
- <td>Basic Contraints, Netscape Flags, etc.</td>
- </tr>
- </table>
- </td>
- </tr>
- </table>
- </td>
- </tr>
-</table>
-</div>
-<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>
-
-<div align="center">
-<a name="table2"></a>
-<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
- <caption align="bottom">Table 2: Distinguished Name Information</caption>
- <tr>
- <td bgcolor="#cccccc">
- <table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
- <tr>
- <td valign="top" align="center" bgcolor="#ffffff">
- <table summary="">
- <tr valign="top">
- <td><b>DN Field:</b></td>
- <td><b>Abbrev.:</b></td>
- <td><b>Description:</b></td>
- <td><b>Example:</b></td>
- </tr>
- <tr valign="top">
- <td>Common Name</td>
- <td>CN</td>
- <td>Name being certified</td>
- <td>CN=Joe Average</td>
- </tr>
- <tr valign="top">
- <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 valign="top">
- <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 valign="top">
- <td>City/Locality</td>
- <td>L</td>
- <td>Name is located in this City</td>
- <td>L=Snake City</td>
- </tr>
- <tr valign="top">
- <td>State/Province</td>
- <td>ST</td>
- <td>Name is located in this State/Province</td>
- <td>ST=Desert</td>
- </tr>
- <tr valign="top">
- <td>Country</td>
- <td>C</td>
- <td>Name is located in this Country (ISO code)</td>
- <td>C=XZ</td>
- </tr>
- </table>
- </td>
- </tr>
- </table>
- </td>
- </tr>
-</table>
-</div>
-<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 <a href="#table3">Table 3</a>.</p>
-
-<div align="center">
-<a name="table3"></a>
-<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
-<caption align="bottom">Table 3: Example of a PEM-encoded certificate (snakeoil.crt)</caption>
-<tr><td bgcolor="#cccccc">
-<table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
-<tr><td valign="top" align="center" bgcolor="#ffffff">
-<table cellspacing="0" cellpadding="0" summary=""><tr><td>
-<div class="code"><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>
-</td></tr></table>
-</td>
-</tr></table>
-</td></tr></table>
-</div>
-<h3><a name="ToC7">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="ToC8">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="ToC9">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="ToC10">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 align="center"><b>Note:</b></div>
-<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>
-<h2><a name="ToC11">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>
-<div align="center">
-<a name="table4"></a>
-<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
- <caption align="bottom">Table 4: Versions of the SSL protocol</caption>
- <tr>
- <td bgcolor="#cccccc">
- <table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
- <tr>
- <td valign="top" align="center" bgcolor="#ffffff">
- <table summary="">
- <tr valign="top">
- <td><b>Version:</b></td>
- <td><b>Source:</b></td>
- <td><b>Description:</b></td>
- <td><b>Browser Support:</b></td>
- </tr>
- <tr valign="top">
- <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 valign="top">
- <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 valign="top">
- <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>
- </td>
- </tr>
- </table>
- </td>
- </tr>
-</table>
-</div>
-<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="ToC12">Session Establishment</a></h3>
-<p>The SSL session is established by following a <a>handshake sequence</a>
-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 align="center"><b>Note</b></div>
-<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 align="center">
-<a name="figure1"></a>
-<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
- <caption align="bottom">Figure 1: Simplified SSL Handshake Sequence</caption>
- <tr>
- <td bgcolor="#cccccc">
- <table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
- <tr>
- <td valign="top" align="center" bgcolor="#ffffff">
- <img src="ssl_intro_fig1.gif" alt="" width="423" height="327" />
- </td>
- </tr>
- </table>
- </td>
- </tr>
- </table>
-</div>
-<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="ToC13">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="ToC14">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="ToC15">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="ToC16">Handshake Sequence Protocol</a></h3>
-<p>The handshake sequence uses three protocols:</p>
-<ul>
-<li>The <em>SSL Handshake Protocol</em>
- for performing the client and server SSL session establishment.
-</li>
-<li>The <em>SSL Change Cipher Spec Protocol</em> for actually establishing agreement
- on the Cipher Suite for the session.
-</li>
-<li>The <em>SSL Alert Protocol</em> for
- conveying SSL error messages between client and server.
-</li>
-</ul>
-These protocols, as well as application protocol data, are encapsulated in the
-<em>SSL Record Protocol</em>, 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.
-<div align="center">
-<a name="figure2"></a>
-<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
- <caption align="bottom">Figure 2: SSL Protocol Stack</caption>
- <tr>
- <td bgcolor="#cccccc">
- <table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
- <tr>
- <td valign="top" align="center" bgcolor="#ffffff">
- <img src="ssl_intro_fig2.gif" alt="" width="428" height="217" />
- </td>
- </tr>
- </table>
- </td>
- </tr>
-</table>
-</div>
-<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="ToC17">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>
-<div align="center">
-<a name="figure3"></a>
-<table width="600" cellspacing="0" cellpadding="1" border="0" summary="">
- <caption align="bottom">Figure 3: SSL Record Protocol</caption>
- <tr>
- <td bgcolor="#cccccc">
- <table width="598" cellpadding="5" cellspacing="0" border="0" summary="">
- <tr>
- <td valign="top" align="center" bgcolor="#ffffff">
- <img src="ssl_intro_fig3.gif" alt="" width="423" height="323" />
- </td>
- </tr>
- </table>
- </td>
- </tr>
-</table>
-</div>
-<h3><a name="ToC18">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 mod_ssl provides to you for the Apache webserver...</p>
-<h2><a name="ToC19">References</a></h2>
-<ul>
-<li><a name="AC96"></a>
-[AC96] Bruce Schneier, <em>Applied Cryptography</em>, 2nd Edition, Wiley,
- 1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for
- various other materials by Bruce Schneier.
-</li>
-<li><a name="X208"></a>
-[X208] ITU-T Recommendation X.208, <em>Specification of Abstract Syntax Notation
- One (ASN.1)</em>, 1988. See for instance <a
- href="ftp://ftp.neda.com/pub/itu/x.series/x208.ps">
- ftp://ftp.neda.com/pub/itu/x.series/x208.ps</a>.
-</li>
-<li><a name="X509"></a>
-[X509] ITU-T Recommendation X.509, <em>The Directory - Authentication
- Framework</em>, 1988. See for instance <a
- href="ftp://ftp.bull.com/pub/OSIdirectory/ITUnov96/X.509/97x509final.doc">
- ftp://ftp.bull.com/pub/OSIdirectory/ITUnov96/X.509/97x509final.doc</a>.
-</li>
-<li><a name="PKCS"></a>
-[PKCS] Kaliski, Burton S., Jr., <em>An Overview of the PKCS Standards</em>, An RSA
- Laboratories Technical Note, revised November 1, 1993.
- See <a href="http://www.rsa.com/rsalabs/pubs/PKCS/">
- http://www.rsa.com/rsalabs/pubs/PKCS/</a>.
-</li>
-<li><a name="MIME"></a>
-[MIME] N. Freed, N. Borenstein, <em>Multipurpose Internet Mail Extensions
- (MIME) Part One: Format of Internet Message Bodies</em>, RFC2045.
- See for instance <a href="ftp://ftp.isi.edu/in-notes/rfc2045.txt">
- ftp://ftp.isi.edu/in-notes/rfc2045.txt</a>.
-</li>
-<li><a name="SSL2"></a>
-[SSL2] Kipp E.B. Hickman, <em>The SSL Protocol</em>, 1995.
- See <a href="http://www.netscape.com/eng/security/SSL_2.html">
- http://www.netscape.com/eng/security/SSL_2.html</a>.
-</li>
-<li><a name="SSL3"></a>
-[SSL3] Alan O. Freier, Philip Karlton, Paul C. Kocher, <em>The SSL Protocol
- Version 3.0</em>, 1996. See <a
- href="http://www.netscape.com/eng/ssl3/draft302.txt">
- http://www.netscape.com/eng/ssl3/draft302.txt</a>.
-</li>
-<li><a name="TLS1"></a>
-[TLS1] Tim Dierks, Christopher Allen, <em>The TLS Protocol Version 1.0</em>,
- 1997. See <a
- href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-protocol-06.txt">
- ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-protocol-06.txt</a>.
-</li>
-</ul>
- <!--#include virtual="footer.html" -->
- </body>
-</html>
--- /dev/null
+<?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="<-" alt="<-" src="../images/left.gif" /></a></div><div id="path"><a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <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&lang=e&parent=T-REC-X.208-198811-I">http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I</a>.
+</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&lang=e&parent=T-REC-X.509">http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&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>
\ No newline at end of file
--- /dev/null
+<?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&lang=e&parent=T-REC-X.208-198811-I"
+>http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I</a>.
+</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&lang=e&parent=T-REC-X.509"
+>http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&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>
projects / apache / commitdiff