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.3</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="../">バージョン
20 2.3</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS 暗号化: はじめに</h1>
22 <p><span>言語: </span><a href="../en/ssl/ssl_intro.html" hreflang="en" rel="alternate" title="English"> en </a> |
23 <a href="../fr/ssl/ssl_intro.html" hreflang="fr" rel="alternate" title="Français"> fr </a> |
24 <a href="../ja/ssl/ssl_intro.html" title="Japanese"> ja </a></p>
28 <p>標準規格の良い所は、たくさんの規格から選べるということだ。
29 そして、もし本当にどの規格も気に入らなければ、
30 一年待つだけで探していた規格が現れる。</p>
32 <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
33 Computer Networks"</p>
37 入門ということで、この章は Web、HTTP、Apache に通じている
38 読者向けですが、セキュリティ専門家向けではありません。
39 SSL プロトコルの決定的な手引きであるつもりはありません。
40 また、組織内の認証管理のための特定のテクニックや、
41 特許や輸出規制などの重要な法的な問題についても扱いません。
42 むしろ、更なる研究への出発点として色々な概念、定義、例を並べることで
43 <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> のユーザに基礎知識を提供する事を目的としています。</p>
45 <p>ここに示された内容は主に、原著者の許可の下
46 The Open Group Research Institute の <a href="http://home.earthlink.net/~fjhirsch/">Frederick J. Hirsch</a>
47 氏の記事 <a href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/">
48 Introducing SSL and Certificates using SSLeay</a> を基にしています。
49 氏の記事は <a href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
50 Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997
52 肯定的な意見は <a href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> 氏
53 (元記事の著者) へ全ての苦情は <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (
54 <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> の作者) へお願いします。
55 <span class="transnote">(<em>訳注:</em> 訳については <a href="mailto:apache-docs@ml.apache.or.jp">
56 Apache ドキュメント翻訳プロジェクト</a>
59 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cryptographictech">暗号化技術</a></li>
60 <li><img alt="" src="../images/down.gif" /> <a href="#certificates">証明書</a></li>
61 <li><img alt="" src="../images/down.gif" /> <a href="#ssl">Secure Sockets Layer (SSL)</a></li>
62 <li><img alt="" src="../images/down.gif" /> <a href="#references">参考文献</a></li>
64 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
66 <h2><a name="cryptographictech" id="cryptographictech">暗号化技術</a></h2>
68 <p>SSL を理解するには、暗号アルゴリズム、
69 メッセージダイジェスト関数(別名: 一方向関数、ハッシュ関数)、
72 (例えば [<a href="#AC96">AC96</a>] を参照)、
73 プライバシー、信用、認証などの技術の基礎となっています。</p>
75 <h3><a name="cryptographicalgo" id="cryptographicalgo">暗号アルゴリズム</a></h3>
77 <p>例えば、アリスが送金のために銀行にメッセージを送りたいとします。
79 アリスはそのメッセージを秘密にしたいと思います。
80 解決方法の一つは暗号アルゴリズムを使って、メッセージを
81 復号されるまで読むことができない暗号化された
84 メッセージは秘密の鍵によってのみ復号化することができます。
86 良い暗号アルゴリズムは、侵入者が元のテキストを解読することを
87 非常に難しくするため、努力が割に合わなくさせます。</p>
90 従来型と公開鍵の二つの種類があります。</p>
95 送信者と受信者が鍵を共有することが必要です。
96 鍵とは、メッセージを暗号化したり復号するのに使われる秘密
98 この鍵が秘密になっている限り、送信者と受信者以外は誰もメッセージを読
100 もしも、アリスと銀行が秘密の鍵を知っているなら、
101 彼らはお互いに秘密のメッセージを送ることができるでしょう。
102 ただし交信の前に、事前に内密に鍵を共有するという作業自体は難題かもしれません。</dd>
106 メッセージを暗号化することのできる二つの鍵
107 を使用するアルゴリズムを定義することで鍵のやり取りの問題を解決
111 この方式によって、一つの鍵を公表して(公開鍵)、
112 もう片方を秘密にしておく(秘密鍵)だけで、
113 安全なメッセージを受け取ることができます。</dd>
116 <p>公開鍵を使って誰もがメッセージを暗号化できますが、秘
117 密鍵の持ち主だけがそれを読むことができます。
118 この方法で、銀行の公開鍵を使って暗号化することで、
119 アリスは秘密のメッセージを送ることができます。
120 銀行のみが送られたメッセージを復号することができます。</p>
123 <h3><a name="messagedigests" id="messagedigests">メッセージダイジェスト</a></h3>
125 <p>アリスはメッセージを秘密にすることができますが、
126 誰かが例えば自分に送金するようにメッセージを変更したり、
127 別のものに置き換えてしまうかもしれないという問題があります。
128 アリスのメッセージだという信憑性を保証する方法の一つは、
129 メッセージの簡潔なダイジェストを作って、それも銀行に送るというものです。
130 メッセージを受け取ると銀行側でもダイジェストを作成し、
131 アリスが送ったダイジェストと比べます。もし一致したなら、
132 受け取ったメッセージは無傷だということになります。</p>
134 <p>このような要約は<dfn>メッセージダイジェスト</dfn>、
135 <em>一方行関数</em>、または<em>ハッシュ関数</em>と呼ばれます。
136 メッセージダイジェストは長い可変長のメッセージから
139 一意なダイジェストを生成するように作られています。
140 メッセージダイジェストはダイジェストから元のメッセージを
141 判定するのがとても難しいようにできていて、
142 同じ要約を作成する二つのメッセージを探すのは(理論上)不可能です。
143 これによって、要約を変更することなくメッセージを置き換えられる
146 <p>アリスへのもう一つの問題は、このダイジェストを安全に送る方法を探すことです。
147 ダイジェストが安全に送られればダイジェストの信憑性が保障されて、
148 ダイジェストの信憑性をもってオリジナルメッセージの信憑性を得ることができます。
149 ダイジェストを安全に送った場合にのみ、そのメッセージの
152 <p>ダイジェスト安全に送る方法の一つは、電子署名に含める方法です。</p>
155 <h3><a name="digitalsignatures" id="digitalsignatures">電子署名</a></h3>
156 <p>アリスが銀行にメッセージを送ったとき、
157 侵入者が彼女になりすまして彼女の口座への取引を申請できないように、
158 銀行側ではメッセージが本当に彼女からのものか確実に分かるようにしなければなりません。
159 アリスによって作成されて、メッセージに含まれた
160 <em>電子署名</em>がここで役に立ちます。</p>
162 <p>電子署名はメッセージのダイジェストやその他の情報(処理番号など)を
163 送信者の秘密鍵で暗号化することで作られます。
164 誰もが公開鍵を使って署名を<em>復号</em>することができますが、
166 これは送信者のみが署名しえたことを意味します。
168 その署名がそのメッセージのみに有効であることを意味します。
169 これは、誰もダイジェストを変えて署名をすることができないため、
172 <p>侵入者が署名を傍受して後日に再利用するのを防ぐため
174 これは、アリスがそんなメッセージは送っていないと言う詐欺
176 彼女だけが署名しえたからです。(否認防止)</p>
178 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
179 <div class="section">
180 <h2><a name="certificates" id="certificates">証明書</a></h2>
182 <p>アリスは秘密のメッセージを銀行に送り、
183 署名をして、メッセージの信用を保証することができるおうになりましたが、
184 通信している相手が本当に銀行なのか確かめなくてはいけません。
185 つまり彼女が使おうとしている公開鍵が、銀行の秘密鍵と対になっていて、
186 侵入者の秘密鍵と対になっているわけではないことを
187 確かめなくてはいけないことを意味しています。
188 同様に銀行は、メッセージの署名が本当にアリスの持っている
189 秘密鍵で署名された署名かを確認する必要があります。</p>
191 <p>もし両者に身元を証明し、公開鍵を確認し、また信頼された機関が署名
192 した証明書があれば、両者とも通信相手について正しい相手だと
194 そのような信頼された機関は<em>認証局</em>
195 (Certificate Authority または CA) と呼ばれ、
196 証明書 (certificate) が認証 (authentication) に使われます。</p>
198 <h3><a name="certificatecontents" id="certificatecontents">証明書の内容</a></h3>
200 <p>証明書は公開鍵と個人、サーバ、その他の主体の実在の身元を
202 <a href="#table1">表1</a>に示されるように証明対象の情報は
203 身元証明の情報(識別名)と公開鍵が含まれます。
204 証明書はまた、認証局の身元証明と署名、そして証明書の有効期間を
206 シリアルナンバーなどの認証局の管理上の情報や
207 その他の追加の情報が含まれているかもしれません。</p>
209 <h4><a name="table1" id="table1">表1: 証明書情報</a></h4>
214 <td>識別名、公開鍵</td></tr>
216 <td>識別名、公開鍵</td></tr>
218 <td>開始日、失効日</td></tr>
220 <td>バージョン、シリアルナンバー</td></tr>
222 <td>基本的な制約、ネットスケープフラッグ、その他</td></tr>
226 <p>識別名(ディスティングイッシュ・ネーム)は特定の状況における
227 身分証明を提供するのに使われています。例えば、ある人は
228 私用と会社とで別々の身分証明を持つかもしれません。
230 識別名は X.509 標準規格 [<a href="#X509">X509</a>] で定義されています。
231 X.509 標準規格は、項目、項目名、そして項目の略称を定義しています。(<a href="#table2">表
234 <h4><a name="table2" id="table2">表 2: 識別名情報</a></h4>
236 <table class="bordered">
242 <tr><td>Common Name (コモンネーム)</td>
246 <td>CN=www.example.com</td></tr>
247 <tr><td>Organization or Company (組織名)</td>
250 <td>O=Example Japan K.K.</td></tr>
251 <tr><td>Organizational Unit (部門名)</td>
254 <td>OU=Customer Service</td></tr>
255 <tr><td>City/Locality (市区町村)</td>
258 <td>L=Sapporo</td></tr>
259 <tr><td>State/Province (都道府県)</td>
262 <td>ST=Hokkaido</td></tr>
263 <tr><td>Country(国)</td>
265 <td>所在している国名の ISO コード<br />
272 <p>認証局はどの項目が省略可能でどれが必須かの方針を定義する
273 かもしれません。項目の内容についても認証局や証明書のユーザからの
275 例えばネットスケープのブラウザは、サーバの証明書の
276 Common Name (コモンネーム)がサーバのドメイン名の
277 <code>*.snakeoil.com</code>
278 というようなワイルドカードのパターンにマッチすること
281 <p>バイナリ形式の証明書は ASN.1 表記法
282 [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>] で
284 この表記法は内容をどのように記述するかを定義し、
285 符号化の規定がこの情報がどのようにバイナリ形式に変換されるかを
287 証明書のバイナリ符号化は Distinguished Encoding
288 Rules (DER) で定義され、それはより一般的な Basic Encoding Rules
290 バイナリ形式を扱うことのできない送信では、
291 バイナリ形式は Base64 符号化 [<a href="#MIME">MIME</a>] で
292 ASCII 形式に変換されることがあります。
293 開始デリミタ行と終了デリミタ行で囲まれた、この形式のことを
294 PEM ("Privacy Enhanced Mail") 符号化された証明書と言います。</p>
296 <div class="example"><h3>PEM 符号化された証明書の例 (example.crt)</h3><pre>-----BEGIN CERTIFICATE-----
297 MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
298 FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
299 A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
300 cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
301 bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
302 MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
303 a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
304 cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
305 AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
306 gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
307 vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
308 lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
309 HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
310 gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
311 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
312 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
313 -----END CERTIFICATE-----</pre></div>
316 <h3><a name="certificateauthorities" id="certificateauthorities">認証局</a></h3>
318 <p>証明書を承認する前に、証明書要求に記載されている情報を確認し、
320 例えば、アリスが個人証明書を申請したとすると、
321 認証局はアリスが証明書の申請が主張する通りの
322 当の本人だということを確認しなくてはいけません。</p>
324 <h4><a name="certificatechains" id="certificatechains">証明書の連鎖</a></h4>
326 <p>認証局は他の認証局への証明書を発行することができます。
327 未知の証明書を調べる時に、アリスはその証明書の発行者
329 その上位階層の認証局をたどって調べる必要があります。
331 彼女は限られた連鎖の発行者のみ信頼するように
335 <h4><a name="rootlevelca" id="rootlevelca">最上位認証局の作成</a></h4>
337 <p>前に述べたように、全ての証明書について、
338 最上位の認証局(CA)までそれぞれの発行者が
339 対象の身元証明の有効性を明らかにする必要があります。
340 問題は、誰がその最上位の認証機関の証明書を保証するのか、
342 このような場合に限り、証明書は「自己署名」されます。
343 ブラウザには、とてもよく知られている認証局が初期登録されていますが、
346 最上位認証局が公開鍵を広く公表することで、
347 その鍵を信頼するリスクを低くすることができます。
348 もし、他人がその認証局になりすました時に、それが露見しや
351 <p><a href="http://www.thawte.com/">Thawte</a>
352 や <a href="http://www.verisign.com/">VeriSign</a>
353 のような多くの会社が認証局として開設しました。
354 このような会社は以下のサービスを提供します:</p>
364 個人やサーバの身元証明が簡単に行える組織の
365 イントラネット内では役に立つかもしれません。</p>
368 <h4><a name="certificatemanagement" id="certificatemanagement">証明書管理</a></h4>
370 <p>認証局の開設は徹底した管理、技術、運用の体制を必要とする
374 具体的には、証明書がいつまで有効であり続けるかを決定し、更新し、
376 (Certificate Revocation Lists または CRL)
379 <p>例えばアリスが過去、会社の社員であることを証明する証明書を持っていたが、
380 現在は退職していた際、その証明書は失効されなければなりません。
381 証明書は次々と人に渡されていくものなので、
382 証明書そのものから、それが取り消されたか判断することは
385 認証局に連絡して CRL を照合する必要があります。
386 普通この過程は自動化されているものではありません。</p>
388 <div class="note"><h3>注意</h3>
389 <p>ブラウザに信用できる認証局としてデフォルトで登録されていない
392 ブラウザがその認証局によって署名されたサーバの証明書を
394 一度読み込まれると、その認証局によって署名された全ての
395 証明書を受け入れるため、危険を伴います。</p>
400 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
401 <div class="section">
402 <h2><a name="ssl" id="ssl">Secure Sockets Layer (SSL)</a></h2>
404 <p>Secure Sockets Layer プロトコルは信頼性のあるコネクション型の
405 ネットワーク層のプロトコル(例えば、TCP/IP)と
406 アプリケーション層のプロトコル(例えば、HTTP)
408 SSL は、相互認証によってサーバとクライアント間の安全な通信を、
410 そして暗号化によってプライバシを提供します。</p>
412 <p>SSL プロトコルは暗号化、ダイジェスト、電子署名について、
413 様々なアルゴリズムをサポートするようにできています。
414 こうすることで、法や輸出の規制を考慮に入れて、サーバに合わせた
415 アルゴリズムを選ぶことができ、また、新しいアルゴリズムを
417 アルゴリズムの選択はプロトコルセッション開始時に
418 サーバとクライアント間で取り決められます。</p>
420 <h3><a name="table4" id="table4">表4: SSL プロトコルのバージョン</a></h3>
422 <table class="bordered">
427 <th>ブラウザのサポート</th></tr>
428 <tr><td>SSL v2.0</td>
429 <td>Vendor Standard (Netscape Corp. より) [<a href="#SSL2">SSL2</a>]</td>
430 <td>実装が現存する初めての SSL プロトコル</td>
431 <td>- NS Navigator 1.x/2.x<br />
433 - Lynx/2.8+OpenSSL</td></tr>
434 <tr><td>SSL v3.0</td>
435 <td>Expired Internet Draft (Netscape Corp. より) [<a href="#SSL3">SSL3</a>]</td>
436 <td>特定のセキュリティ攻撃を防ぐための改訂、
437 非RSA 暗号の追加、証明書階層構造のサポート</td>
438 <td>- NS Navigator 2.x/3.x/4.x<br />
439 - MS IE 3.x/4.x<br />
440 - Lynx/2.8+OpenSSL</td></tr>
441 <tr><td>TLS v1.0</td>
442 <td>Proposed Internet Standard (IETF より) [<a href="#TLS1">TLS1</a>]</td>
443 <td>MAC レイヤを HMAC へ更新、ブロック暗号の block
444 padding、メッセージ順序の標準化、警告文の充実などのため
446 <td>- Lynx/2.8+OpenSSL</td></tr>
450 <p><a href="#table4">表4</a>に示されるとおり、SSL プロトコルには
452 表にも書かれているように、SSL 3.0 の利点の一つは
454 この機能によって、サーバは自分の証明書に加えて、
455 発行者の証明書をブラウザに渡すことができます。
457 ブラウザに発行者の証明書が直接登録されていなくても、
459 ブラウザはサーバの証明書を有効化することができます。
460 SSL 3.0 は現在 Internet Engineering Task Force (IETF)
461 によって開発されている Transport Layer Security
462 [<a href="#TLS1">TLS</a>] プロトコル標準規格の基礎となっています。</p>
464 <h3><a name="session" id="session">セッションの確立</a></h3>
466 <p><a href="#figure1">図1</a>で示されるように、
467 セッションの確立はクライアントとサーバ間の
468 ハンドシェークシークエンスによって行なわれます。
469 サーバが証明書を提供するか、クライアントの証明書をリクエストするか
470 というサーバの設定により、このシークエンスは異なるものとなります。
471 暗号情報の管理のために、追加のハンドシェーク過程が必要になる
474 全ての可能性についは、SSL 仕様書を参照してください。</p>
476 <div class="note"><h3>注意</h3>
477 <p>一度 SSL セッションが確立すると、セッションを再利用することで、
478 セッションを開始するための多くの過程を繰り返すという
480 そのため、サーバは全てのセッションに一意なセッション識別名を
481 割り当て、サーバにキャッシュし、クライアントは次回から
482 (識別名がサーバのキャッシュで期限切れになるまでは)
483 ハンドシェークなしで接続することができます。</p>
487 <img src="../images/ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
488 <a id="figure1" name="figure1"><dfn>図1</dfn></a>: SSL
492 ハンドシェークシークエンスの要素を以下に示します:</p>
495 <li>データ通信に使われる暗号スイートの取り決め</li>
496 <li>クライアントとサーバ間でのセッション鍵の確立と共有</li>
497 <li>オプションとして、クライアントに対するサーバの認証</li>
498 <li>オプションとして、サーバに対するクライアントの認証</li>
501 <p>第一ステップの暗号スイート取り決めによって、
504 SSL3.0 プロトコルの仕様書は 31 の暗号スイートを定義しています。
505 暗号スイートは以下のコンポーネントにより定義されています:</p>
510 <li>Message Authentication Code (MAC) 作成のための
514 <p>これらの三つの要素は以下のセクションで説明されています。</p>
517 <h3><a name="keyexchange" id="keyexchange">鍵の交換手段</a></h3>
519 <p>鍵の交換手段はアプリケーションのデータ通信に使われ、
520 共有される対称暗号鍵をどのようにがクライアントとサーバで
522 SSL 2.0 は RSA 鍵交換しか使いませんが、
523 SSL 3.0 は (証明書が使われるときの) RSA 鍵交換や、
524 (証明書無しの場合やクライアントとサーバの事前の通信が無い場合の)
526 など様々な鍵交換アルゴリズムをサポートします。</p>
528 <p>鍵の交換方法における一つの選択肢は電子署名です。
530 どの種類の署名を使うかという選択があります。
531 秘密鍵で署名することで共有鍵を保護し、情報交換する時の
532 マン・イン・ザ・ミドル攻撃を防ぐことができます。
533 [<a href="#AC96">AC96</a>, p516]</p>
536 <h3><a name="ciphertransfer" id="ciphertransfer">データ通信の暗号術</a></h3>
538 <p>SSL はセッションのメッセージの暗号化に前述した
540 暗号化しないという選択肢も含め九つの暗号方式の選択肢があります:</p>
546 <li>40-bit 鍵での RC4</li>
547 <li>128-bit 鍵での RC4</li>
550 <ul><li>40 bit 鍵での RC2</li>
551 <li>40 bit 鍵での DES</li>
552 <li>56 bit 鍵での DES</li>
553 <li>168 bit 鍵での Triple-DES</li>
554 <li>Idea (128 bit 鍵)</li>
555 <li>Fortezza (96 bit 鍵)</li>
559 <p>CBC とは暗号ブロック連鎖 (Cipher Block Chaining)
560 の略で、一つ前の暗号化された暗号文の一部が
561 ブロックの暗号化に使われることを意味します。
562 DES はデータ暗号化標準規格 (Data Encryption Standard)
563 [<a href="#AC96">AC96</a>, ch12] の略で、
564 DES40 や 3DES_EDE を含むいくつもの種類があります。
565 Idea は現在最高なものの一つで、暗号術的には現在ある中で
567 RC2 は RSA DSI による独占的なアルゴリズムです。
568 [<a href="#AC96">AC96</a>,
572 <h3><a name="digestfuntion" id="digestfuntion">ダイジェスト関数</a></h3>
575 ダイジェスト関数の選択はレコードユニットからどのようにダイジェストが生成されるかを決定します。
580 <li>MD5 (128-bit ハッシュ)</li>
581 <li>Secure Hash Algorithm (SHA-1) (160-bit ハッシュ)</li>
584 <p>メッセージダイジェストは Message Authentication Code (MAC)
585 の生成に使われ、メッセージと共に暗号化され、メッセージの信憑性を
589 <h3><a name="handshake" id="handshake">ハンドシェークシークエンスプロトコル</a></h3>
591 <p>ハンドシェークシークエンスは三つのプロトコルを使います:</p>
594 <li><dfn>SSL ハンドシェークプロトコル</dfn>は
595 クライアントとサーバ間での SSL セッションの確立に使われます。</li>
596 <li><dfn>SSL 暗号仕様変更プロトコル</dfn>は
597 セッションでの暗号スイートの取り決めに使われます。</li>
598 <li><dfn>SSL 警告プロトコル</dfn>は
599 クライアントサーバ間で SSL エラーを伝達するのに使われます。</li>
602 <p>三つのプロトコルは、アプリケーションプロトコルデータとともに、
603 <a href="#figure2">図2</a>に示すとおり <dfn>SSL レコードプロトコル</dfn>
605 カプセル化されたプロトコルはデータを検査しない
606 下層のプロトコルによってデータとして伝達されます。
607 カプセル化されたプロトコルは下層のプロトコルに関して一切関知しません。</p>
610 <img src="../images/ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
611 <a id="figure2" name="figure2"><dfn>図2</dfn></a>: SSL プロトコルスタック
615 レコードプロトコルで SSL コントロールプロトコルがカプセル化されているということは、
616 アクティブなセッション上で再ネゴシエーションされたときにも、
617 コントロールプロトコルは安全であることを意味します。
618 既存のセッションが無い場合は、Null 暗号スイートが使われ、
619 暗号化は行なわれず、セッションが確立するまでは
620 ダイジェストも無い状態となります。</p>
623 <h3><a name="datatransfer" id="datatransfer">データ通信</a></h3>
625 <p><a href="#figure3">図3</a>に示される SSL レコードプロトコル
626 はクライアントとサーバ間のアプリケーションや
627 SSL コントロールデータの通信に使われます。
628 必要に応じてこのデータはより小さいユニットに分けられたり、
629 いくつかの高級プロトコルをまとめて一ユニットとして通信が
631 データを圧縮し、ダイジェスト署名を添付して、
632 これらのユニットを暗号化したのち、ベースとなっている
633 信頼性のあるトランスポートプロトコルを用いるかもしれません。
634 (注意: 現在メジャーな SLL 実装で圧縮をサポートしているものはありません)</p>
637 <img src="../images/ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
638 <a id="figure3" name="figure3"><dfn>図 3</dfn></a>: SSL レコードプロトコル
642 <h3><a name="securehttp" id="securehttp">HTTP 通信の安全化</a></h3>
644 <p>よくある SSL の使い方はブラウザとウェブサーバ間の HTTP 通信
646 これは、従来の安全ではない HTTP の使用を除外するものではありません。
647 安全化されたもの (HTTPS と呼ばれます) は、SSL 上での普通の HTTP で、
648 URL スキームに <code>http</code> の代わりに <code>https</code>
649 を用い、サーバで別のポートを使うことです (デフォルトでは443)。
650 これが主に <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> が Apache
653 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
654 <div class="section">
655 <h2><a name="references" id="references">参考文献</a></h2>
658 <dt><a id="AC96" name="AC96">[AC96]</a></dt>
659 <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
660 1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for various other materials by Bruce
663 <dt><a id="X208" name="X208">[X208]</a></dt>
664 <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
665 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>.
668 <dt><a id="X509" name="X509">[X509]</a></dt>
669 <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
670 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>.
673 <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
674 <dd><q>Public Key Cryptography Standards (PKCS)</q>,
675 RSA Laboratories Technical Notes, See <a href="http://www.rsasecurity.com/rsalabs/pkcs/">http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
677 <dt><a id="MIME" name="MIME">[MIME]</a></dt>
678 <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
679 (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
680 See for instance <a href="http://ietf.org/rfc/rfc2045.txt">http://ietf.org/rfc/rfc2045.txt</a>.</dd>
682 <dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
683 <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>
685 <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
686 <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
687 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>
689 <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
690 <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
691 1999. See <a href="http://ietf.org/rfc/rfc2246.txt">http://ietf.org/rfc/rfc2246.txt</a>.</dd>
694 <div class="bottomlang">
695 <p><span>言語: </span><a href="../en/ssl/ssl_intro.html" hreflang="en" rel="alternate" title="English"> en </a> |
696 <a href="../fr/ssl/ssl_intro.html" hreflang="fr" rel="alternate" title="Français"> fr </a> |
697 <a href="../ja/ssl/ssl_intro.html" title="Japanese"> ja </a></p>
698 </div><div id="footer">
699 <p class="apache">Copyright 2011 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>
700 <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>