From cc40af334e619bb549038238507407866f774f8f Mon Sep 17 00:00:00 2001 From: hongbotian Date: Mon, 30 Nov 2015 01:35:09 -0500 Subject: upload apache JIRA: BOTTLENECK-10 Change-Id: I67eae31de6dc824097dfa56ab454ba36fdd23a2c Signed-off-by: hongbotian --- rubbos/app/apache2/manual/ssl/index.html | 13 + rubbos/app/apache2/manual/ssl/index.html.en | 59 ++ rubbos/app/apache2/manual/ssl/index.html.ja.utf8 | 61 ++ rubbos/app/apache2/manual/ssl/index.html.tr.utf8 | 59 ++ rubbos/app/apache2/manual/ssl/ssl_compat.html | 5 + rubbos/app/apache2/manual/ssl/ssl_compat.html.en | 233 +++++ rubbos/app/apache2/manual/ssl/ssl_faq.html | 5 + rubbos/app/apache2/manual/ssl/ssl_faq.html.en | 1043 ++++++++++++++++++++ rubbos/app/apache2/manual/ssl/ssl_howto.html | 5 + rubbos/app/apache2/manual/ssl/ssl_howto.html.en | 284 ++++++ rubbos/app/apache2/manual/ssl/ssl_intro.html | 9 + rubbos/app/apache2/manual/ssl/ssl_intro.html.en | 641 ++++++++++++ .../app/apache2/manual/ssl/ssl_intro.html.ja.utf8 | 695 +++++++++++++ 13 files changed, 3112 insertions(+) create mode 100644 rubbos/app/apache2/manual/ssl/index.html create mode 100644 rubbos/app/apache2/manual/ssl/index.html.en create mode 100644 rubbos/app/apache2/manual/ssl/index.html.ja.utf8 create mode 100644 rubbos/app/apache2/manual/ssl/index.html.tr.utf8 create mode 100644 rubbos/app/apache2/manual/ssl/ssl_compat.html create mode 100644 rubbos/app/apache2/manual/ssl/ssl_compat.html.en create mode 100644 rubbos/app/apache2/manual/ssl/ssl_faq.html create mode 100644 rubbos/app/apache2/manual/ssl/ssl_faq.html.en create mode 100644 rubbos/app/apache2/manual/ssl/ssl_howto.html create mode 100644 rubbos/app/apache2/manual/ssl/ssl_howto.html.en create mode 100644 rubbos/app/apache2/manual/ssl/ssl_intro.html create mode 100644 rubbos/app/apache2/manual/ssl/ssl_intro.html.en create mode 100644 rubbos/app/apache2/manual/ssl/ssl_intro.html.ja.utf8 (limited to 'rubbos/app/apache2/manual/ssl') diff --git a/rubbos/app/apache2/manual/ssl/index.html b/rubbos/app/apache2/manual/ssl/index.html new file mode 100644 index 00000000..d6ccf929 --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/index.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: index.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +URI: index.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: index.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/rubbos/app/apache2/manual/ssl/index.html.en b/rubbos/app/apache2/manual/ssl/index.html.en new file mode 100644 index 00000000..1577c57d --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/index.html.en @@ -0,0 +1,59 @@ + + + +Apache SSL/TLS Encryption - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

Apache SSL/TLS Encryption

+
+

Available Languages:  en  | + ja  | + tr 

+
+ +

The Apache HTTP Server module mod_ssl +provides an interface to the OpenSSL library, which provides +Strong Encryption using the Secure Sockets Layer and Transport Layer +Security protocols. The module and this documentation are based on +Ralf S. Engelschall's mod_ssl project.

+
+ +
top
+
+

Documentation

+ +
top
+
+

mod_ssl

+

Extensive documentation on the directives and environment variables +provided by this module is provided in the mod_ssl reference documentation. +

+
+
+

Available Languages:  en  | + ja  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/ssl/index.html.ja.utf8 b/rubbos/app/apache2/manual/ssl/index.html.ja.utf8 new file mode 100644 index 00000000..f8d893b8 --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/index.html.ja.utf8 @@ -0,0 +1,61 @@ + + + +Apache の SSL/TLS 暗号化 - Apache HTTP サヌバ + + + + +
+

モゞュヌル | ディレクティブ | FAQ | 甚語 | サむトマップ

+

Apache HTTP サヌバ バヌゞョン 2.0

+
+
<-
+

Apache の SSL/TLS 暗号化

+
+

Available Languages:  en  | + ja  | + tr 

+
+ +

Apache HTTP サヌバモゞュヌル mod_ssl が +OpenSSL +ラむブラリぞのむンタヌフェヌスを提䟛しおいたすが、これは +Secure Sockts Layer ず Transport Layer Security +プロトコルを甚いた匷力な暗号化を提䟛したす。 +このモゞュヌルやこの文曞は Ralf S. Engelschall の mod_ssl +プロゞェクトに基づいおいたす。

+
+ +
top
+
+

Documentation

+ +
top
+
+

mod_ssl

+

このモゞュヌルで提䟛されるディレクティブや環境倉数に関する +詳しい文曞は、mod_ssl +リファレンスをご芧䞋さい。

+
+
+

Available Languages:  en  | + ja  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/ssl/index.html.tr.utf8 b/rubbos/app/apache2/manual/ssl/index.html.tr.utf8 new file mode 100644 index 00000000..1f673957 --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/index.html.tr.utf8 @@ -0,0 +1,59 @@ + + + +Apache SSL/TLS Şifrelemesi - Apache HTTP Sunucusu + + + + +
+

ModÌller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu SÃŒrÃŒm 2.0

+
+
<-
+

Apache SSL/TLS Şifrelemesi

+
+

Mevcut Diller:  en  | + ja  | + tr 

+
+ +

Apache HTTP Sunucusunun mod_ssl modÃŒlÃŒ, GÃŒvenli Soketler + Katmanı (SSL) ve Aktarım Katmanı GÃŒvenliği (TLS) protokollerinin + kullanıldığı Sağlam Şifreleme desteğini sağlayan OpenSSL kÃŒtÃŒphanesine bir arayÃŒz + içerir. Bu modÃŒl ve belgeler Ralf S. Engelschall’ın mod_ssl projesine + dayanmaktadır.

+
+ +
top
+
+

Belgeler

+ +
top
+
+

mod_ssl ModÌlÌ

+

Bu modÃŒlce sağlanan yönergeler ve ortam değişkenleri + mod_ssl başvuru kılavuzunda ayrıntılı olarak + açıklanmıştır.

+
+
+

Mevcut Diller:  en  | + ja  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/ssl/ssl_compat.html b/rubbos/app/apache2/manual/ssl/ssl_compat.html new file mode 100644 index 00000000..eb43a0be --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_compat.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssl_compat.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/rubbos/app/apache2/manual/ssl/ssl_compat.html.en b/rubbos/app/apache2/manual/ssl/ssl_compat.html.en new file mode 100644 index 00000000..9a0dbfcf --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_compat.html.en @@ -0,0 +1,233 @@ + + + +SSL/TLS Strong Encryption: Compatibility - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

SSL/TLS Strong Encryption: Compatibility

+
+

Available Languages:  en 

+
+ +
+

All PCs are compatible. But some of +them are more compatible than others.

+

-- Unknown

+
+ +

+Here we talk about backward compatibility to other SSL solutions. As you +perhaps know, mod_ssl is not the only existing SSL solution for Apache. +Actually there are four additional major products available on the market: Ben +Laurie's freely available Apache-SSL +(from where mod_ssl were originally derived in 1998), Red Hat's commercial Secure Web +Server (which is based on mod_ssl), Covalent's commercial Raven SSL Module (also based on mod_ssl) +and finally C2Net's commercial product Stronghold (based on a +different evolution branch named Sioux up to Stronghold 2.x and based on +mod_ssl since Stronghold 3.x).

+ +

+The idea in mod_ssl is mainly the following: because mod_ssl provides mostly a +superset of the functionality of all other solutions we can easily provide +backward compatibility for most of the cases. Actually there are three +compatibility areas we currently address: configuration directives, +environment variables and custom log functions.

+
+ +
top
+
+

Configuration Directives

+

For backward compatibility to the configuration directives of other SSL +solutions we do an on-the-fly mapping: directives which have a direct +counterpart in mod_ssl are mapped silently while other directives lead to a +warning message in the logfiles. The currently implemented directive mapping +is listed in Table 1. Currently full backward +compatibility is provided only for Apache-SSL 1.x and mod_ssl 2.0.x. +Compatibility to Sioux 1.x and Stronghold 2.x is only partial because of +special functionality in these interfaces which mod_ssl (still) doesn't +provide.

+ + +

Table 1: Configuration Directive Mapping

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Old Directivemod_ssl DirectiveComment
Apache-SSL 1.x & mod_ssl 2.0.x compatibility:
SSLEnableSSLEngine oncompactified
SSLDisableSSLEngine offcompactified
SSLLogFile fileSSLLog filecompactified
SSLRequiredCiphers specSSLCipherSuite specrenamed
SSLRequireCipher c1 ...SSLRequire %{SSL_CIPHER} in {"c1", +...}generalized
SSLBanCipher c1 ...SSLRequire not (%{SSL_CIPHER} in {"c1", +...})generalized
SSLFakeBasicAuthSSLOptions +FakeBasicAuthmerged
SSLCacheServerPath dir-functionality removed
SSLCacheServerPort integer-functionality removed
Apache-SSL 1.x compatibility:
SSLExportClientCertificatesSSLOptions +ExportCertDatamerged
SSLCacheServerRunDir dir-functionality not supported
Sioux 1.x compatibility:
SSL_CertFile fileSSLCertificateFile filerenamed
SSL_KeyFile fileSSLCertificateKeyFile filerenamed
SSL_CipherSuite argSSLCipherSuite argrenamed
SSL_X509VerifyDir argSSLCACertificatePath argrenamed
SSL_Log fileSSLLogFile filerenamed
SSL_Connect flagSSLEngine flagrenamed
SSL_ClientAuth argSSLVerifyClient argrenamed
SSL_X509VerifyDepth argSSLVerifyDepth argrenamed
SSL_FetchKeyPhraseFrom arg-not directly mappable; use SSLPassPhraseDialog
SSL_SessionDir dir-not directly mappable; use SSLSessionCache
SSL_Require expr-not directly mappable; use SSLRequire
SSL_CertFileType arg-functionality not supported
SSL_KeyFileType arg-functionality not supported
SSL_X509VerifyPolicy arg-functionality not supported
SSL_LogX509Attributes arg-functionality not supported
Stronghold 2.x compatibility:
StrongholdAccelerator dir-functionality not supported
StrongholdKey dir-functionality not supported
StrongholdLicenseFile dir-functionality not supported
SSLFlag flagSSLEngine flagrenamed
SSLSessionLockFile fileSSLMutex filerenamed
SSLCipherList specSSLCipherSuite specrenamed
RequireSSLSSLRequireSSLrenamed
SSLErrorFile file-functionality not supported
SSLRoot dir-functionality not supported
SSL_CertificateLogDir dir-functionality not supported
AuthCertDir dir-functionality not supported
SSL_Group name-functionality not supported
SSLProxyMachineCertPath dir-functionality not supported
SSLProxyMachineCertFile file-functionality not supported
SSLProxyCACertificatePath dir-functionality not supported
SSLProxyCACertificateFile file-functionality not supported
SSLProxyVerifyDepth number-functionality not supported
SSLProxyCipherList spec-functionality not supported
+ +
top
+
+

Environment Variables

