1 <?xml version="1.0" encoding="UTF-8"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja"><head><!--
4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
5 This file is generated from xml source: DO NOT EDIT
6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
8 <title>SSL/TLS 暗号化: はじめに - Apache HTTP サーバ</title>
9 <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
10 <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
11 <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
12 <link href="../images/favicon.ico" rel="shortcut icon" /></head>
13 <body id="manual-page"><div id="page-header">
14 <p class="menu"><a href="../mod/">モジュール</a> | <a href="../mod/directives.html">ディレクティブ</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">用語</a> | <a href="../sitemap.html">サイトマップ</a></p>
15 <p class="apache">Apache HTTP サーバ バージョン 2.0</p>
16 <img alt="" src="../images/feather.gif" /></div>
17 <div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
19 <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP サーバ</a> > <a href="http://httpd.apache.org/docs/">ドキュメンテーション</a> > <a href="../">バージョン 2.0</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS 暗号化: はじめに</h1>
21 <p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" hreflang="en" rel="alternate" title="English"> en </a> |
22 <a href="../ja/ssl/ssl_intro.html" title="Japanese"> ja </a></p>
26 <p>標準規格の良い所は、たくさんの規格から選べるということだ。
27 そして、もし本当にどの規格も気に入らなければ、
28 一年待つだけで探していた規格が現れる。</p>
30 <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
31 Computer Networks"</p>
35 入門ということで、この章は Web、HTTP、Apache に通じている
36 読者向けですが、セキュリティ専門家向けではありません。
37 SSL プロトコルの決定的な手引きであるつもりはありません。
38 また、組織内の認証管理のための特定のテクニックや、
39 特許や輸出規制などの重要な法的な問題についても扱いません。
40 むしろ、更なる研究への出発点として色々な概念、定義、例を並べることで
41 mod_ssl のユーザに基礎知識を提供する事を目的としています。</p>
43 <p>ここに示された内容は主に、原著者の許可の下
44 The Open Group Research Institute の <a href="http://home.earthlink.net/~fjhirsch/">Frederick J. Hirsch</a>
45 氏の記事 <a href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/article.html">
46 Introducing SSL and Certificates using SSLeay</a> を基にしています。
47 氏の記事は <a href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
48 Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997
50 肯定的な意見は <a href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> 氏
51 (元記事の著者) へ全ての苦情は <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (
52 <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> の作者) へお願いします。
53 [訳注: 訳については <a href="mailto:apache-docs@ml.apache.or.jp">
54 Apache ドキュメント翻訳プロジェクト</a>
57 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cryptographictech">暗号化技術</a></li>
58 <li><img alt="" src="../images/down.gif" /> <a href="#certificates">証明書</a></li>
59 <li><img alt="" src="../images/down.gif" /> <a href="#ssl">Secure Sockets Layer (SSL)</a></li>
60 <li><img alt="" src="../images/down.gif" /> <a href="#references">参考文献</a></li>
62 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
64 <h2><a name="cryptographictech" id="cryptographictech">暗号化技術</a></h2>
66 <p>SSL を理解するには、暗号アルゴリズム、
67 メッセージダイジェスト関数(別名: 一方向関数、ハッシュ関数)、
70 (例えば [<a href="#AC96">AC96</a>] を参照)、
71 プライバシー、信用、認証などの技術の基礎となっています。</p>
73 <h3><a name="cryptographicalgo" id="cryptographicalgo">暗号アルゴリズム</a></h3>
75 <p>例えば、アリスが送金のために銀行にメッセージを送りたいとします。
77 アリスはそのメッセージを秘密にしたいと思います。
78 解決方法の一つは暗号アルゴリズムを使って、メッセージを
79 読ませたい人以外は読むことができない暗号化された
82 メッセージは秘密の鍵によってのみ解釈することができます。
84 良い暗号アルゴリズムは、侵入者が元のテキストを解読することを
85 非常に難しくするため、努力が割に合わなくさせます。</p>
88 従来型と公開鍵の二つの種類があります。</p>
93 送信者と受信者が鍵を共有することが必要です。
94 鍵とは、メッセージを暗号化したり復号するのに使われる秘密
96 もし、この鍵が秘密なら、送信者と受信者以外は誰もメッセージを読
98 もしも、アリスと銀行が秘密の鍵を知っているなら、
99 彼らはお互いに秘密のメッセージを送ることができるでしょう。
100 ただし、事前に内密に鍵を選ぶという仕事は問題を含んでいます。</dd>
104 メッセージを暗号化することのできる二つの鍵
105 を使用するアルゴリズムを定義することで鍵のやり取りの問題を解決
109 この方式によって、一つの鍵を公表して(公開鍵)、
110 もう片方を秘密にしておく(秘密鍵)だけで、
111 安全なメッセージを受け取ることができます。</dd>
114 <p>誰もが暗号化されたメッセージを公開鍵によって暗号化
115 することができますが、秘密鍵の持ち主だけがそれを読むことが
117 この方法で、銀行の公開鍵を使って暗号化することで、
118 アリスは秘密のメッセージを送ることができます。
119 銀行のみが復号することができます。</p>
122 <h3><a name="messagedigests" id="messagedigests">メッセージダイジェスト</a></h3>
124 <p>アリスはメッセージを秘密にすることができますが、
125 誰かが例えば自分に送金するようにメッセージを変更したり、
126 別のものに置き換えてしまうかもしれないという問題があります。
127 アリスのメッセージの信用を保証する方法の一つは、
128 メッセージの簡潔なダイジェストを作って、それも銀行に送るというものです。
129 メッセージを受け取ると銀行もダイジェストを作成し、
130 アリスが送ったものと比べます。もし一致したなら、
131 受け取ったメッセージは無傷だということになります。</p>
133 <p>このような要約は<dfn>メッセージダイジェスト</dfn>、
134 <em>一方行関数</em>、または<em>ハッシュ関数</em>と呼ばれます。
135 メッセージダイジェストは長い可変長のメッセージから
138 一意なダイジェストを生成するように作られています。
139 メッセージダイジェストはダイジェストから元のメッセージを
140 判定するのがとても難しいようにできています。
141 また、同じ要約を作成する二つのメッセージを探すのは不可能です。
142 よって、同じ要約を使ってメッセージを置き換えるという
145 <p>アリスへのもう一つの問題は、このダイジェストを安全に送る方法を探すことです。
146 これができれば、メッセージの信用が保証されます。
147 一つの方法はこのダイジェストに電子署名を含むことです。</p>
150 <h3><a name="digitalsignatures" id="digitalsignatures">電子署名</a></h3>
151 <p>アリスが銀行にメッセージを送ったとき、銀行は、
152 侵入者が彼女になりすまして彼女の口座への取引を申請していないか、
153 メッセージが本当に彼女からのものか確実に分からなければいけません。
154 アリスによって作成され、メッセージに含まれた
155 <em>電子署名</em>がここで役に立ちます。</p>
157 <p>電子署名はメッセージのダイジェストやその他の情報(処理番号など)を
158 送信者の秘密鍵で暗号化することで作られます。
159 誰もが公開鍵を使って署名を<em>復号</em>することができますが、
161 これは、彼らのみが署名しえたことを意味します。
163 その署名がそのメッセージのみに有効であることを意味します。
164 これは、誰もダイジェストを変えて署名をすることができないため、
167 <p>侵入者が署名を傍受して後日に再利用するのを防ぐため
169 これは、アリスがそんなメッセージは送っていないと言う詐欺
171 彼女だけが署名しえたからです。(否認防止)</p>
173 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
174 <div class="section">
175 <h2><a name="certificates" id="certificates">証明書</a></h2>
177 <p>アリスは秘密のメッセージを銀行に送り、
178 署名をして、メッセージの信用を保証することができるおうになりましたが、
179 通信している相手が本当に銀行なのか確かめなくてはいけません。
180 これは、彼女が使う公開鍵が銀行の秘密鍵と対になっているものか、
181 彼女は確かめなくてはいけないということを意味します。
182 同様に、銀行はメッセージの署名が本当にアリスの署名か確認する必要が
185 <p>もし両者に身元を証明し、公開鍵を確認し、また信頼された機関が署名
186 した証明書があれば、両者とも通信相手について正しい相手だと
188 そのような信頼された機関は<em>認証局</em>
189 (Certificate Authority または CA) と呼ばれ、
190 証明書 (certificate) が認証 (authentication) に使われます。</p>
192 <h3><a name="certificatecontents" id="certificatecontents">証明書の内容</a></h3>
194 <p>証明書は公開鍵と個人、サーバ、その他の主体の実在の身元を
196 <a href="#table1">表1</a>に示されるように証明対象の情報は
197 身元証明の情報(識別名)と公開鍵が含まれます。
198 証明書はまた、認証局の身元証明と署名、そして証明書の有効期間を
200 シリアルナンバーなどの認証局の管理上の情報や
201 その他の追加の情報が含まれているかもしれません。</p>
203 <h4><a name="table1" id="table1">表1: 証明書情報</a></h4>
208 <td>識別名、公開鍵</td></tr>
210 <td>識別名、公開鍵</td></tr>
212 <td>開始日、失効日</td></tr>
214 <td>バージョン、シリアルナンバー</td></tr>
216 <td>基本的な制約、ネットスケープフラッグ、その他</td></tr>
220 <p>識別名(ディスティングイッシュ・ネーム)は特定の状況における
221 身分証明を提供するのに使われています。例えば、ある人は
222 私用と会社とで別々の身分証明を持つかもしれません。
224 識別名は X.509 標準規格 [<a href="#X509">X509</a>] で定義されています。
225 X.509 標準規格は、項目、項目名、そして項目の略称を定義しています。(<a href="#table2">表
228 <h4><a name="table2" id="table2">表 2: 識別名情報</a></h4>
230 <table class="bordered">
236 <tr><td>Common Name (コモンネーム)</td>
240 <td>CN=www.example.com</td></tr>
241 <tr><td>Organization or Company (組織名)</td>
244 <td>O=Example Japan K.K.</td></tr>
245 <tr><td>Organizational Unit (部門名)</td>
248 <td>OU=Customer Service</td></tr>
249 <tr><td>City/Locality (市区町村)</td>
252 <td>L=Sapporo</td></tr>
253 <tr><td>State/Province (都道府県)</td>
256 <td>ST=Hokkaido</td></tr>
257 <tr><td>Country(国)</td>
259 <td>所在している国名の ISO コード<br />
266 <p>認証局はどの項目が省略可能でどれが必須かの方針を定義する
267 かもしれません。項目の内容についても認証局や証明書のユーザからの
269 例えば、ネットスケープのブラウザはサーバの証明書の
270 Common Name (コモンネーム)がサーバのドメイン名の
271 <code>*.example.com</code>
272 というようなワイルドカードのパターンにマッチすること
275 <p>バイナリ形式の証明書は ASN.1 表記法
276 [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>] で
278 この表記法は内容をどのように記述するかを定義し、
279 符号化の規定がこの情報がどのようにバイナリ形式に変換されるかを
281 証明書のバイナリ符号化は Distinguished Encoding
282 Rules (DER) で定義され、それはより一般的な Basic Encoding Rules
284 バイナリ形式を扱うことのできない送信では、
285 バイナリ形式は Base64 符号化 [<a href="#MIME">MIME</a>] で
286 ASCII 形式に変換されることがあります。
287 このように符号化され、以下の例に示されるように区切り行に
288 挟まれたものは PEM 符号化されたと言います。
289 (PEM の名前は "Privacy Enhanced Mail" に由来します)</p>
291 <div class="example"><h3>PEM 符号化された証明書の例 (example.crt)</h3><pre>-----BEGIN CERTIFICATE-----
292 MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
293 FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
294 A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
295 cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
296 bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
297 MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
298 a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
299 cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
300 AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
301 gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
302 vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
303 lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
304 HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
305 gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
306 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
307 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
308 -----END CERTIFICATE-----</pre></div>
311 <h3><a name="certificateauthorities" id="certificateauthorities">認証局</a></h3>
313 <p>まず証明書の申請の情報を確認することで、
314 認証局は秘密鍵の持ち主の身元を保証します。
315 例えば、アリスが個人証明書を申請したとすると、
316 認証局はアリスが証明書の申請が主張する通りの
317 人物だということを確認しなくてはいけません。</p>
319 <h4><a name="certificatechains" id="certificatechains">証明書階層構造</a></h4>
321 <p>認証局は他の認証局への証明書を発行することができます。
322 未知の証明書を調べる時に、アリスはその証明書の発行者
324 その上位階層の認証局をたどって調べる必要があります。
326 彼女は限られた連鎖の発行者のみ信頼するように
330 <h4><a name="rootlevelca" id="rootlevelca">最上位認証局の作成</a></h4>
332 <p>前に述べたように、全ての証明書について、
333 最上位の認証局(CA)までそれぞれの発行者が
334 対象の身元証明の有効性を明らかにする必要があります。
335 問題は、誰がその最上位の認証機関の証明書を保証するのか、
337 このような場合に限り、証明書は「自己署名」されます。
338 つまり、証明書の発行者と証明対象が同じということになります。
339 その結果、自己署名された証明書を信用するには
341 最上位認証局が公開鍵を広く公表することで、
342 その鍵を信頼するリスクを低くすることができます。
343 もし、他人がその認証局になりすました時に、それが露見しや
345 多くのブラウザは有名な認証局を信頼するように
348 <p><a href="http://www.thawte.com/">Thawte</a>
349 や <a href="http://www.verisign.com/">VeriSign</a>
350 のような多くの会社が認証局として開設しました。
351 このような会社は以下のサービスを提供します:</p>
361 個人やサーバの身元証明が簡単に行える組織の
362 イントラネット内では役に立つかもしれません。</p>
365 <h4><a name="certificatemanagement" id="certificatemanagement">証明書管理</a></h4>
367 <p>認証局の開設は徹底した管理、技術、運用の体制を必要とする
371 具体的には、証明書がいつまで有効かを決定し、更新し、
372 また既に発行されたが失効した証明書のリスト
373 (Certificate Revocation Lists または CRL)
375 例えば、アリスが会社から社員として証明書を与えられたとします。
376 そして、アリスが会社を辞めるときには証明書を取り消さなければ
378 証明書は次々と人に渡されていくものなので、
379 証明書そのものから、それが取り消されたか判断することは
382 認証局に連絡して CRL を照合する必要があります。
383 普通この過程は自動化されているものではありません。</p>
385 <div class="note"><h3>注意</h3>
386 <p>デフォルトでブラウザに設定されていない認証局を使った場合、
388 ブラウザがその認証局によって署名されたサーバの証明書を
390 一度読み込まれると、その認証局によって署名された全ての
391 証明書を受け入れるため、危険を伴います。</p>
396 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
397 <div class="section">
398 <h2><a name="ssl" id="ssl">Secure Sockets Layer (SSL)</a></h2>
400 <p>Secure Sockets Layer プロトコルは信頼性のあるコネクション型の
401 ネットワーク層のプロトコル(例えば、TCP/IP)と
402 アプリケーション層のプロトコル(例えば、HTTP)
404 SSL は、相互認証によってサーバとクライアント間の安全な通信を、
406 そして暗号化によってプライバシを提供します。</p>
408 <p>SSL プロトコルは暗号化、ダイジェスト、電子署名について、
409 様々なアルゴリズムをサポートするようにできています。
410 こうすることで、法や輸出の規制を考慮に入れて、サーバに合わせた
411 アルゴリズムを選ぶことができ、また、新しいアルゴリズムを
413 アルゴリズムの選択はプロトコルセッション開始時に
414 サーバとクライアント間で取り決められます。</p>
416 <h3><a name="table4" id="table4">表4: SSL プロトコルのバージョン</a></h3>
418 <table class="bordered">
423 <th>ブラウザのサポート</th></tr>
424 <tr><td>SSL v2.0</td>
425 <td>Vendor Standard (Netscape Corp. より) [<a href="#SSL2">SSL2</a>]</td>
426 <td>実装が現存する初めての SSL プロトコル</td>
427 <td>- NS Navigator 1.x/2.x<br />
429 - Lynx/2.8+OpenSSL</td></tr>
430 <tr><td>SSL v3.0</td>
431 <td>Expired Internet Draft (Netscape Corp. より) [<a href="#SSL3">SSL3</a>]</td>
432 <td>特定のセキュリティ攻撃を防ぐための改訂、
433 非RSA 暗号の追加、証明書階層構造のサポート</td>
434 <td>- NS Navigator 2.x/3.x/4.x<br />
435 - MS IE 3.x/4.x<br />
436 - Lynx/2.8+OpenSSL</td></tr>
437 <tr><td>TLS v1.0</td>
438 <td>Proposed Internet Standard (IETF より) [<a href="#TLS1">TLS1</a>]</td>
439 <td>MAC レイヤを HMAC へ更新、ブロック暗号の block
440 padding、メッセージ順序の標準化、警告文の充実などのため
442 <td>- Lynx/2.8+OpenSSL</td></tr>
446 <p><a href="#table4">表4</a>に示されるとおり、SSL プロトコルには
448 表にも書かれているように、SSL 3.0 の利点の一つは
450 この機能によって、サーバは自分の証明書に加えて、
451 発行者の証明書をブラウザに渡すことができます。
453 ブラウザに発行者の証明書が直接登録されていなくても、
455 ブラウザはサーバの証明書を有効化することができます。
456 SSL 3.0 は現在 Internet Engineering Task Force (IETF)
457 によって開発されている Transport Layer Security
458 [<a href="#TLS1">TLS</a>] プロトコル標準規格の基礎となっています。</p>
460 <h3><a name="session" id="session">セッションの確立</a></h3>
462 <p><a href="#figure1">図1</a>で示されるように、
463 セッションの確立はクライアントとサーバ間の
464 ハンドシェークシークエンスによって行なわれます。
465 サーバが証明書を提供するか、クライアントの証明書をリクエストするか
466 というサーバの設定により、このシークエンスは異なるものとなります。
467 暗号情報の管理のために、追加のハンドシェーク過程が必要になる
470 全ての可能性についは、SSL 仕様書を参照してください。</p>
472 <div class="note"><h3>注意</h3>
473 <p>一度 SSL セッションが確立すると、セッションを再利用することで、
474 セッションを開始するための多くの過程を繰り返すという
476 そのため、サーバは全てのセッションに一意なセッション識別名を
477 割り当て、サーバにキャッシュし、クライアントは次回から
478 (識別名がサーバのキャッシュで期限切れになるまでは)
479 ハンドシェークなしで接続することができます。</p>
483 <img src="../images/ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
484 <a id="figure1" name="figure1"><dfn>図1</dfn></a>: SSL
488 ハンドシェークシークエンスの要素を以下に示します:</p>
491 <li>データ通信に使われる暗号スイートの取り決め</li>
492 <li>クライアントとサーバ間でのセッション鍵の確立と共有</li>
493 <li>オプションとして、クライアントに対するサーバの認証</li>
494 <li>オプションとして、サーバに対するクライアントの認証</li>
497 <p>第一ステップの暗号スイート取り決めによって、
500 SSL3.0 プロトコルの仕様書は 31 の暗号スイートを定義しています。
501 暗号スイートは以下のコンポーネントにより定義されています:</p>
506 <li>Message Authentication Code (MAC) 作成のための
510 <p>これらの三つの要素は以下のセクションで説明されています。</p>
513 <h3><a name="keyexchange" id="keyexchange">鍵の交換手段</a></h3>
515 <p>鍵の交換手段はアプリケーションのデータ通信に使われ、
516 共有される対称暗号鍵をどのようにがクライアントとサーバで
518 SSL 2.0 は RSA 鍵交換しか使いませんが、
519 SSL 3.0 は証明書が使われるときは RSA 鍵交換を使い、
520 証明書が無く、クライアントとサーバの事前の通信が無い場合は
521 Diffie-Hellman 鍵交換を使う
522 など様々な鍵交換アルゴリズムをサポートします。</p>
524 <p>鍵の交換方法における一つの選択肢は電子署名です。
526 どの種類の署名を使うかという選択があります。
527 秘密鍵で署名することで共有鍵を生成すし、情報交換する時の
528 マン・イン・ザ・ミドル攻撃を防ぐことができます。
529 [<a href="#AC96">AC96</a>, p516]</p>
532 <h3><a name="ciphertransfer" id="ciphertransfer">データ通信の暗号術</a></h3>
534 <p>SSL はセッションのメッセージの暗号化に前述した
536 暗号化しないという選択肢も含め九つの選択肢があります:</p>
542 <li>40-bit 鍵での RC4</li>
543 <li>128-bit 鍵での RC4</li>
546 <ul><li>40 bit 鍵での RC2</li>
547 <li>40 bit 鍵での DES</li>
548 <li>56 bit 鍵での DES</li>
549 <li>168 bit 鍵での Triple-DES</li>
550 <li>Idea (128 bit 鍵)</li>
551 <li>Fortezza (96 bit 鍵)</li>
555 <p>ここでの CBC とは暗号ブロック連鎖 (Cipher Block Chaining)
556 の略で、一つ前の暗号化された暗号文の一部が
557 ブロックの暗号化に使われることを意味します。
558 DES はデータ暗号化標準規格 (Data Encryption Standard)
559 [<a href="#AC96">AC96</a>, ch12] の略で、
560 DES40 や 3DES_EDE を含むいくつもの種類があります。
561 Idea は最高なものの一つで、暗号術的には現在ある中で
563 RC2 は RSA DSI による独占的なアルゴリズムです。
564 [<a href="#AC96">AC96</a>,
568 <h3><a name="digestfuntion" id="digestfuntion">ダイジェスト関数</a></h3>
571 ダイジェスト関数の選択はレコードユニットからどのようにダイジェストが生成されるかを決定します。
576 <li>MD5 (128-bit ハッシュ)</li>
577 <li>Secure Hash Algorithm (SHA-1) (160-bit ハッシュ)</li>
580 <p>メッセージダイジェストは Message Authentication Code (MAC)
581 の生成に使われ、メッセージと共に暗号化され、メッセージの信用を
585 <h3><a name="handshake" id="handshake">ハンドシェークシークエンスプロトコル</a></h3>
587 <p>ハンドシェークシークエンスは三つのプロトコルを使います:</p>
590 <li><dfn>SSL ハンドシェークプロトコル</dfn>は
591 クライアントとサーバ間での SSL セッションの確立に使われます。</li>
592 <li><dfn>SSL 暗号仕様変更プロトコル</dfn>は
593 セッションでの暗号スイートの取り決めに使われます。</li>
594 <li><dfn>SSL 警告プロトコル</dfn>は
595 クライアントサーバ間で SSL エラーを伝達するのに使われます。</li>
598 <p>三つのプロトコルは、アプリケーションプロトコルデータとともに、
599 <a href="#figure2">図2</a>に示すとおり <dfn>SSL レコードプロトコル</dfn>
601 カプセル化されたプロトコルはデータを検査しない
602 下層のプロトコルによってデータとして伝達されます。
603 カプセル化されたプロトコルは下層のプロトコルに関して一切関知しません。</p>
606 <img src="../images/ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
607 <a id="figure2" name="figure2"><dfn>図2</dfn></a>: SSL プロトコルスタック
611 レコードプロトコルによる SSL コントロールプロトコルのカプセル化は、
612 アクティブなセッションの二回目の通信があった場合、
613 コントロールプロトコルが安全であることを意味します。
614 既にセッションが無い場合は、Null 暗号スイートが使われ、
615 暗号化は行なわれず、セッションが確立するまでは
616 ダイジェストも無い状態となります。</p>
619 <h3><a name="datatransfer" id="datatransfer">データ通信</a></h3>
621 <p><a href="#figure3">図3</a>に示される SSL レコードプロトコル
622 はクライアントとサーバ間のアプリケーションや
623 SSL コントロールデータの通信に使われます。
624 このデータはより小さいユニットに分けられたり、
625 いくつかの高級プロトコルをまとめて一ユニットとして通信が
627 データを圧縮し、ダイジェスト署名を添付して、
628 これらのユニットを暗号化したのち、ベースとなっている
629 信頼性のあるトランスポートプロトコルを用いるかもしれません。
630 (注意: 現在メジャーな SLL 実装で圧縮をサポートしているものはありません)</p>
633 <img src="../images/ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
634 <a id="figure3" name="figure3"><dfn>図 3</dfn></a>: SSL レコードプロトコル
638 <h3><a name="securehttp" id="securehttp">HTTP 通信の安全化</a></h3>
640 <p>よくある SSL の使い方はブラウザとウェブサーバ間の HTTP 通信
642 これは、従来の安全ではない HTTP の使用を除外するものではありません。
643 安全化されたものは主に SSH 上の普通の HTTP で、HTTPS と呼ばれます。
644 大きな違いは、URL スキームに <code>http</code> の代わりに <code>https</code>
645 を用い、サーバが別のポートを使うことです (デフォルトでは443)。
646 これが主に <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> が Apache ウェブサーバに提供する機能です。</p>
648 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
649 <div class="section">
650 <h2><a name="references" id="references">参考文献</a></h2>
653 <dt><a id="AC96" name="AC96">[AC96]</a></dt>
654 <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
655 1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for various other materials by Bruce
658 <dt><a id="X208" name="X208">[X208]</a></dt>
659 <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
660 One (ASN.1)</q>, 1988. See for instance <a href="http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I">http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I</a>.
663 <dt><a id="X509" name="X509">[X509]</a></dt>
664 <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
665 Framework</q>. See for instance <a href="http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509">http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509</a>.
668 <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
669 <dd><q>Public Key Cryptography Standards (PKCS)</q>,
670 RSA Laboratories Technical Notes, See <a href="http://www.rsasecurity.com/rsalabs/pkcs/">http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
672 <dt><a id="MIME" name="MIME">[MIME]</a></dt>
673 <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
674 (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
675 See for instance <a href="http://ietf.org/rfc/rfc2045.txt">http://ietf.org/rfc/rfc2045.txt</a>.</dd>
677 <dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
678 <dd>Kipp E.B. Hickman, <q>The SSL Protocol</q>, 1995. See <a href="http://www.netscape.com/eng/security/SSL_2.html">http://www.netscape.com/eng/security/SSL_2.html</a>.</dd>
680 <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
681 <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
682 Version 3.0</q>, 1996. See <a href="http://www.netscape.com/eng/ssl3/draft302.txt">http://www.netscape.com/eng/ssl3/draft302.txt</a>.</dd>
684 <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
685 <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
686 1999. See <a href="http://ietf.org/rfc/rfc2246.txt">http://ietf.org/rfc/rfc2246.txt</a>.</dd>
689 <div class="bottomlang">
690 <p><span>Available Languages: </span><a href="../en/ssl/ssl_intro.html" hreflang="en" rel="alternate" title="English"> en </a> |
691 <a href="../ja/ssl/ssl_intro.html" title="Japanese"> ja </a></p>
692 </div><div id="footer">
693 <p class="apache">Copyright 2009 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
694 <p class="menu"><a href="../mod/">モジュール</a> | <a href="../mod/directives.html">ディレクティブ</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">用語</a> | <a href="../sitemap.html">サイトマップ</a></p></div>