+

When you use ``SSLOptions +CompatEnvVars'' additional environment +variables are generated. They all correspond to existing official mod_ssl +variables. The currently implemented variable derivation is listed in Table 2.

+ +

Table 2: Environment Variable Derivation

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Old Variablemod_ssl VariableComment
SSL_PROTOCOL_VERSIONSSL_PROTOCOLrenamed
SSLEAY_VERSIONSSL_VERSION_LIBRARYrenamed
HTTPS_SECRETKEYSIZESSL_CIPHER_USEKEYSIZErenamed
HTTPS_KEYSIZESSL_CIPHER_ALGKEYSIZErenamed
HTTPS_CIPHERSSL_CIPHERrenamed
HTTPS_EXPORTSSL_CIPHER_EXPORTrenamed
SSL_SERVER_KEY_SIZESSL_CIPHER_ALGKEYSIZErenamed
SSL_SERVER_CERTIFICATESSL_SERVER_CERTrenamed
SSL_SERVER_CERT_STARTSSL_SERVER_V_STARTrenamed
SSL_SERVER_CERT_ENDSSL_SERVER_V_ENDrenamed
SSL_SERVER_CERT_SERIALSSL_SERVER_M_SERIALrenamed
SSL_SERVER_SIGNATURE_ALGORITHMSSL_SERVER_A_SIGrenamed
SSL_SERVER_DNSSL_SERVER_S_DNrenamed
SSL_SERVER_CNSSL_SERVER_S_DN_CNrenamed
SSL_SERVER_EMAILSSL_SERVER_S_DN_Emailrenamed
SSL_SERVER_OSSL_SERVER_S_DN_Orenamed
SSL_SERVER_OUSSL_SERVER_S_DN_OUrenamed
SSL_SERVER_CSSL_SERVER_S_DN_Crenamed
SSL_SERVER_SPSSL_SERVER_S_DN_SPrenamed
SSL_SERVER_LSSL_SERVER_S_DN_Lrenamed
SSL_SERVER_IDNSSL_SERVER_I_DNrenamed
SSL_SERVER_ICNSSL_SERVER_I_DN_CNrenamed
SSL_SERVER_IEMAILSSL_SERVER_I_DN_Emailrenamed
SSL_SERVER_IOSSL_SERVER_I_DN_Orenamed
SSL_SERVER_IOUSSL_SERVER_I_DN_OUrenamed
SSL_SERVER_ICSSL_SERVER_I_DN_Crenamed
SSL_SERVER_ISPSSL_SERVER_I_DN_SPrenamed
SSL_SERVER_ILSSL_SERVER_I_DN_Lrenamed
SSL_CLIENT_CERTIFICATESSL_CLIENT_CERTrenamed
SSL_CLIENT_CERT_STARTSSL_CLIENT_V_STARTrenamed
SSL_CLIENT_CERT_ENDSSL_CLIENT_V_ENDrenamed
SSL_CLIENT_CERT_SERIALSSL_CLIENT_M_SERIALrenamed
SSL_CLIENT_SIGNATURE_ALGORITHMSSL_CLIENT_A_SIGrenamed
SSL_CLIENT_DNSSL_CLIENT_S_DNrenamed
SSL_CLIENT_CNSSL_CLIENT_S_DN_CNrenamed
SSL_CLIENT_EMAILSSL_CLIENT_S_DN_Emailrenamed
SSL_CLIENT_OSSL_CLIENT_S_DN_Orenamed
SSL_CLIENT_OUSSL_CLIENT_S_DN_OUrenamed
SSL_CLIENT_CSSL_CLIENT_S_DN_Crenamed
SSL_CLIENT_SPSSL_CLIENT_S_DN_SPrenamed
SSL_CLIENT_LSSL_CLIENT_S_DN_Lrenamed
SSL_CLIENT_IDNSSL_CLIENT_I_DNrenamed
SSL_CLIENT_ICNSSL_CLIENT_I_DN_CNrenamed
SSL_CLIENT_IEMAILSSL_CLIENT_I_DN_Emailrenamed
SSL_CLIENT_IOSSL_CLIENT_I_DN_Orenamed
SSL_CLIENT_IOUSSL_CLIENT_I_DN_OUrenamed
SSL_CLIENT_ICSSL_CLIENT_I_DN_Crenamed
SSL_CLIENT_ISPSSL_CLIENT_I_DN_SPrenamed
SSL_CLIENT_ILSSL_CLIENT_I_DN_Lrenamed
SSL_EXPORTSSL_CIPHER_EXPORTrenamed
SSL_KEYSIZESSL_CIPHER_ALGKEYSIZErenamed
SSL_SECKEYSIZESSL_CIPHER_USEKEYSIZErenamed
SSL_SSLEAY_VERSIONSSL_VERSION_LIBRARYrenamed
SSL_STRONG_CRYPTO-Not supported by mod_ssl
SSL_SERVER_KEY_EXP-Not supported by mod_ssl
SSL_SERVER_KEY_ALGORITHM-Not supported by mod_ssl
SSL_SERVER_KEY_SIZE-Not supported by mod_ssl
SSL_SERVER_SESSIONDIR-Not supported by mod_ssl
SSL_SERVER_CERTIFICATELOGDIR-Not supported by mod_ssl
SSL_SERVER_CERTFILE-Not supported by mod_ssl
SSL_SERVER_KEYFILE-Not supported by mod_ssl
SSL_SERVER_KEYFILETYPE-Not supported by mod_ssl
SSL_CLIENT_KEY_EXP-Not supported by mod_ssl
SSL_CLIENT_KEY_ALGORITHM-Not supported by mod_ssl
SSL_CLIENT_KEY_SIZE-Not supported by mod_ssl
+ +
top
+
+

Custom Log Functions

+

+When mod_ssl is built into Apache or at least loaded (under DSO situation) +additional functions exist for the Custom Log Format of +mod_log_config as documented in the Reference +Chapter. Beside the ``%{varname}x'' +eXtension format function which can be used to expand any variables provided +by any module, an additional Cryptography +``%{name}c'' cryptography format function +exists for backward compatibility. The currently implemented function calls +are listed in Table 3.

+ +

Table 3: Custom Log Cryptography Function

+ + + + + + + + + + + + +
Function CallDescription
%...{version}c SSL protocol version
%...{cipher}c SSL cipher
%...{subjectdn}c Client Certificate Subject Distinguished Name
%...{issuerdn}c Client Certificate Issuer Distinguished Name
%...{errcode}c Certificate Verification Error (numerical)
%...{errstr}c Certificate Verification Error (string)
+ +
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/ssl/ssl_faq.html b/rubbos/app/apache2/manual/ssl/ssl_faq.html new file mode 100644 index 00000000..ce1cf81d --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_faq.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssl_faq.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/rubbos/app/apache2/manual/ssl/ssl_faq.html.en b/rubbos/app/apache2/manual/ssl/ssl_faq.html.en new file mode 100644 index 00000000..16801dd6 --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_faq.html.en @@ -0,0 +1,1043 @@ + + + +SSL/TLS Strong Encryption: FAQ - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

SSL/TLS Strong Encryption: FAQ

+
+

Available Languages:  en 

+
+ +
+

The wise man doesn't give the right answers, +he poses the right questions.

+

-- Claude Levi-Strauss

+ +
+

This chapter is a collection of frequently asked questions (FAQ) and +corresponding answers following the popular USENET tradition. Most of these +questions occurred on the Newsgroup comp.infosystems.www.servers.unix or the mod_ssl Support +Mailing List modssl-users@modssl.org. They are collected at this place +to avoid answering the same questions over and over.

+ +

Please read this chapter at least once when installing mod_ssl or at least +search for your problem here before submitting a problem report to the +author.

+
+ +
top
+
+

About The Module

+ + +

What is the history of mod_ssl?

+

The mod_ssl v1 package was initially created in April 1998 by Ralf S. Engelschall via porting Ben Laurie's Apache-SSL 1.17 source patches for + Apache 1.2.6 to Apache 1.3b6. Because of conflicts with Ben + Laurie's development cycle it then was re-assembled from scratch for + Apache 1.3.0 by merging the old mod_ssl 1.x with the newer Apache-SSL + 1.18. From this point on mod_ssl lived its own life as mod_ssl v2. The + first publicly released version was mod_ssl 2.0.0 from August 10th, + 1998.

+ +

After US export restrictions on cryptographic software were + loosened, mod_ssl became part of the Apache HTTP + Server with the release of Apache httpd 2.

+ + +

Is mod_ssl affected by the Wassenaar Arrangement?

+

First, let us explain what Wassenaar and its Arrangement on + Export Controls for Conventional Arms and Dual-Use Goods and + Technologies is: This is a international regime, established in 1995, to + control trade in conventional arms and dual-use goods and technology. It + replaced the previous CoCom regime. Further details on + both the Arrangement and its signatories are available at http://www.wassenaar.org/.

+ +

In short, the aim of the Wassenaar Arrangement is to prevent the build up + of military capabilities that threaten regional and international security + and stability. The Wassenaar Arrangement controls the export of + cryptography as a dual-use good, that is, something that has both military and + civilian applications. However, the Wassenaar Arrangement also provides an + exemption from export controls for mass-market software and free software.

+ +

In the current Wassenaar List of Dual Use Goods and Technologies And + Munitions, under GENERAL SOFTWARE NOTE (GSN) it says + The Lists do not control "software" which is either: 1. [...] 2. "in + the public domain". And under DEFINITIONS OF TERMS USED IN + THESE LISTS we find In the public + domain defined as "technology" or "software" which has been made + available without restrictions upon its further dissemination. Note: + Copyright restrictions do not remove "technology" or "software" from being + "in the public domain".

+ +

So, both mod_ssl and OpenSSL are in the public domain for the purposes + of the Wassenaar Arrangement and its List of Dual Use Goods and + Technologies And Munitions List, and thus not affected by its provisions.

+ + +
top
+
+

Installation

+ + +

Why do I get permission errors related to + SSLMutex when I start Apache?

+

Errors such as ``mod_ssl: Child could not open + SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) + [...] System: Permission denied (errno: 13)'' are usually + caused by overly restrictive permissions on the parent directories. + Make sure that all parent directories (here /opt, + /opt/apache and /opt/apache/logs) have the x-bit + set for, at minimum, the UID under which Apache's children are running (see + the User directive).

+ + +

Why does mod_ssl stop with the error + "Failed to generate temporary 512 bit RSA private key" when I start + Apache?

+

Cryptographic software needs a source of unpredictable data + to work correctly. Many open source operating systems provide + a "randomness device" that serves this purpose (usually named + /dev/random). On other systems, applications have to + seed the OpenSSL Pseudo Random Number Generator (PRNG) manually with + appropriate data before generating keys or performing public key + encryption. As of version 0.9.5, the OpenSSL functions that need + randomness report an error if the PRNG has not been seeded with + at least 128 bits of randomness.

+

To prevent this error, mod_ssl has to provide + enough entropy to the PRNG to allow it to work correctly. This can + be done via the SSLRandomSeed + directive.

+ +
top
+
+

Configuration

+ + +

Is it possible to provide HTTP and HTTPS + from the same server?

+

Yes. HTTP and HTTPS use different server ports (HTTP binds to + port 80, HTTPS to port 443), so there is no direct conflict between + them. You can either run two separate server instances bound to + these ports, or use Apache's elegant virtual hosting facility to + create two virtual servers, both served by the same instance of Apache + - one responding over HTTP to requests on port 80, and the other + responding over HTTPS to requests on port 443.

+ + +

Which port does HTTPS use?

+

You can run HTTPS on any port, but the standards specify port 443, which + is where any HTTPS compliant browser will look by default. You can force + your browser to look on a different port by specifying it in the URL. For + example, if your server is set up to serve pages over HTTPS on port 8080, + you can access them at https://example.com:8080/

+ + +

How do I speak HTTPS manually for testing purposes?

+

While you usually just use

+ +

$ telnet localhost 80
+ GET / HTTP/1.0

+ +

for simple testing of Apache via HTTP, it's not so easy for + HTTPS because of the SSL protocol between TCP and HTTP. With the + help of OpenSSL's s_client command, however, you can + do a similar check via HTTPS:

+ +

$ openssl s_client -connect localhost:443 -state -debug
+ GET / HTTP/1.0

+ +

Before the actual HTTP response you will receive detailed + information about the SSL handshake. For a more general command + line client which directly understands both HTTP and HTTPS, can + perform GET and POST operations, can use a proxy, supports byte + ranges, etc. you should have a look at the nifty + cURL tool. Using this, you can + check that Apache is responding correctly to requests via HTTP and + HTTPS as follows:

+ +

$ curl http://localhost/
+ $ curl https://localhost/

+ + +

Why does the connection hang when I connect + to my SSL-aware Apache server?

+ +

This can happen when you try to connect to a HTTPS server (or virtual + server) via HTTP (eg, using http://example.com/ instead of + https://example.com). It can also happen when trying to + connect via HTTPS to a HTTP server (eg, using + https://example.com/ on a server which doesn't support HTTPS, + or which supports it on a non-standard port). Make sure that you're + connecting to a (virtual) server that supports SSL.

+ +

Why do I get ``Connection Refused'' messages, + when trying to access my newly installed Apache+mod_ssl server via HTTPS?

+

+ This error can be caused by an incorrect configuration. + Please make sure that your Listen directives match your + <VirtualHost> + directives. If all else fails, please start afresh, using the default + configuration provided by mod_ssl.

+ + +

Why are the SSL_XXX variables + not available to my CGI & SSI scripts?

+

Please make sure you have ``SSLOptions +StdEnvVars'' + enabled for the context of your CGI/SSI requests.

+ + +

How can I switch between HTTP and HTTPS in relative + hyperlinks?

+ +

Usually, to switch between HTTP and HTTPS, you have to use + fully-qualified hyperlinks (because you have to change the URL + scheme). Using mod_rewrite however, you can + manipulate relative hyperlinks, to achieve the same effect.

+

+ RewriteEngine on
+ RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]
+ RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L] +

+ +

This rewrite ruleset lets you use hyperlinks of the form + <a href="document.html:SSL">, to switch to HTTPS + in a relative link. (Replace SSL with NOSSL to switch to HTTP.)

+ +
top
+
+

Certificates

+ + +

What are RSA Private Keys, CSRs and Certificates?

+

An RSA private key file is a digital file that you can use to decrypt + messages sent to you. It has a public component which you distribute (via + your Certificate file) which allows people to encrypt those messages to + you.

+

A Certificate Signing Request (CSR) is a digital file which contains + your public key and your name. You send the CSR to a Certifying Authority + (CA), who will convert it into a real Certificate, by signing it.

+

A Certificate contains your + RSA public key, your name, the name of the CA, and is digitally signed by + the CA. Browsers that know the CA can verify the signature on that + Certificate, thereby obtaining your RSA public key. That enables them to + send messages which only you can decrypt.

+

See the Introduction chapter for a general + description of the SSL protocol.

+ + +

Is there a difference on startup between + a non-SSL-aware Apache and an SSL-aware Apache?

+

Yes. In general, starting Apache with + mod_ssl built-in is just like starting Apache + without it. However, if you have a passphrase on your SSL private + key file, a startup dialog will pop up which asks you to enter the + pass phrase.

+ +

Having to manually enter the passphrase when starting the server + can be problematic - for example, when starting the server from the + system boot scripts. In this case, you can follow the steps + below to remove the passphrase from + your private key. Bear in mind that doing so brings additional security + risks - proceed with caution!

+ + +

How do I create a self-signed SSL +Certificate for testing purposes?

+
    +
  1. Make sure OpenSSL is installed and in your PATH.
    +
    +
    2. +
  2. Run the following command, to create server.key and + server.crt files:
    + $ openssl req -new -x509 -nodes -out server.crt + -keyout server.key
    + These can be used as follows in your httpd.conf + file: + 
    +             SSLCertificateFile    /path/to/this/server.crt
+             SSLCertificateKeyFile /path/to/this/server.key
+
    +
    3. +
  3. It is important that you are aware that this + server.key does not have any passphrase. + To add a passphrase to the key, you should run the following + command, and enter & verify the passphrase as requested.
    +

    $ openssl rsa -des3 -in server.key -out + server.key.new
    + $ mv server.key.new server.key

    + Please backup the server.key file, and the passphrase + you entered, in a secure location. +
    4. +
+ + +

How do I create a real SSL Certificate?

+

Here is a step-by-step description:

+
    +
  1. Make sure OpenSSL is installed and in your PATH. +
    +
    +
    2. +
  2. Create a RSA private key for your Apache server + (will be Triple-DES encrypted and PEM formatted):
    +
    + $ openssl genrsa -des3 -out server.key 1024
    +
    + Please backup this server.key file and the + pass-phrase you entered in a secure location. + You can see the details of this RSA private key by using the command:
    + +
    + $ openssl rsa -noout -text -in server.key
    +
    + If necessary, you can also create a decrypted PEM version (not + recommended) of this RSA private key with:
    +
    + $ openssl rsa -in server.key -out server.key.unsecure
    +
    + +
    3. +
  3. Create a Certificate Signing Request (CSR) with the server RSA private + key (output will be PEM formatted):
    +
    + $ openssl req -new -key server.key -out server.csr
    +
    + Make sure you enter the FQDN ("Fully Qualified Domain Name") of the + server when OpenSSL prompts you for the "CommonName", i.e. when you + generate a CSR for a website which will be later accessed via + https://www.foo.dom/, enter "www.foo.dom" here. + You can see the details of this CSR by using
    + +
    + $ openssl req -noout -text -in server.csr
    +
    +
    4. +
  4. You now have to send this Certificate Signing Request (CSR) to + a Certifying Authority (CA) to be signed. Once the CSR has been + signed, you will have a real Certificate, which can be used by + Apache. You can have a CSR signed by a commercial CA, or you can + create your own CA to sign it.
    + Commercial CAs usually ask you to post the CSR into a web form, + pay for the signing, and then send a signed Certificate, which + you can store in a server.crt file. For more information about + commercial CAs see the following locations:
    +
    +
      +
    1. Verisign
      + + http://digitalid.verisign.com/server/apacheNotice.htm + +
      2. +
    2. Thawte
      + http://www.thawte.com/ +
      3. +
    3. CertiSign Certificadora Digital Ltda.
      + + http://www.certisign.com.br + +
      4. +
    4. IKS GmbH
      + + http://www.iks-jena.de/leistungen/ca/ + +
      5. +
    5. Uptime Commerce Ltd.
      + + http://www.uptimecommerce.com + +
      6. +
    6. BelSign NV/SA
      + + http://www.belsign.be + +
      7. +
    + + For details on how to create your own CA, and use this to sign + a CSR, see below.
    + + Once your CSR has been signed, you can see the details of the + Certificate as follows:
    +
    + $ openssl x509 -noout -text -in server.crt
    + +
    5. +
  5. You should now have two files: server.key and + server.crt. These can be used as follows in your + httpd.conf file: + 
    +       SSLCertificateFile    /path/to/this/server.crt
+       SSLCertificateKeyFile /path/to/this/server.key
+
    + The server.csr file is no longer needed. +
    6. + +
+ + +

How do I create and use my own Certificate Authority (CA)?

+

The short answer is to use the CA.sh or CA.pl + script provided by OpenSSL. Unless you have a good reason not to, + you should use these for preference. If you cannot, you can create a + self-signed Certificate as follows:

+ +
    +
  1. Create a RSA private key for your server + (will be Triple-DES encrypted and PEM formatted):
    +
    + $ openssl genrsa -des3 -out server.key 1024
    +
    + Please backup this host.key file and the + pass-phrase you entered in a secure location. + You can see the details of this RSA private key by using the + command:
    + $ openssl rsa -noout -text -in server.key
    +
    + If necessary, you can also create a decrypted PEM version (not + recommended) of this RSA private key with:
    +
    + $ openssl rsa -in server.key -out server.key.unsecure
    +
    +
    2. +
  2. Create a self-signed Certificate (X509 structure) + with the RSA key you just created (output will be PEM formatted):
    +
    + $ openssl req -new -x509 -nodes -sha1 -days 365 + -key server.key -out server.crt
    +
    + This signs the server CSR and results in a server.crt file.
    + You can see the details of this Certificate using:
    +
    + $ openssl x509 -noout -text -in server.crt
    +
    +
    3. +
+ + +

How can I change the pass-phrase on my private key file?

+

You simply have to read it with the old pass-phrase and write it again, + specifying the new pass-phrase. You can accomplish this with the following + commands:

+ + +

$ openssl rsa -des3 -in server.key -out server.key.new
+ $ mv server.key.new server.key

+ +

The first time you're asked for a PEM pass-phrase, you should + enter the old pass-phrase. After that, you'll be asked again to + enter a pass-phrase - this time, use the new pass-phrase. If you + are asked to verify the pass-phrase, you'll need to enter the new + pass-phrase a second time.

+ + +

How can I get rid of the pass-phrase dialog at Apache startup time?

+

The reason this dialog pops up at startup and every re-start + is that the RSA private key inside your server.key file is stored in + encrypted format for security reasons. The pass-phrase is needed to decrypt + this file, so it can be read and parsed. Removing the pass-phrase + removes a layer of security from your server - proceed with caution!

+
    +
  1. Remove the encryption from the RSA private key (while + keeping a backup copy of the original file):
    +
    + $ cp server.key server.key.org
    + $ openssl rsa -in server.key.org -out server.key
    + +
    +
    2. +
  2. Make sure the server.key file is only readable by root:
    +
    + $ chmod 400 server.key
    +
    +
    3. +
+ +

Now server.key contains an unencrypted copy of the key. + If you point your server at this file, it will not prompt you for a + pass-phrase. HOWEVER, if anyone gets this key they will be able to + impersonate you on the net. PLEASE make sure that the permissions on this + file are such that only root or the web server user can read it + (preferably get your web server to start as root but run as another + user, and have the key readable only by root).

+ +

As an alternative approach you can use the ``SSLPassPhraseDialog + exec:/path/to/program'' facility. Bear in mind that this is + neither more nor less secure, of course.

+ + +

How do I verify that a private key matches its Certificate?

+

A private key contains a series of numbers. Two of these numbers form + the "public key", the others are part of the "private key". The "public + key" bits are included when you generate a CSR, and subsequently form + part of the associated Certificate.

+

To check that the public key in your Certificate matches the public + portion of your private key, you simply need to compare these numbers. + To view the Certificate and the key run the commands:

+ +

$ openssl x509 -noout -text -in server.crt
+ $ openssl rsa -noout -text -in server.key

+ +

The `modulus' and the `public exponent' portions in the key and the + Certificate must match. As the public exponent is usually 65537 + and it's difficult to visually check that the long modulus numbers + are the same, you can use the following approach:

+ +

$ openssl x509 -noout -modulus -in server.crt | openssl md5
+ $ openssl rsa -noout -modulus -in server.key | openssl md5

+ +

This leaves you with two rather shorter numbers to compare. It is, + in theory, possible that these numbers may be the same, without the + modulus numbers being the same, but the chances of this are + overwhelmingly remote.

+

Should you wish to check to which key or certificate a particular + CSR belongs you can perform the same calculation on the CSR as + follows:

+ +

$ openssl req -noout -modulus -in server.csr | openssl md5

+ + +

Why do connections fail with an "alert +bad certificate" error?

+

Errors such as OpenSSL: error:14094412: SSL + routines:SSL3_READ_BYTES:sslv3 alert bad certificate in the SSL + logfile, are usually caused by a browser which is unable to handle the server + certificate/private-key. For example, Netscape Navigator 3.x is + unable to handle RSA key lengths not equal to 1024 bits.

+ + +

Why does my 2048-bit private key not work?

+

The private key sizes for SSL must be either 512 or 1024 bits, for compatibility + with certain web browsers. A keysize of 1024 bits is recommended because + keys larger than 1024 bits are incompatible with some versions of Netscape + Navigator and Microsoft Internet Explorer, and with other browsers that + use RSA's BSAFE cryptography toolkit.

+ + +

Why is client authentication broken after upgrading from +SSLeay version 0.8 to 0.9?

+

The CA certificates under the path you configured with + SSLCACertificatePath are found by SSLeay through hash + symlinks. These hash values are generated by the `openssl x509 -noout + -hash' command. However, the algorithm used to calculate the hash for a + certificate changed between SSLeay 0.8 and 0.9. You will need to remove + all old hash symlinks and create new ones after upgrading. Use the + Makefile provided by mod_ssl.

+ + +

How can I convert a certificate from PEM to DER format?

+

The default certificate format for SSLeay/OpenSSL is PEM, which is simply + Base64 encoded DER, with header and footer lines. For some applications + (e.g. Microsoft Internet Explorer) you need the certificate in plain DER + format. You can convert a PEM file cert.pem into the + corresponding DER file cert.der using the following command: + $ openssl x509 -in cert.pem -out cert.der -outform DER

+ + +

Why can't I find the +getca or getverisign programs mentioned by +Verisign, for installing my Verisign certificate?

+

Verisign has never provided specific instructions + for Apache+mod_ssl. The instructions provided are for C2Net's + Stronghold (a commercial Apache based server with SSL support).

+

To install your certificate, all you need to do is to save the + certificate to a file, and give the name of that file to the + SSLCertificateFile directive. + You will also need to give it the key file. For more information, + see the SSLCertificateKeyFile + directive.

+ + +

Can I use the Server Gated Cryptography (SGC) +facility (aka Verisign Global ID) with mod_ssl?

+

Yes. mod_ssl has included support for the SGC + facility since version 2.1. No special configuration is required - + just use the Global ID as your server certificate. The + step up of the clients is then automatically handled by + mod_ssl at run-time.

+ + +

Why do browsers complain that they cannot +verify my Verisign Global ID server certificate?

+

Verisign uses an intermediate CA certificate between the root CA + certificate (which is installed in the browsers) and the server + certificate (which you installed on the server). You should have + received this additional CA certificate from Verisign. + If not, complain to them. Then, configure this certificate with the + SSLCertificateChainFile + directive. This ensures that the intermediate CA certificate is + sent to the browser, filling the gap in the certificate chain.

+ +
top
+
+

The SSL Protocol

+ + +

Why do I get lots of random SSL protocol +errors under heavy server load?

+

There can be a number of reasons for this, but the main one + is problems with the SSL session Cache specified by the + SSLSessionCache directive. The DBM session + cache is the most likely source of the problem, so using the SHM session cache (or + no cache at all) may help.

+ + +

Why does my webserver have a higher load, now +that it serves SSL encrypted traffic?

+

SSL uses strong cryptographic encryption, which necessitates a lot of + number crunching. When you request a webpage via HTTPS, everything (even + the images) is encrypted before it is transferred. So increased HTTPS + traffic leads to load increases.

+ + +

Why do HTTPS connections to my server +sometimes take up to 30 seconds to establish a connection?

+

This is usually caused by a /dev/random device for + SSLRandomSeed which blocks the + read(2) call until enough entropy is available to service the + request. More information is available in the reference + manual for the SSLRandomSeed + directive.

+ + +

What SSL Ciphers are supported by mod_ssl?

+

Usually, any SSL ciphers supported by the version of OpenSSL in use, + are also supported by mod_ssl. Which ciphers are + available can depend on the way you built OpenSSL. Typically, at + least the following ciphers are supported:

+ +
    +
  1. RC4 with MD5
    2. +
  2. RC4 with MD5 (export version restricted to 40-bit key)
    3. +
  3. RC2 with MD5
    4. +
  4. RC2 with MD5 (export version restricted to 40-bit key)
    5. +
  5. IDEA with MD5
    6. +
  6. DES with MD5
    7. +
  7. Triple-DES with MD5
    8. +
+ +

To determine the actual list of ciphers available, you should run + the following:

+

$ openssl ciphers -v

+ + +

Why do I get ``no shared cipher'' errors, when +trying to use Anonymous Diffie-Hellman (ADH) ciphers?

+

By default, OpenSSL does not allow ADH ciphers, for security + reasons. Please be sure you are aware of the potential side-effects + if you choose to enable these ciphers.

+

In order to use Anonymous Diffie-Hellman (ADH) ciphers, you must + build OpenSSL with ``-DSSL_ALLOW_ADH'', and then add + ``ADH'' into your SSLCipherSuite.

+ + +

Why do I get a 'no shared ciphers' +error when connecting to my newly installed server?

+

Either you have made a mistake with your + SSLCipherSuite + directive (compare it with the pre-configured example in + httpd.conf-dist) or you chose to use DSA/DH + algorithms instead of RSA when you generated your private key + and ignored or overlooked the warnings. If you have chosen + DSA/DH, then your server cannot communicate using RSA-based SSL + ciphers (at least until you configure an additional RSA-based + certificate/key pair). Modern browsers like NS or IE can only + communicate over SSL using RSA ciphers. The result is the + "no shared ciphers" error. To fix this, regenerate your server + certificate/key pair, using the RSA algorithm.

+ + +

Why can't I use SSL with name-based/non-IP-based virtual hosts?

+

The reason is very technical, and a somewhat "chicken and egg" problem. + The SSL protocol layer stays below the HTTP protocol layer and + encapsulates HTTP. When an SSL connection (HTTPS) is established + Apache/mod_ssl has to negotiate the SSL protocol parameters with the + client. For this, mod_ssl has to consult the configuration of the virtual + server (for instance it has to look for the cipher suite, the server + certificate, etc.). But in order to go to the correct virtual server + Apache has to know the Host HTTP header field. To do this, the + HTTP request header has to be read. This cannot be done before the SSL + handshake is finished, but the information is needed in order to + complete the SSL handshake phase. Bingo!

+ + +

Why is it not possible to use Name-Based +Virtual Hosting to identify different SSL virtual hosts?

+

Name-Based Virtual Hosting is a very popular method of identifying + different virtual hosts. It allows you to use the same IP address and + the same port number for many different sites. When people move on to + SSL, it seems natural to assume that the same method can be used to have + lots of different SSL virtual hosts on the same server.

+ +

It comes as rather a shock to learn that it is impossible.

+ +

The reason is that the SSL protocol is a separate layer which + encapsulates the HTTP protocol. So the SSL session is a separate + transaction, that takes place before the HTTP session has begun. + The server receives an SSL request on IP address X and port Y + (usually 443). Since the SSL request does not contain any Host: + field, the server has no way to decide which SSL virtual host to use. + Usually, it will just use the first one it finds, which matches the + port and IP address specified.

+ +

You can, of course, use Name-Based Virtual Hosting to identify many + non-SSL virtual hosts (all on port 80, for example) and then + have a single SSL virtual host (on port 443). But if you do this, + you must make sure to put the non-SSL port number on the NameVirtualHost + directive, e.g.

+ +

+ NameVirtualHost 192.168.1.1:80 +

+ +

Other workaround solutions include:

+ +

Using separate IP addresses for different SSL hosts. + Using different port numbers for different SSL hosts.

+ + +

How do I get SSL compression working?

+

Although SSL compression negotiation was defined in the specification +of SSLv2 and TLS, it took until May 2004 for RFC 3749 to define DEFLATE as +a negotiable standard compression method. +

+

OpenSSL 0.9.8 started to support this by default when compiled with the +zlib option. If both the client and the server support compression, +it will be used. However, most clients still try to initially connect with an +SSLv2 Hello. As SSLv2 did not include an array of prefered compression algorithms +in its handshake, compression cannot be negotiated with these clients. +If the client disables support for SSLv2, either an SSLv3 or TLS Hello +may be sent, depending on which SSL library is used, and compression may +be set up. You can verify whether clients make use of SSL compression by +logging the %{SSL_COMPRESS_METHOD}x variable. +

+ + +

When I use Basic Authentication over HTTPS +the lock icon in Netscape browsers stays unlocked when the dialog pops up. +Does this mean the username/password is being sent unencrypted?

+

No, the username/password is transmitted encrypted. The icon in + Netscape browsers is not actually synchronized with the SSL/TLS layer. + It only toggles to the locked state when the first part of the actual + webpage data is transferred, which may confuse people. The Basic + Authentication facility is part of the HTTP layer, which is above + the SSL/TLS layer in HTTPS. Before any HTTP data communication takes + place in HTTPS, the SSL/TLS layer has already completed its handshake + phase, and switched to encrypted communication. So don't be + confused by this icon.

+ + +

Why do I get I/O errors when connecting via +HTTPS to an Apache+mod_ssl server with Microsoft Internet Explorer (MSIE)?

+

The first reason is that the SSL implementation in some MSIE versions has + some subtle bugs related to the HTTP keep-alive facility and the SSL close + notify alerts on socket connection close. Additionally the interaction + between SSL and HTTP/1.1 features are problematic in some MSIE versions. + You can work around these problems by forcing Apache not to use HTTP/1.1, + keep-alive connections or send the SSL close notify messages to MSIE clients. + This can be done by using the following directive in your SSL-aware + virtual host section:

+

+ SetEnvIf User-Agent ".*MSIE.*" \
+ nokeepalive ssl-unclean-shutdown \
+ downgrade-1.0 force-response-1.0 +

+

Further, some MSIE versions have problems with particular ciphers. + Unfortunately, it is not possible to implement a MSIE-specific + workaround for this, because the ciphers are needed as early as the + SSL handshake phase. So a MSIE-specific + SetEnvIf won't solve these + problems. Instead, you will have to make more drastic + adjustments to the global parameters. Before you decide to do + this, make sure your clients really have problems. If not, do not + make these changes - they will affect all your clients, MSIE + or otherwise.

+ +

The next problem is that 56bit export versions of MSIE 5.x + browsers have a broken SSLv3 implementation, which interacts badly + with OpenSSL versions greater than 0.9.4. You can accept this and + require your clients to upgrade their browsers, you can downgrade to + OpenSSL 0.9.4 (not advised), or you can work around this, accepting + that your workaround will affect other browsers too:

+

SSLProtocol all -SSLv3

+

will completely disables the SSLv3 protocol and allow those + browsers to work. A better workaround is to disable only those + ciphers which cause trouble.

+

SSLCipherSuite + ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP +

+ +

This also allows the broken MSIE versions to work, but only removes the + newer 56bit TLS ciphers.

+ +

Another problem with MSIE 5.x clients is that they refuse to connect to + URLs of the form https://12.34.56.78/ (where IP-addresses are used + instead of the hostname), if the server is using the Server Gated + Cryptography (SGC) facility. This can only be avoided by using the fully + qualified domain name (FQDN) of the website in hyperlinks instead, because + MSIE 5.x has an error in the way it handles the SGC negotiation.

+ +

And finally there are versions of MSIE which seem to require that + an SSL session can be reused (a totally non standard-conforming + behaviour, of course). Connecting with those MSIE versions only work + if a SSL session cache is used. So, as a work-around, make sure you + are using a session cache (see the SSLSessionCache directive).

+ + +

Why do I get I/O errors, or the message "Netscape has +encountered bad data from the server", when connecting via +HTTPS to an Apache+mod_ssl server with Netscape Navigator?

+

+ This usually occurs when you have created a new server certificate for + a given domain, but had previously told your browser to always accept + the old server certificate. Once you clear the entry for the old + certificate from your browser, everything should be fine. Netscape's SSL + implementation is correct, so when you encounter I/O errors with Netscape + Navigator it is usually caused by the configured certificates.

+ +
top
+
+

mod_ssl Support

+ + +

What information resources are available in case of mod_ssl problems?

+

The following information resources are available. + In case of problems you should search here first.

+ +
+
Answers in the User Manual's F.A.Q. List (this)
+
+ http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html
+ First check the F.A.Q. (this text). If your problem is a common + one, it may have been answered several times before, and been included + in this doc. +
+
Postings from the modssl-users Support Mailing List + http://www.modssl.org/support/
+
Search for your problem in the archives of the modssl-users mailing list. + You're probably not the first person to have had this problem! +
+
+ + +

What support contacts are available in case +of mod_ssl problems?

+

The following lists all support possibilities for mod_ssl, in order of + preference. Please go through these possibilities + in this order - don't just pick the one you like the look of.

+
    +
  1. Send a Problem Report to the modssl-users Support Mailing List
    + + modssl-users@modssl.org
    + This is the preferred way of submitting your problem report, because this way, + others can see the problem, and learn from any answers. You must subscribe to + the list first, but you can then easily discuss your problem with both the + author and the whole mod_ssl user community. +
    2. + +
  2. Send a Problem Report to the Apache httpd Users Support Mailing List
    + + users@httpd.apache.org
    + This is the second way of submitting your problem report. Again, you must + subscribe to the list first, but you can then easily discuss your problem + with the whole Apache httpd user community. +
    3. + +
  3. Write a Problem Report in the Bug Database
    + + http://httpd.apache.org/bug_report.html
    + This is the last way of submitting your problem report. You should only + do this if you've already posted to the mailing lists, and had no success. + Please follow the instructions on the above page carefully. +
    4. +
+ + +

What information should I +provide when writing a bug report?

+

You should always provide at least the following information:

+ +
+
Apache and OpenSSL version information
+
The Apache version can be determined + by running httpd -v. The OpenSSL version can be + determined by running openssl version. Alternatively, if + you have Lynx installed, you can run the command lynx -mime_header + http://localhost/ | grep Server to gather this information in a + single step. +
+ +
The details on how you built and installed Apache+mod_ssl+OpenSSL
+
For this you can provide a logfile of your terminal session which shows + the configuration and install steps. If this is not possible, you + should at least provide the configure command line you used. +
+ +
In case of core dumps please include a Backtrace
+
If your Apache+mod_ssl+OpenSSL dumps its core, please attach + a stack-frame ``backtrace'' (see below + for information on how to get this). This information is required + in order to find a reason for your core dump. +
+ +
A detailed description of your problem
+
Don't laugh, we really mean it! Many problem reports don't + include a description of what the actual problem is. Without this, + it's very difficult for anyone to help you. So, it's in your own + interest (you want the problem be solved, don't you?) to include as + much detail as possible, please. Of course, you should still include + all the essentials above too. +
+
+ + +

I had a core dump, can you help me?

+

In general no, at least not unless you provide more details about the code + location where Apache dumped core. What is usually always required in + order to help you is a backtrace (see next question). Without this + information it is mostly impossible to find the problem and help you in + fixing it.

+ + +

How do I get a backtrace, to help find +the reason for my core dump?

+

Following are the steps you will need to complete, to get a backtrace:

+
    +
  1. Make sure you have debugging symbols available, at least + in Apache. On platforms where you use GCC/GDB, you will have to build + Apache+mod_ssl with ``OPTIM="-g -ggdb3"'' to get this. On + other platforms at least ``OPTIM="-g"'' is needed. +
    2. + +
  2. Start the server and try to reproduce the core-dump. For this you may + want to use a directive like ``CoreDumpDirectory /tmp'' to + make sure that the core-dump file can be written. This should result + in a /tmp/core or /tmp/httpd.core file. If you + don't get one of these, try running your server under a non-root UID. + Many modern kernels do not allow a process to dump core after it has + done a setuid() (unless it does an exec()) for + security reasons (there can be privileged information left over in + memory). If necessary, you can run /path/to/httpd -X + manually to force Apache to not fork. +
    3. + +
  3. Analyze the core-dump. For this, run gdb /path/to/httpd + /tmp/httpd.core or a similar command. In GDB, all you + have to do then is to enter bt, and voila, you get the + backtrace. For other debuggers consult your local debugger manual. +
    4. +
+ +
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/ssl/ssl_howto.html b/rubbos/app/apache2/manual/ssl/ssl_howto.html new file mode 100644 index 00000000..9f06e018 --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_howto.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssl_howto.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/rubbos/app/apache2/manual/ssl/ssl_howto.html.en b/rubbos/app/apache2/manual/ssl/ssl_howto.html.en new file mode 100644 index 00000000..f09492d6 --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_howto.html.en @@ -0,0 +1,284 @@ + + + +SSL/TLS Strong Encryption: How-To - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

SSL/TLS Strong Encryption: How-To

+
+

Available Languages:  en 

+
+ +
+

The solution of this problem is trivial +and is left as an exercise for the reader.

+ +

-- Standard textbook cookie

+
+ +

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 it 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.

+
+ +
top
+
+

Cipher Suites and Enforced Strong Security

+ + + +

How can I create a real SSLv2-only server?

+ +

The following creates an SSL server which speaks only the SSLv2 protocol and + its ciphers.

+ +

httpd.conf

+ SSLProtocol -all +SSLv2
+ SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
+

+ + +

How can I create an SSL server which accepts strong encryption +only?

+ +

The following enables only the seven strongest ciphers:

+

httpd.conf

+ SSLProtocol all
+ SSLCipherSuite HIGH:MEDIUM
+

+ + +

How can I create an SSL server which accepts strong encryption +only, but allows export browsers to upgrade to stronger encryption?

+ +

This facility is called Server Gated Cryptography (SGC) and details + you can find in the README.GlobalID 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:

+

httpd.conf

+ # allow all ciphers for the initial handshake,
+ # so export browsers can upgrade via SGC facility
+ SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
+
+ <Directory /usr/local/apache2/htdocs>
+ # but finally deny all browsers which haven't upgraded
+ SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
+ </Directory> +

+ + +

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?

+ +

Obviously you cannot just use a server-wide SSLCipherSuite 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:

+

+ # 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> +

+ +
top
+
+

Client Authentication and Access Control

+ + + +

How can I authenticate clients based on certificates when I know +all my clients?

+ +

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 + ca.crt and then verify the clients against this + certificate.

+

httpd.conf

+ # 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 +

+ + +

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?

+ +

For this we again use the per-directory reconfiguration feature + of mod_ssl:

+ +

httpd.conf

+ SSLVerifyClient none
+ SSLCACertificateFile conf/ssl.crt/ca.crt
+
+ <Location /secure/area>
+ SSLVerifyClient require
+ SSLVerifyDepth 1
+ </Location>
+

+ + +

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?

+ +

The key is to check for various ingredients of the client certificate. + Usually this means to check the whole or part of the Distinguished + Name (DN) of the Subject. For this two methods exists: The mod_auth based variant and the SSLRequire 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 all + 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.

+ +

The first method:

+

httpd.conf

+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>
+ +

The password used in this example is the DES encrypted string "password". + See the SSLOptions docs for more + information.

+ +

httpd.passwd

+/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
+ +

The second method:

+ +

httpd.conf

+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>
+ + +

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?

+ +

Let us assume the Intranet can be distinguished through the IP + network 192.168.1.0/24 and the subarea on the Intranet website has + the URL /subarea. Then configure the following outside + your HTTPS virtual host (so it applies to both HTTPS and HTTP):

+ +

httpd.conf

+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>
+ +
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/ssl/ssl_intro.html b/rubbos/app/apache2/manual/ssl/ssl_intro.html new file mode 100644 index 00000000..0163b215 --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_intro.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssl_intro.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +URI: ssl_intro.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 diff --git a/rubbos/app/apache2/manual/ssl/ssl_intro.html.en b/rubbos/app/apache2/manual/ssl/ssl_intro.html.en new file mode 100644 index 00000000..c3079d4e --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_intro.html.en @@ -0,0 +1,641 @@ + + + +SSL/TLS Strong Encryption: An Introduction - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

SSL/TLS Strong Encryption: An Introduction

+
+

Available Languages:  en  | + ja 

+
+ +
+

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.

+ +

-- A. Tanenbaum, "Introduction to +Computer Networks"

+
+ +

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.

+ +

The presented content is mainly derived, with permission by the author, +from the article Introducing +SSL and Certificates using SSLeay from Frederick J. Hirsch, of The +Open Group Research Institute, which was published in Web Security: A Matter of +Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997. +Please send any positive feedback to Frederick Hirsch (the original +article author) and all negative feedback to Ralf S. Engelschall (the +mod_ssl author).

+
+ +
top
+
+

Cryptographic Techniques

+ +

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 [AC96]) and provide the basis for privacy, +integrity, and authentication.

+ +

Cryptographic Algorithms

+ +

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.

+ +

There are two categories of cryptographic algorithms: conventional + and public key.

+ +
+
Conventional cryptography
+
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.
+ +
Public key cryptography
+
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).
+
+ +

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.

+ + +

Message Digests

+ +

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.

+ +

A summary such as this is called a message digest, one-way +function or hash function. 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.

+

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 do this is to include the digest in a digital +signature.

+ + +

Digital Signatures

+

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 digital signature, created by Alice and +included with the message, serves this purpose.

+ +

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 decrypt 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.

+

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).

+ +
top
+
+

Certificates

+ +

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.

+ +

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 Certificate Authority, and +certificates are used for authentication.

+ +

Certificate Contents

+ +

A certificate associates a public key with the real identity of + an individual, server, or other entity, known as the subject. As + shown in Table 1, 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.

+ +

Table 1: Certificate Information

+ + + + + + + + + + + + + +
SubjectDistinguished Name, Public Key
IssuerDistinguished Name, Signature
Period of ValidityNot Before Date, Not After Date
Administrative InformationVersion, Serial Number
Extended InformationBasic Constraints, Netscape Flags, etc.
+ + +

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 [X509], which defines the fields, field names, and + abbreviations used to refer to the fields (see Table + 2).

+ +

Table 2: Distinguished Name Information

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DN FieldAbbrev.DescriptionExample
Common NameCNName being certifiedCN=Joe Average
Organization or CompanyOName is associated with this
organization		O=Snake Oil, Ltd.
Organizational UnitOUName is associated with this
organization unit, such + as a department		OU=Research Institute
City/LocalityLName is located in this CityL=Snake City
State/ProvinceSTName is located in this State/ProvinceST=Desert
CountryCName is located in this Country (ISO code)C=XZ
+ + +

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 *.snakeoil.com.

+ +

The binary format of a certificate is defined using the ASN.1 + notation [X208] [PKCS]. 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 + [MIME]. 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.

+ +

Example of a PEM-encoded certificate (snakeoil.crt)

-----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-----
+ + +

Certificate Authorities

+ +

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.

+ +

Certificate Chains

+ +

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.

+ + +

Creating a Root-Level CA

+ +

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.

+ +

A number of companies, such as Thawte and VeriSign + have established themselves as Certificate Authorities. These + companies provide the following services:

+ +
    +
  • Verifying certificate requests
    • +
  • Processing certificate requests
    • +
  • Issuing and managing certificates
    • +
+ +

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.

+ + +

Certificate Management

+ +

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.

+ +

Note

+

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.

+
+ + + +
top
+
+

Secure Sockets Layer (SSL)

+ +

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.

+ +

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.

+ +

Table 4: Versions of the SSL protocol

+ + + + + + + + + + + + + + + + + + + +
VersionSourceDescriptionBrowser Support
SSL v2.0Vendor Standard (from Netscape Corp.) [SSL2]First SSL protocol for which implementations exists- NS Navigator 1.x/2.x
+ - MS IE 3.x
+ - Lynx/2.8+OpenSSL
SSL v3.0Expired Internet Draft (from Netscape Corp.) [SSL3]Revisions to prevent specific security attacks, add non-RSA + ciphers, and support for certificate chains- NS Navigator 2.x/3.x/4.x
+ - MS IE 3.x/4.x
+ - Lynx/2.8+OpenSSL
TLS v1.0Proposed Internet Standard (from IETF) [TLS1]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.- Lynx/2.8+OpenSSL
+ + +

There are a number of versions of the SSL protocol, as shown in +Table 4. 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 +[TLS] protocol standard, currently in development by +the Internet Engineering Task Force (IETF).

+ +

Session Establishment

+ +

The SSL session is established by following a handshake sequence + between client and server, as shown in Figure 1. 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.

+ +

Note

+

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).

+
+ +

+
+ Figure 1: Simplified SSL + Handshake Sequence

+ +

The elements of the handshake sequence, as used by the client and + server, are listed below:

+ +
    +
  1. Negotiate the Cipher Suite to be used during data transfer
    2. +
  2. Establish and share a session key between client and server
    3. +
  3. Optionally authenticate the server to the client
    4. +
  4. Optionally authenticate the client to the server
    5. +
+ +

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:

+ +
    +
  • Key Exchange Method
    • +
  • Cipher for Data Transfer
    • +
  • Message Digest for creating the Message Authentication Code (MAC)
    • +
+ +

These three elements are described in the sections that follow.

+ + +

Key Exchange Method

+ +

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.

+ +

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 [AC96, p516].

+ + +

Cipher for Data Transfer

+ +

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:

+ +
    +
  • No encryption
    • +
  • Stream Ciphers +
      +
    • RC4 with 40-bit keys
      • +
    • RC4 with 128-bit keys
      • +
    • +
  • CBC Block Ciphers +
    • RC2 with 40 bit key
      • +
    • DES with 40 bit key
      • +
    • DES with 56 bit key
      • +
    • Triple-DES with 168 bit key
      • +
    • Idea (128 bit key)
      • +
    • Fortezza (96 bit key)
      • +
    • +
+ +

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 [AC96, 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 [AC96, + ch13].

+ + +

Digest Function

+ +

The choice of digest function determines how a digest is created + from a record unit. SSL supports the following:

+ +
    +
  • No digest (Null choice)
    • +
  • MD5, a 128-bit hash
    • +
  • Secure Hash Algorithm (SHA-1), a 160-bit hash
    • +
+ +

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.

+ + +

Handshake Sequence Protocol

+ +

The handshake sequence uses three protocols:

+ +
    +
  • The SSL Handshake Protocol + for performing the client and server SSL session establishment.
    • +
  • The SSL Change Cipher Spec Protocol for actually + establishing agreement on the Cipher Suite for the session.
    • +
  • The SSL Alert Protocol for conveying SSL error + messages between client and server.
    • +
+ +

These protocols, as well as application protocol data, are + encapsulated in the SSL Record Protocol, as shown in + Figure 2. 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.

+ +

+
+ Figure 2: SSL Protocol Stack +

+ +

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.

+ + +

Data Transfer

+ +

The SSL Record Protocol, shown in Figure 3, + 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).

+ +

+
+ Figure 3: SSL Record Protocol +

+ + +

Securing HTTP Communication

+ +

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 + https rather than http and a different + server port (by default 443). This mainly is what mod_ssl provides to you for the Apache webserver...

+ +
top
+
+

References

+ +
+
[AC96]
+
Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, +1996. See http://www.counterpane.com/ for various other materials by Bruce +Schneier.
+ +
[X208]
+
ITU-T Recommendation X.208, Specification of Abstract Syntax Notation +One (ASN.1), 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I. +
+ +
[X509]
+
ITU-T Recommendation X.509, The Directory - Authentication +Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509. +
+ +
[PKCS]
+
Public Key Cryptography Standards (PKCS), +RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.
+ +
[MIME]
+
N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies, RFC2045. +See for instance http://ietf.org/rfc/rfc2045.txt.
+ +
[SSL2]
+
Kipp E.B. Hickman, The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.
+ +
[SSL3]
+
Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol +Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.
+ +
[TLS1]
+
Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, +1999. See http://ietf.org/rfc/rfc2246.txt.
+
+
+
+

Available Languages:  en  | + ja 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/ssl/ssl_intro.html.ja.utf8 b/rubbos/app/apache2/manual/ssl/ssl_intro.html.ja.utf8 new file mode 100644 index 00000000..eb497b47 --- /dev/null +++ b/rubbos/app/apache2/manual/ssl/ssl_intro.html.ja.utf8 @@ -0,0 +1,695 @@ + + + +SSL/TLS 暗号化: はじめに - Apache HTTP サヌバ + + + + +
+

モゞュヌル | ディレクティブ | FAQ | 甚語 | サむトマップ

+

Apache HTTP サヌバ バヌゞョン 2.0

+
+
<-
+

SSL/TLS 暗号化: はじめに

+
+

Available Languages:  en  | + ja 

+
+ +
+

暙準芏栌の良い所は、たくさんの芏栌から遞べるずいうこずだ。 +そしお、もし本圓にどの芏栌も気に入らなければ、 +䞀幎埅぀だけで探しおいた芏栌が珟れる。

+ +

-- A. Tanenbaum, "Introduction to +Computer Networks"

+
+ +

+入門ずいうこずで、この章は Web、HTTP、Apache に通じおいる +読者向けですが、セキュリティ専門家向けではありたせん。 +SSL プロトコルの決定的な手匕きである぀もりはありたせん。 +たた、組織内の認蚌管理のための特定のテクニックや、 +特蚱や茞出芏制などの重芁な法的な問題に぀いおも扱いたせん。 +むしろ、曎なる研究ぞの出発点ずしお色々な抂念、定矩、䟋を䞊べるこずで + mod_ssl のナヌザに基瀎知識を提䟛する事を目的ずしおいたす。

+ +

ここに瀺された内容は䞻に、原著者の蚱可の䞋 +The Open Group Research Institute の Frederick J. Hirsch + 氏の蚘事 +Introducing SSL and Certificates using SSLeay を基にしおいたす。 +氏の蚘事は Web Security: A Matter of +Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997 +に掲茉されたした。 +肯定的な意芋は Frederick Hirsch 氏 + (元蚘事の著者) ぞ党おの苊情は Ralf S. Engelschall ( +mod_ssl の䜜者) ぞお願いしたす。 +[蚳泚: 蚳に぀いおは +Apache ドキュメント翻蚳プロゞェクト +ぞお願いしたす。]

+
+ +
top
+
+

暗号化技術

+ +

SSL を理解するには、暗号アルゎリズム、 +メッセヌゞダむゞェスト関数(別名: 䞀方向関数、ハッシュ関数)、 +電子眲名などぞの理解が必芁です。 +これらの技術は本が䞞ごず必芁な題目で +(䟋えば [AC96] を参照)、 +プラむバシヌ、信甚、認蚌などの技術の基瀎ずなっおいたす。

+ +

暗号アルゎリズム

+ +

䟋えば、アリスが送金のために銀行にメッセヌゞを送りたいずしたす。 + 口座番号や送金の金額が含たれるため、 + アリスはそのメッセヌゞを秘密にしたいず思いたす。 + 解決方法の䞀぀は暗号アルゎリズムを䜿っお、メッセヌゞを + 読たせたい人以倖は読むこずができない暗号化された + 圢態に倉えおしたうこずです。 + その圢態になるず、 + メッセヌゞは秘密の鍵によっおのみ解釈するこずができたす。 + 鍵なしでは、メッセヌゞは圹に立ちたせん。 + 良い暗号アルゎリズムは、䟵入者が元のテキストを解読するこずを + 非垞に難しくするため、努力が割に合わなくさせたす。

+ +

暗号アルゎリズムには + 埓来型ず公開鍵の二぀の皮類がありたす。

+ +
+
埓来型暗号
+
察称暗号ずしおも知られ、 + 送信者ず受信者が鍵を共有するこずが必芁です。 + 鍵ずは、メッセヌゞを暗号化したり埩号するのに䜿われる秘密 + の情報のこずです。 + もし、この鍵が秘密なら、送信者ず受信者以倖は誰もメッセヌゞを読 + むこずができたせん。 + もしも、アリスず銀行が秘密の鍵を知っおいるなら、 + 圌らはお互いに秘密のメッセヌゞを送るこずができるでしょう。 + ただし、事前に内密に鍵を遞ぶずいう仕事は問題を含んでいたす。
+ +
公開鍵暗号
+
非察称暗号ずしおも知られ、 + メッセヌゞを暗号化するこずのできる二぀の鍵 + を䜿甚するアルゎリズムを定矩するこずで鍵のやり取りの問題を解決 + したす。 + もし、ある鍵が暗号化に䜿われたなら、 + もう片方の鍵で埩号しなければいけたせん。 + この方匏によっお、䞀぀の鍵を公衚しお(公開鍵)、 + もう片方を秘密にしおおく(秘密鍵)だけで、 + 安党なメッセヌゞを受け取るこずができたす。
+
+ +

誰もが暗号化されたメッセヌゞを公開鍵によっお暗号化 + するこずができたすが、秘密鍵の持ち䞻だけがそれを読むこずが + できたす。 + この方法で、銀行の公開鍵を䜿っお暗号化するこずで、 + アリスは秘密のメッセヌゞを送るこずができたす。 + 銀行のみが埩号するこずができたす。

+ + +

メッセヌゞダむゞェスト

+ +

アリスはメッセヌゞを秘密にするこずができたすが、 + 誰かが䟋えば自分に送金するようにメッセヌゞを倉曎したり、 + 別のものに眮き換えおしたうかもしれないずいう問題がありたす。 + アリスのメッセヌゞの信甚を保蚌する方法の䞀぀は、 + メッセヌゞの簡朔なダむゞェストを䜜っお、それも銀行に送るずいうものです。 + メッセヌゞを受け取るず銀行もダむゞェストを䜜成し、 + アリスが送ったものず比べたす。もし䞀臎したなら、 + 受け取ったメッセヌゞは無傷だずいうこずになりたす。

+ +

このような芁玄はメッセヌゞダむゞェスト、 + 䞀方行関数、たたはハッシュ関数ず呌ばれたす。 + メッセヌゞダむゞェストは長い可倉長のメッセヌゞから + 短い固定長の衚珟を䜜るのに䜿われたす。 + ダむゞェストアルゎリズムはメッセヌゞから + 䞀意なダむゞェストを生成するように䜜られおいたす。 + メッセヌゞダむゞェストはダむゞェストから元のメッセヌゞを + 刀定するのがずおも難しいようにできおいたす。 + たた、同じ芁玄を䜜成する二぀のメッセヌゞを探すのは䞍可胜です。 + よっお、同じ芁玄を䜿っおメッセヌゞを眮き換えるずいう + 可胜性を排陀しおいたす。

+ +

アリスぞのもう䞀぀の問題は、このダむゞェストを安党に送る方法を探すこずです。 +これができれば、メッセヌゞの信甚が保蚌されたす。 +䞀぀の方法はこのダむゞェストに電子眲名を含むこずです。

+ + +

電子眲名

+

アリスが銀行にメッセヌゞを送ったずき、銀行は、 +䟵入者が圌女になりすたしお圌女の口座ぞの取匕を申請しおいないか、 +メッセヌゞが本圓に圌女からのものか確実に分からなければいけたせん。 +アリスによっお䜜成され、メッセヌゞに含たれた +電子眲名がここで圹に立ちたす。

+ +

電子眲名はメッセヌゞのダむゞェストやその他の情報(凊理番号など)を +送信者の秘密鍵で暗号化するこずで䜜られたす。 +誰もが公開鍵を䜿っお眲名を埩号するこずができたすが、 +眲名者のみが秘密鍵を知っおいたす。 +これは、圌らのみが眲名しえたこずを意味したす。 +ダむゞェストを電子眲名に含むこずは、 +その眲名がそのメッセヌゞのみに有効であるこずを意味したす。 +これは、誰もダむゞェストを倉えお眲名をするこずができないため、 +メッセヌゞの信甚も保蚌したす。

+ +

䟵入者が眲名を傍受しお埌日に再利甚するのを防ぐため +電子眲名には䞀意な凊理番号が含たれたす。 +これは、アリスがそんなメッセヌゞは送っおいないず蚀う詐欺 +から銀行を守りたす。 +圌女だけが眲名しえたからです。(吊認防止)

+ +
top
+
+

蚌明曞

+ +

アリスは秘密のメッセヌゞを銀行に送り、 +眲名をしお、メッセヌゞの信甚を保蚌するこずができるおうになりたしたが、 +通信しおいる盞手が本圓に銀行なのか確かめなくおはいけたせん。 +これは、圌女が䜿う公開鍵が銀行の秘密鍵ず察になっおいるものか、 +圌女は確かめなくおはいけないずいうこずを意味したす。 +同様に、銀行はメッセヌゞの眲名が本圓にアリスの眲名か確認する必芁が +ありたす。

+ +

もし䞡者に身元を蚌明し、公開鍵を確認し、たた信頌された機関が眲名 +した蚌明曞があれば、䞡者ずも通信盞手に぀いお正しい盞手だず +確信するこずができたす。 +そのような信頌された機関は認蚌局 + (Certificate Authority たたは CA) ず呌ばれ、 +蚌明曞 (certificate) が認蚌 (authentication) に䜿われたす。

+ +

蚌明曞の内容

+ +

蚌明曞は公開鍵ず個人、サヌバ、その他の䞻䜓の実圚の身元を + 関連付けたす。 + è¡š1に瀺されるように蚌明察象の情報は + 身元蚌明の情報(識別名)ず公開鍵が含たれたす。 + 蚌明曞はたた、認蚌局の身元蚌明ず眲名、そしお蚌明曞の有効期間を + 含みたす。 + シリアルナンバヌなどの認蚌局の管理䞊の情報や + その他の远加の情報が含たれおいるかもしれたせん。

+ +

è¡š1: 蚌明曞情報

+ + + + + + + + + + + + + +
蚌明察象識別名、公開鍵
発行者識別名、公開鍵
有効期間開始日、倱効日
管理情報バヌゞョン、シリアルナンバヌ
拡匵情報基本的な制玄、ネットスケヌプフラッグ、その他
+ + +

識別名(ディスティングむッシュ・ネヌム)は特定の状況における + 身分蚌明を提䟛するのに䜿われおいたす。䟋えば、ある人は + 私甚ず䌚瀟ずで別々の身分蚌明を持぀かもしれたせん。 + + 識別名は X.509 暙準芏栌 [X509] で定矩されおいたす。 + X.509 暙準芏栌は、項目、項目名、そしお項目の略称を定矩しおいたす。(è¡š + 2 参照)

+ +

è¡š 2: 識別名情報

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
識別名項目略称説明䟋
Common Name (コモンネヌム)CN認蚌される名前
+ SSL接続するURL		CN=www.example.com
Organization or Company (組織名)O団䜓の正匏英語組織名O=Example Japan K.K.
Organizational Unit (郚門名)OU郚眲名などOU=Customer Service
City/Locality (垂区町村)L所圚しおる垂区町村L=Sapporo
State/Province (郜道府県)ST所圚しおる郜道府県ST=Hokkaido
Country(囜)C所圚しおいる囜名の ISO コヌド
+ 日本の堎合 JP + 		C=JP
+ + +

認蚌局はどの項目が省略可胜でどれが必須かの方針を定矩する + かもしれたせん。項目の内容に぀いおも認蚌局や蚌明曞のナヌザからの + 芁件があるかもしれたせん。 + 䟋えば、ネットスケヌプのブラりザはサヌバの蚌明曞の + Common Name (コモンネヌム)がサヌバのドメむン名の + *.example.com + ずいうようなワむルドカヌドのパタヌンにマッチするこず + を芁求したす。

+ +

バむナリ圢匏の蚌明曞は ASN.1 衚蚘法 + [X208] [PKCS] で + 定矩されおいたす。 + この衚蚘法は内容をどのように蚘述するかを定矩し、 + 笊号化の芏定がこの情報がどのようにバむナリ圢匏に倉換されるかを + 定矩したす。 + 蚌明曞のバむナリ笊号化は Distinguished Encoding + Rules (DER) で定矩され、それはより䞀般的な Basic Encoding Rules + (BER) に基づいおいたす。 + バむナリ圢匏を扱うこずのできない送信では、 + バむナリ圢匏は Base64 笊号化 [MIME] で + ASCII 圢匏に倉換されるこずがありたす。 + このように笊号化され、以䞋の䟋に瀺されるように区切り行に + 挟たれたものは PEM 笊号化されたず蚀いたす。 + (PEM の名前は "Privacy Enhanced Mail" に由来したす)

+ +

PEM 笊号化された蚌明曞の䟋 (example.crt)

-----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-----
+ + +

認蚌局

+ +

たず蚌明曞の申請の情報を確認するこずで、 + 認蚌局は秘密鍵の持ち䞻の身元を保蚌したす。 + 䟋えば、アリスが個人蚌明曞を申請したずするず、 + 認蚌局はアリスが蚌明曞の申請が䞻匵する通りの + 人物だずいうこずを確認しなくおはいけたせん。

+ +

蚌明曞階局構造

+ +

認蚌局は他の認蚌局ぞの蚌明曞を発行するこずができたす。 + 未知の蚌明曞を調べる時に、アリスはその蚌明曞の発行者 + に自信が持おるたで、発行者の蚌明曞を + その䞊䜍階局の認蚌局をたどっお調べる必芁がありたす。 + 「悪質な」蚌明曞の危険性を枛らすため、 + 圌女は限られた連鎖の発行者のみ信頌するように + 決めるこずもできたす。

+ + +

最䞊䜍認蚌局の䜜成

+ +

前に述べたように、党おの蚌明曞に぀いお、 + 最䞊䜍の認蚌局(CA)たでそれぞれの発行者が + 察象の身元蚌明の有効性を明らかにする必芁がありたす。 + 問題は、誰がその最䞊䜍の認蚌機関の蚌明曞を保蚌するのか、 + ずいうこずです。 + このような堎合に限り、蚌明曞は「自己眲名」されたす。 + ぀たり、蚌明曞の発行者ず蚌明察象が同じずいうこずになりたす。 + その結果、自己眲名された蚌明曞を信甚するには + 现心の泚意が必芁です。 + 最䞊䜍認蚌局が公開鍵を広く公衚するこずで、 + その鍵を信頌するリスクを䜎くするこずができたす。 + もし、他人がその認蚌局になりすたした時に、それが露芋しや + すいからです。 + 倚くのブラりザは有名な認蚌局を信頌するように + 蚭定されおいたす。

+ +

Thawte + や VeriSign + のような倚くの䌚瀟が認蚌局ずしお開蚭したした。 + このような䌚瀟は以䞋のサヌビスを提䟛したす:

+ +
    +
  • 蚌明曞申請の確認
    • +
  • 蚌明曞申請の凊理
    • +
  • 蚌明曞の発行ず管理
    • +
+ +

自分で認蚌局を䜜るこずも可胜です。 + むンタヌネット環境では危険ですが、 + 個人やサヌバの身元蚌明が簡単に行える組織の + むントラネット内では圹に立぀かもしれたせん。

+ + +

蚌明曞管理

+ +

認蚌局の開蚭は培底した管理、技術、運甚の䜓制を必芁ずする + 責任のある仕事です。 + 認蚌局は蚌明曞を発行するだけでなく、 + 管理もしなければなりたせん。 + 具䜓的には、蚌明曞がい぀たで有効かを決定し、曎新し、 + たた既に発行されたが倱効した蚌明曞のリスト + (Certificate Revocation Lists たたは CRL) + を管理しなければいけたせん。 + 䟋えば、アリスが䌚瀟から瀟員ずしお蚌明曞を䞎えられたずしたす。 + そしお、アリスが䌚瀟を蟞めるずきには蚌明曞を取り消さなければ + いけないずしたす。 + 蚌明曞は次々ず人に枡されおいくものなので、 + 蚌明曞そのものから、それが取り消されたか刀断するこずは + 䞍可胜です。 + よっお、蚌明曞の有効性を調べるずきには、 + 認蚌局に連絡しお CRL を照合する必芁がありたす。 + 普通この過皋は自動化されおいるものではありたせん。

+ +

泚意

+

デフォルトでブラりザに蚭定されおいない認蚌局を䜿った堎合、 + 認蚌局の蚌明曞をブラりザに読み蟌んで、 + ブラりザがその認蚌局によっお眲名されたサヌバの蚌明曞を + 有効化する必芁がありたす。 + 䞀床読み蟌たれるず、その認蚌局によっお眲名された党おの + 蚌明曞を受け入れるため、危険を䌎いたす。

+
+ + + +
top
+
+

Secure Sockets Layer (SSL)

+ +

Secure Sockets Layer プロトコルは信頌性のあるコネクション型の +ネットワヌク局のプロトコル(䟋えば、TCP/IP)ず +アプリケヌション局のプロトコル(䟋えば、HTTP) +の間に眮くこずができたす。 +SSL は、盞互認蚌によっおサヌバずクラむアント間の安党な通信を、 +電子眲名によっおデヌタの完党性を、 +そしお暗号化によっおプラむバシを提䟛したす。

+ +

SSL プロトコルは暗号化、ダむゞェスト、電子眲名に぀いお、 +様々なアルゎリズムをサポヌトするようにできおいたす。 +こうするこずで、法や茞出の芏制を考慮に入れお、サヌバに合わせた +アルゎリズムを遞ぶこずができ、たた、新しいアルゎリズムを +利甚しおいくこずも可胜にしおいたす。 +アルゎリズムの遞択はプロトコルセッション開始時に +サヌバずクラむアント間で取り決められたす。

+ +

è¡š4: SSL プロトコルのバヌゞョン

+ + + + + + + + + + + + + + + + + + + +
バヌゞョン出兞説明ブラりザのサポヌト
SSL v2.0Vendor Standard (Netscape Corp. より) [SSL2]実装が珟存する初めおの SSL プロトコル- NS Navigator 1.x/2.x
+ - MS IE 3.x
+ - Lynx/2.8+OpenSSL
SSL v3.0Expired Internet Draft (Netscape Corp. より) [SSL3]特定のセキュリティ攻撃を防ぐための改蚂、 + 非RSA 暗号の远加、蚌明曞階局構造のサポヌト- NS Navigator 2.x/3.x/4.x
+ - MS IE 3.x/4.x
+ - Lynx/2.8+OpenSSL
TLS v1.0Proposed Internet Standard (IETF より) [TLS1]MAC レむダを HMAC ぞ曎新、ブロック暗号の block + padding、メッセヌゞ順序の暙準化、譊告文の充実などのため + SSL 3.0 を改蚂。- Lynx/2.8+OpenSSL
+ + +

è¡š4に瀺されるずおり、SSL プロトコルには +いく぀ものバヌゞョンがありたす。 +衚にも曞かれおいるように、SSL 3.0 の利点の䞀぀は +蚌明曞階局構造をサポヌトするこずです。 +この機胜によっお、サヌバは自分の蚌明曞に加えお、 +発行者の蚌明曞をブラりザに枡すこずができたす。 +蚌明曞階局構造によっお、 +ブラりザに発行者の蚌明曞が盎接登録されおいなくおも、 +階局の䞭に含たれおいれば、 +ブラりザはサヌバの蚌明曞を有効化するこずができたす。 +SSL 3.0 は珟圚 Internet Engineering Task Force (IETF) +によっお開発されおいる Transport Layer Security +[TLS] プロトコル暙準芏栌の基瀎ずなっおいたす。

+ +

セッションの確立

+ +

図1で瀺されるように、 + セッションの確立はクラむアントずサヌバ間の + ハンドシェヌクシヌク゚ンスによっお行なわれたす。 + サヌバが蚌明曞を提䟛するか、クラむアントの蚌明曞をリク゚ストするか + ずいうサヌバの蚭定により、このシヌク゚ンスは異なるものずなりたす。 + 暗号情報の管理のために、远加のハンドシェヌク過皋が必芁になる + 堎合もありたすが、この蚘事では + よくあるシナリオを手短に説明したす。 + 党おの可胜性に぀いは、SSL 仕様曞を参照しおください。

+ +

泚意

+

䞀床 SSL セッションが確立するず、セッションを再利甚するこずで、 + セッションを開始するための倚くの過皋を繰り返すずいう + パフォヌマンスの損倱を防ぎたす。 + そのため、サヌバは党おのセッションに䞀意なセッション識別名を + 割り圓お、サヌバにキャッシュし、クラむアントは次回から + (識別名がサヌバのキャッシュで期限切れになるたでは) + ハンドシェヌクなしで接続するこずができたす。

+
+ +

+
+ 図1: SSL + ハンドシェヌクシヌク゚ンス抂略

+ +

サヌバずクラむアントで䜿われる + ハンドシェヌクシヌク゚ンスの芁玠を以䞋に瀺したす:

+ +
    +
  1. デヌタ通信に䜿われる暗号スむヌトの取り決め
    2. +
  2. クラむアントずサヌバ間でのセッション鍵の確立ず共有
    3. +
  3. オプションずしお、クラむアントに察するサヌバの認蚌
    4. +
  4. オプションずしお、サヌバに察するクラむアントの認蚌
    5. +
+ +

第䞀ステップの暗号スむヌト取り決めによっお、 + サヌバずクラむアントはそれぞれにあった + 暗号スむヌトを遞ぶこずができたす。 + SSL3.0 プロトコルの仕様曞は 31 の暗号スむヌトを定矩しおいたす。 + 暗号スむヌトは以䞋のコンポヌネントにより定矩されおいたす:

+ +
    +
  • 鍵の亀換手段
    • +
  • デヌタ通信の暗号術
    • +
  • Message Authentication Code (MAC) 䜜成のための + メッセヌゞダむゞェスト
    • +
+ +

これらの䞉぀の芁玠は以䞋のセクションで説明されおいたす。

+ + +

鍵の亀換手段

+ +

鍵の亀換手段はアプリケヌションのデヌタ通信に䜿われ、 + 共有される察称暗号鍵をどのようにがクラむアントずサヌバで + 取り決めるかを定矩したす。 + SSL 2.0 は RSA 鍵亀換しか䜿いたせんが、 + SSL 3.0 は蚌明曞が䜿われるずきは RSA 鍵亀換を䜿い、 + 蚌明曞が無く、クラむアントずサヌバの事前の通信が無い堎合は + Diffie-Hellman 鍵亀換を䜿う + など様々な鍵亀換アルゎリズムをサポヌトしたす。

+ +

鍵の亀換方法における䞀぀の遞択肢は電子眲名です。 + 電子眲名を䜿うかどうか、たた、 + どの皮類の眲名を䜿うかずいう遞択がありたす。 + 秘密鍵で眲名するこずで共有鍵を生成すし、情報亀換する時の + マン・むン・ザ・ミドル攻撃を防ぐこずができたす。 + [AC96, p516]

+ + +

デヌタ通信の暗号術

+ +

SSL はセッションのメッセヌゞの暗号化に前述した + 埓来型暗号(察称暗号)を甚いたす。 + 暗号化しないずいう遞択肢も含め九぀の遞択肢がありたす:

+ +
    +
  • 暗号化なし
    • +
  • ストリヌム暗号 +
      +
    • 40-bit 鍵での RC4
      • +
    • 128-bit 鍵での RC4
      • +
    • +
  • CBC ブロック暗号 +
    • 40 bit 鍵での RC2
      • +
    • 40 bit 鍵での DES
      • +
    • 56 bit 鍵での DES
      • +
    • 168 bit 鍵での Triple-DES
      • +
    • Idea (128 bit 鍵)
      • +
    • Fortezza (96 bit 鍵)
      • +
    • +
+ +

ここでの CBC ずは暗号ブロック連鎖 (Cipher Block Chaining) + の略で、䞀぀前の暗号化された暗号文の䞀郚が + ブロックの暗号化に䜿われるこずを意味したす。 + DES はデヌタ暗号化暙準芏栌 (Data Encryption Standard) + [AC96, ch12] の略で、 + DES40 や 3DES_EDE を含むいく぀もの皮類がありたす。 + Idea は最高なものの䞀぀で、暗号術的には珟圚ある䞭で + 最も匷力なものです。 + RC2 は RSA DSI による独占的なアルゎリズムです。 + [AC96, + ch13]

+ + +

ダむゞェスト関数

+ +

+ ダむゞェスト関数の遞択はレコヌドナニットからどのようにダむゞェストが生成されるかを決定したす。 + SSL は以䞋をサポヌトしたす:

+ +
    +
  • ダむゞェストなし
    • +
  • MD5 (128-bit ハッシュ)
    • +
  • Secure Hash Algorithm (SHA-1) (160-bit ハッシュ)
    • +
+ +

メッセヌゞダむゞェストは Message Authentication Code (MAC) + の生成に䜿われ、メッセヌゞず共に暗号化され、メッセヌゞの信甚を + 提䟛し、リプレむ攻撃を防ぎたす。

+ + +

ハンドシェヌクシヌク゚ンスプロトコル

+ +

ハンドシェヌクシヌク゚ンスは䞉぀のプロトコルを䜿いたす:

+ +
    +
  • SSL ハンドシェヌクプロトコルは + クラむアントずサヌバ間での SSL セッションの確立に䜿われたす。
    • +
  • SSL 暗号仕様倉曎プロトコルは + セッションでの暗号スむヌトの取り決めに䜿われたす。
    • +
  • SSL 譊告プロトコルは + クラむアントサヌバ間で SSL ゚ラヌを䌝達するのに䜿われたす。
    • +
+ +

䞉぀のプロトコルは、アプリケヌションプロトコルデヌタずずもに、 + 図2に瀺すずおり SSL レコヌドプロトコル + でカプセル化されたす。 + カプセル化されたプロトコルはデヌタを怜査しない + 䞋局のプロトコルによっおデヌタずしお䌝達されたす。 + カプセル化されたプロトコルは䞋局のプロトコルに関しお䞀切関知したせん。

+ +

+
+ 図2: SSL プロトコルスタック +

+ +

+ レコヌドプロトコルによる SSL コントロヌルプロトコルのカプセル化は、 + アクティブなセッションの二回目の通信があった堎合、 + コントロヌルプロトコルが安党であるこずを意味したす。 + 既にセッションが無い堎合は、Null 暗号スむヌトが䜿われ、 + 暗号化は行なわれず、セッションが確立するたでは + ダむゞェストも無い状態ずなりたす。

+ + +

デヌタ通信

+ +

図3に瀺される SSL レコヌドプロトコル + はクラむアントずサヌバ間のアプリケヌションや + SSL コントロヌルデヌタの通信に䜿われたす。 + このデヌタはより小さいナニットに分けられたり、 + いく぀かの高玚プロトコルをたずめお䞀ナニットずしお通信が + 行なわれるこずもありたす。 + デヌタを圧瞮し、ダむゞェスト眲名を添付しお、 + これらのナニットを暗号化したのち、ベヌスずなっおいる + 信頌性のあるトランスポヌトプロトコルを甚いるかもしれたせん。 + (泚意: 珟圚メゞャヌな SLL 実装で圧瞮をサポヌトしおいるものはありたせん)

+ +

+
+ 図 3: SSL レコヌドプロトコル +

+ + +

HTTP 通信の安党化

+ +

よくある SSL の䜿い方はブラりザずりェブサヌバ間の HTTP 通信 + の安党化です。 + これは、埓来の安党ではない HTTP の䜿甚を陀倖するものではありたせん。 + 安党化されたものは䞻に SSH 䞊の普通の HTTP で、HTTPS ず呌ばれたす。 + 倧きな違いは、URL スキヌムに http の代わりに https + を甚い、サヌバが別のポヌトを䜿うこずです (デフォルトでは443)。 + これが䞻に mod_ssl が Apache りェブサヌバに提䟛する機胜です。

+ +
top
+
+

参考文献

+ +
+
[AC96]
+
Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, +1996. See http://www.counterpane.com/ for various other materials by Bruce +Schneier.
+ +
[X208]
+
ITU-T Recommendation X.208, Specification of Abstract Syntax Notation +One (ASN.1), 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I. +
+ +
[X509]
+
ITU-T Recommendation X.509, The Directory - Authentication +Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509. +
+ +
[PKCS]
+
Public Key Cryptography Standards (PKCS), +RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.
+ +
[MIME]
+
N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies, RFC2045. +See for instance http://ietf.org/rfc/rfc2045.txt.
+ +
[SSL2]
+
Kipp E.B. Hickman, The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.
+ +
[SSL3]
+
Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol +Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.
+ +
[TLS1]
+
Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, +1999. See http://ietf.org/rfc/rfc2246.txt.
+
+
+
+

Available Languages:  en  | + ja 

+
+ \ No newline at end of file -- cgit 1.2.3-korg