1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
4 <!-- English Revision: 659902:1655141 (outdated) -->
7 Licensed to the Apache Software Foundation (ASF) under one or more
8 contributor license agreements. See the NOTICE file distributed with
9 this work for additional information regarding copyright ownership.
10 The ASF licenses this file to You under the Apache License, Version 2.0
11 (the "License"); you may not use this file except in compliance with
12 the License. You may obtain a copy of the License at
14 http://www.apache.org/licenses/LICENSE-2.0
16 Unless required by applicable law or agreed to in writing, software
17 distributed under the License is distributed on an "AS IS" BASIS,
18 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
19 See the License for the specific language governing permissions and
20 limitations under the License.
23 <manualpage metafile="ssl_intro.xml.meta">
24 <parentdocument href="./">SSL/TLS</parentdocument>
26 <title>SSL/TLS 暗号化: はじめに</title>
30 <p>標準規格の良い所は、たくさんの規格から選べるということだ。
31 そして、もし本当にどの規格も気に入らなければ、
32 一年待つだけで探していた規格が現れる。</p>
34 <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
35 Computer Networks"</p>
39 入門ということで、この章は Web、HTTP、Apache に通じている
40 読者向けですが、セキュリティ専門家向けではありません。
41 SSL プロトコルの決定的な手引きであるつもりはありません。
42 また、組織内の認証管理のための特定のテクニックや、
43 特許や輸出規制などの重要な法的な問題についても扱いません。
44 むしろ、更なる研究への出発点として色々な概念、定義、例を並べることで
45 <module>mod_ssl</module> のユーザに基礎知識を提供する事を目的としています。</p>
47 <p>ここに示された内容は主に、原著者の許可の下
48 The Open Group Research Institute の <a
49 href="http://home.earthlink.net/~fjhirsch/">Frederick J. Hirsch</a>
51 href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/">
52 Introducing SSL and Certificates using SSLeay</a> を基にしています。
54 href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
55 Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997
58 href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> 氏
60 href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (
61 <module>mod_ssl</module> の作者) へお願いします。
63 href="mailto:apache-docs@ml.apache.or.jp">
64 Apache ドキュメント翻訳プロジェクト</a>
65 へお願いします。</transnote></p>
68 <section id="cryptographictech">
70 <p>SSL を理解するには、暗号アルゴリズム、
71 メッセージダイジェスト関数(別名: 一方向関数、ハッシュ関数)、
74 (例えば [<a href="#AC96">AC96</a>] を参照)、
75 プライバシー、信用、認証などの技術の基礎となっています。</p>
77 <section id="cryptographicalgo">
78 <title>暗号アルゴリズム</title>
79 <p>例えば、アリスが送金のために銀行にメッセージを送りたいとします。
81 アリスはそのメッセージを秘密にしたいと思います。
82 解決方法の一つは暗号アルゴリズムを使って、メッセージを
83 復号されるまで読むことができない暗号化された
86 メッセージは秘密の鍵によってのみ復号化することができます。
88 良い暗号アルゴリズムは、侵入者が元のテキストを解読することを
89 非常に難しくするため、努力が割に合わなくさせます。</p>
92 従来型と公開鍵の二つの種類があります。</p>
97 送信者と受信者が鍵を共有することが必要です。
98 鍵とは、メッセージを暗号化したり復号するのに使われる秘密
100 この鍵が秘密になっている限り、送信者と受信者以外は誰もメッセージを読
102 もしも、アリスと銀行が秘密の鍵を知っているなら、
103 彼らはお互いに秘密のメッセージを送ることができるでしょう。
104 ただし交信の前に、事前に内密に鍵を共有するという作業自体は難題かもしれません。</dd>
108 メッセージを暗号化することのできる二つの鍵
109 を使用するアルゴリズムを定義することで鍵のやり取りの問題を解決
113 この方式によって、一つの鍵を公表して(公開鍵)、
114 もう片方を秘密にしておく(秘密鍵)だけで、
115 安全なメッセージを受け取ることができます。</dd>
118 <p>公開鍵を使って誰もがメッセージを暗号化できますが、秘
119 密鍵の持ち主だけがそれを読むことができます。
120 この方法で、銀行の公開鍵を使って暗号化することで、
121 アリスは秘密のメッセージを送ることができます。
122 銀行のみが送られたメッセージを復号することができます。</p>
125 <section id="messagedigests">
126 <title>メッセージダイジェスト</title>
127 <p>アリスはメッセージを秘密にすることができますが、
128 誰かが例えば自分に送金するようにメッセージを変更したり、
129 別のものに置き換えてしまうかもしれないという問題があります。
130 アリスのメッセージだという信憑性を保証する方法の一つは、
131 メッセージの簡潔なダイジェストを作って、それも銀行に送るというものです。
132 メッセージを受け取ると銀行側でもダイジェストを作成し、
133 アリスが送ったダイジェストと比べます。もし一致したなら、
134 受け取ったメッセージは無傷だということになります。</p>
136 <p>このような要約は<dfn>メッセージダイジェスト</dfn>、
137 <em>一方行関数</em>、または<em>ハッシュ関数</em>と呼ばれます。
138 メッセージダイジェストは長い可変長のメッセージから
141 一意なダイジェストを生成するように作られています。
142 メッセージダイジェストはダイジェストから元のメッセージを
143 判定するのがとても難しいようにできていて、
144 同じ要約を作成する二つのメッセージを探すのは(理論上)不可能です。
145 これによって、要約を変更することなくメッセージを置き換えられる
148 <p>アリスへのもう一つの問題は、このダイジェストを安全に送る方法を探すことです。
149 ダイジェストが安全に送られればダイジェストの信憑性が保障されて、
150 ダイジェストの信憑性をもってオリジナルメッセージの信憑性を得ることができます。
151 ダイジェストを安全に送った場合にのみ、そのメッセージの
154 <p>ダイジェスト安全に送る方法の一つは、電子署名に含める方法です。</p>
157 <section id="digitalsignatures"><title>電子署名</title>
158 <p>アリスが銀行にメッセージを送ったとき、
159 侵入者が彼女になりすまして彼女の口座への取引を申請できないように、
160 銀行側ではメッセージが本当に彼女からのものか確実に分かるようにしなければなりません。
161 アリスによって作成されて、メッセージに含まれた
162 <em>電子署名</em>がここで役に立ちます。</p>
164 <p>電子署名はメッセージのダイジェストやその他の情報(処理番号など)を
165 送信者の秘密鍵で暗号化することで作られます。
166 誰もが公開鍵を使って署名を<em>復号</em>することができますが、
168 これは送信者のみが署名しえたことを意味します。
170 その署名がそのメッセージのみに有効であることを意味します。
171 これは、誰もダイジェストを変えて署名をすることができないため、
174 <p>侵入者が署名を傍受して後日に再利用するのを防ぐため
176 これは、アリスがそんなメッセージは送っていないと言う詐欺
178 彼女だけが署名しえたからです。(否認防止)</p>
181 <!-- /cryptographictech -->
183 <section id="certificates">
185 <p>アリスは秘密のメッセージを銀行に送り、
186 署名をして、メッセージの信用を保証することができるおうになりましたが、
187 通信している相手が本当に銀行なのか確かめなくてはいけません。
188 つまり彼女が使おうとしている公開鍵が、銀行の秘密鍵と対になっていて、
189 侵入者の秘密鍵と対になっているわけではないことを
190 確かめなくてはいけないことを意味しています。
191 同様に銀行は、メッセージの署名が本当にアリスの持っている
192 秘密鍵で署名された署名かを確認する必要があります。</p>
194 <p>もし両者に身元を証明し、公開鍵を確認し、また信頼された機関が署名
195 した証明書があれば、両者とも通信相手について正しい相手だと
197 そのような信頼された機関は<em>認証局</em>
198 (Certificate Authority または CA) と呼ばれ、
199 証明書 (certificate) が認証 (authentication) に使われます。</p>
201 <section id="certificatecontents">
202 <title>証明書の内容</title>
203 <p>証明書は公開鍵と個人、サーバ、その他の主体の実在の身元を
205 <a href="#table1">表1</a>に示されるように証明対象の情報は
206 身元証明の情報(識別名)と公開鍵が含まれます。
207 証明書はまた、認証局の身元証明と署名、そして証明書の有効期間を
209 シリアルナンバーなどの認証局の管理上の情報や
210 その他の追加の情報が含まれているかもしれません。</p>
212 <section id="table1">
213 <title>表1: 証明書情報</title>
215 <columnspec><column width=".35"/><column width=".35"/>
218 <td>識別名、公開鍵</td></tr>
220 <td>識別名、公開鍵</td></tr>
222 <td>開始日、失効日</td></tr>
224 <td>バージョン、シリアルナンバー</td></tr>
226 <td>基本的な制約、ネットスケープフラッグ、その他</td></tr>
230 <p>識別名(ディスティングイッシュ・ネーム)は特定の状況における
231 身分証明を提供するのに使われています。例えば、ある人は
232 私用と会社とで別々の身分証明を持つかもしれません。
235 href="#X509">X509</a>] で定義されています。
236 X.509 標準規格は、項目、項目名、そして項目の略称を定義しています。(<a href="#table2">表
239 <section id="table2">
240 <title>表 2: 識別名情報</title>
242 <columnspec><column width=".25"/><column width=".15"/>
243 <column width=".3"/><column width=".25"/></columnspec>
248 <tr><td>Common Name (コモンネーム)</td>
252 <td>CN=www.example.com</td></tr>
253 <tr><td>Organization or Company (組織名)</td>
256 <td>O=Example Japan K.K.</td></tr>
257 <tr><td>Organizational Unit (部門名)</td>
260 <td>OU=Customer Service</td></tr>
261 <tr><td>City/Locality (市区町村)</td>
264 <td>L=Sapporo</td></tr>
265 <tr><td>State/Province (都道府県)</td>
268 <td>ST=Hokkaido</td></tr>
269 <tr><td>Country(国)</td>
271 <td>所在している国名の ISO コード<br />
278 <p>認証局はどの項目が省略可能でどれが必須かの方針を定義する
279 かもしれません。項目の内容についても認証局や証明書のユーザからの
281 例えばネットスケープのブラウザは、サーバの証明書の
282 Common Name (コモンネーム)がサーバのドメイン名の
283 <code>*.snakeoil.com</code>
284 というようなワイルドカードのパターンにマッチすること
287 <p>バイナリ形式の証明書は ASN.1 表記法
288 [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>] で
290 この表記法は内容をどのように記述するかを定義し、
291 符号化の規定がこの情報がどのようにバイナリ形式に変換されるかを
293 証明書のバイナリ符号化は Distinguished Encoding
294 Rules (DER) で定義され、それはより一般的な Basic Encoding Rules
296 バイナリ形式を扱うことのできない送信では、
297 バイナリ形式は Base64 符号化 [<a href="#MIME">MIME</a>] で
298 ASCII 形式に変換されることがあります。
299 開始デリミタ行と終了デリミタ行で囲まれた、この形式のことを
300 PEM ("Privacy Enhanced Mail") 符号化された証明書と言います。</p>
303 <title>PEM 符号化された証明書の例 (example.crt)</title>
304 <pre>-----BEGIN CERTIFICATE-----
305 MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
306 FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
307 A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
308 cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
309 bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
310 MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
311 a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
312 cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
313 AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
314 gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
315 vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
316 lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
317 HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
318 gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
319 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
320 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
321 -----END CERTIFICATE-----</pre>
325 <section id="certificateauthorities">
327 <p>証明書を承認する前に、証明書要求に記載されている情報を確認し、
329 例えば、アリスが個人証明書を申請したとすると、
330 認証局はアリスが証明書の申請が主張する通りの
331 当の本人だということを確認しなくてはいけません。</p>
333 <section id="certificatechains">
334 <title>証明書の連鎖</title>
335 <p>認証局は他の認証局への証明書を発行することができます。
336 未知の証明書を調べる時に、アリスはその証明書の発行者
338 その上位階層の認証局をたどって調べる必要があります。
340 彼女は限られた連鎖の発行者のみ信頼するように
344 <section id="rootlevelca">
345 <title>最上位認証局の作成</title>
346 <p>前に述べたように、全ての証明書について、
347 最上位の認証局(CA)までそれぞれの発行者が
348 対象の身元証明の有効性を明らかにする必要があります。
349 問題は、誰がその最上位の認証機関の証明書を保証するのか、
351 このような場合に限り、証明書は「自己署名」されます。
352 ブラウザには、とてもよく知られている認証局が初期登録されていますが、
355 最上位認証局が公開鍵を広く公表することで、
356 その鍵を信頼するリスクを低くすることができます。
357 もし、他人がその認証局になりすました時に、それが露見しや
360 <p><a href="http://www.thawte.com/">Thawte</a>
361 や <a href="http://www.verisign.com/">VeriSign</a>
362 のような多くの会社が認証局として開設しました。
363 このような会社は以下のサービスを提供します:</p>
373 個人やサーバの身元証明が簡単に行える組織の
374 イントラネット内では役に立つかもしれません。</p>
377 <section id="certificatemanagement">
379 <p>認証局の開設は徹底した管理、技術、運用の体制を必要とする
383 具体的には、証明書がいつまで有効であり続けるかを決定し、更新し、
385 (Certificate Revocation Lists または CRL)
388 <p>例えばアリスが過去、会社の社員であることを証明する証明書を持っていたが、
389 現在は退職していた際、その証明書は失効されなければなりません。
390 証明書は次々と人に渡されていくものなので、
391 証明書そのものから、それが取り消されたか判断することは
394 認証局に連絡して CRL を照合する必要があります。
395 普通この過程は自動化されているものではありません。</p>
397 <note><title>注意</title>
398 <p>ブラウザに信用できる認証局としてデフォルトで登録されていない
401 ブラウザがその認証局によって署名されたサーバの証明書を
403 一度読み込まれると、その認証局によって署名された全ての
404 証明書を受け入れるため、危険を伴います。</p>
408 <!-- /certificateauthorities -->
410 <!-- /certificates -->
413 <title>Secure Sockets Layer (SSL)</title>
414 <p>Secure Sockets Layer プロトコルは信頼性のあるコネクション型の
415 ネットワーク層のプロトコル(例えば、TCP/IP)と
416 アプリケーション層のプロトコル(例えば、HTTP)
418 SSL は、相互認証によってサーバとクライアント間の安全な通信を、
420 そして暗号化によってプライバシを提供します。</p>
422 <p>SSL プロトコルは暗号化、ダイジェスト、電子署名について、
423 様々なアルゴリズムをサポートするようにできています。
424 こうすることで、法や輸出の規制を考慮に入れて、サーバに合わせた
425 アルゴリズムを選ぶことができ、また、新しいアルゴリズムを
427 アルゴリズムの選択はプロトコルセッション開始時に
428 サーバとクライアント間で取り決められます。</p>
430 <section id="table4">
431 <title>表4: SSL プロトコルのバージョン</title>
433 <columnspec><column width=".15"/><column width=".2"/>
434 <column width=".30"/><column width=".25"/></columnspec>
438 <th>ブラウザのサポート</th></tr>
439 <tr><td>SSL v2.0</td>
440 <td>Vendor Standard (Netscape Corp. より) [<a href="#SSL2"
442 <td>実装が現存する初めての SSL プロトコル</td>
443 <td>- NS Navigator 1.x/2.x<br />
445 - Lynx/2.8+OpenSSL</td></tr>
446 <tr><td>SSL v3.0</td>
447 <td>Expired Internet Draft (Netscape Corp. より) [<a href="#SSL3"
449 <td>特定のセキュリティ攻撃を防ぐための改訂、
450 非RSA 暗号の追加、証明書階層構造のサポート</td>
451 <td>- NS Navigator 2.x/3.x/4.x<br />
452 - MS IE 3.x/4.x<br />
453 - Lynx/2.8+OpenSSL</td></tr>
454 <tr><td>TLS v1.0</td>
455 <td>Proposed Internet Standard (IETF より) [<a href="#TLS1"
457 <td>MAC レイヤを HMAC へ更新、ブロック暗号の block
458 padding、メッセージ順序の標準化、警告文の充実などのため
460 <td>- Lynx/2.8+OpenSSL</td></tr>
464 <p><a href="#table4">表4</a>に示されるとおり、SSL プロトコルには
466 表にも書かれているように、SSL 3.0 の利点の一つは
468 この機能によって、サーバは自分の証明書に加えて、
469 発行者の証明書をブラウザに渡すことができます。
471 ブラウザに発行者の証明書が直接登録されていなくても、
473 ブラウザはサーバの証明書を有効化することができます。
474 SSL 3.0 は現在 Internet Engineering Task Force (IETF)
475 によって開発されている Transport Layer Security
476 [<a href="#TLS1">TLS</a>] プロトコル標準規格の基礎となっています。</p>
478 <section id="session">
479 <title>セッションの確立</title>
480 <p><a href="#figure1">図1</a>で示されるように、
481 セッションの確立はクライアントとサーバ間の
482 ハンドシェークシークエンスによって行なわれます。
483 サーバが証明書を提供するか、クライアントの証明書をリクエストするか
484 というサーバの設定により、このシークエンスは異なるものとなります。
485 暗号情報の管理のために、追加のハンドシェーク過程が必要になる
488 全ての可能性についは、SSL 仕様書を参照してください。</p>
490 <note><title>注意</title>
491 <p>一度 SSL セッションが確立すると、セッションを再利用することで、
492 セッションを開始するための多くの過程を繰り返すという
494 そのため、サーバは全てのセッションに一意なセッション識別名を
495 割り当て、サーバにキャッシュし、クライアントは次回から
496 (識別名がサーバのキャッシュで期限切れになるまでは)
497 ハンドシェークなしで接続することができます。</p>
502 src="../images/ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
503 <a id="figure1" name="figure1"><dfn>図1</dfn></a>: SSL
507 ハンドシェークシークエンスの要素を以下に示します:</p>
510 <li>データ通信に使われる暗号スイートの取り決め</li>
511 <li>クライアントとサーバ間でのセッション鍵の確立と共有</li>
512 <li>オプションとして、クライアントに対するサーバの認証</li>
513 <li>オプションとして、サーバに対するクライアントの認証</li>
516 <p>第一ステップの暗号スイート取り決めによって、
519 SSL3.0 プロトコルの仕様書は 31 の暗号スイートを定義しています。
520 暗号スイートは以下のコンポーネントにより定義されています:</p>
525 <li>Message Authentication Code (MAC) 作成のための
529 <p>これらの三つの要素は以下のセクションで説明されています。</p>
532 <section id="keyexchange">
533 <title>鍵の交換手段</title>
534 <p>鍵の交換手段はアプリケーションのデータ通信に使われ、
535 共有される対称暗号鍵をどのようにがクライアントとサーバで
537 SSL 2.0 は RSA 鍵交換しか使いませんが、
538 SSL 3.0 は (証明書が使われるときの) RSA 鍵交換や、
539 (証明書無しの場合やクライアントとサーバの事前の通信が無い場合の)
541 など様々な鍵交換アルゴリズムをサポートします。</p>
543 <p>鍵の交換方法における一つの選択肢は電子署名です。
545 どの種類の署名を使うかという選択があります。
546 秘密鍵で署名することで共有鍵を保護し、情報交換する時の
547 マン・イン・ザ・ミドル攻撃を防ぐことができます。
548 [<a href="#AC96">AC96</a>, p516]</p>
551 <section id="ciphertransfer">
552 <title>データ通信の暗号術</title>
553 <p>SSL はセッションのメッセージの暗号化に前述した
555 暗号化しないという選択肢も含め九つの暗号方式の選択肢があります:</p>
561 <li>40-bit 鍵での RC4</li>
562 <li>128-bit 鍵での RC4</li>
565 <ul><li>40 bit 鍵での RC2</li>
566 <li>40 bit 鍵での DES</li>
567 <li>56 bit 鍵での DES</li>
568 <li>168 bit 鍵での Triple-DES</li>
569 <li>Idea (128 bit 鍵)</li>
570 <li>Fortezza (96 bit 鍵)</li>
574 <p>CBC とは暗号ブロック連鎖 (Cipher Block Chaining)
575 の略で、一つ前の暗号化された暗号文の一部が
576 ブロックの暗号化に使われることを意味します。
577 DES はデータ暗号化標準規格 (Data Encryption Standard)
578 [<a href="#AC96">AC96</a>, ch12] の略で、
579 DES40 や 3DES_EDE を含むいくつもの種類があります。
580 Idea は現在最高なものの一つで、暗号術的には現在ある中で
582 RC2 は RSA DSI による独占的なアルゴリズムです。
583 [<a href="#AC96">AC96</a>,
587 <section id="digestfuntion">
588 <title>ダイジェスト関数</title>
590 ダイジェスト関数の選択はレコードユニットからどのようにダイジェストが生成されるかを決定します。
595 <li>MD5 (128-bit ハッシュ)</li>
596 <li>Secure Hash Algorithm (SHA-1) (160-bit ハッシュ)</li>
599 <p>メッセージダイジェストは Message Authentication Code (MAC)
600 の生成に使われ、メッセージと共に暗号化され、メッセージの信憑性を
604 <section id="handshake">
605 <title>ハンドシェークシークエンスプロトコル</title>
606 <p>ハンドシェークシークエンスは三つのプロトコルを使います:</p>
609 <li><dfn>SSL ハンドシェークプロトコル</dfn>は
610 クライアントとサーバ間での SSL セッションの確立に使われます。</li>
611 <li><dfn>SSL 暗号仕様変更プロトコル</dfn>は
612 セッションでの暗号スイートの取り決めに使われます。</li>
613 <li><dfn>SSL 警告プロトコル</dfn>は
614 クライアントサーバ間で SSL エラーを伝達するのに使われます。</li>
617 <p>三つのプロトコルは、アプリケーションプロトコルデータとともに、
618 <a href="#figure2">図2</a>に示すとおり <dfn>SSL レコードプロトコル</dfn>
620 カプセル化されたプロトコルはデータを検査しない
621 下層のプロトコルによってデータとして伝達されます。
622 カプセル化されたプロトコルは下層のプロトコルに関して一切関知しません。</p>
625 <img src="../images/ssl_intro_fig2.gif" alt="" width="428"
626 height="217" /><br />
627 <a id="figure2" name="figure2"><dfn>図2</dfn></a>: SSL プロトコルスタック
631 レコードプロトコルで SSL コントロールプロトコルがカプセル化されているということは、
632 アクティブなセッション上で再ネゴシエーションされたときにも、
633 コントロールプロトコルは安全であることを意味します。
634 既存のセッションが無い場合は、Null 暗号スイートが使われ、
635 暗号化は行なわれず、セッションが確立するまでは
636 ダイジェストも無い状態となります。</p>
639 <section id="datatransfer">
641 <p><a href="#figure3">図3</a>に示される SSL レコードプロトコル
642 はクライアントとサーバ間のアプリケーションや
643 SSL コントロールデータの通信に使われます。
644 必要に応じてこのデータはより小さいユニットに分けられたり、
645 いくつかの高級プロトコルをまとめて一ユニットとして通信が
647 データを圧縮し、ダイジェスト署名を添付して、
648 これらのユニットを暗号化したのち、ベースとなっている
649 信頼性のあるトランスポートプロトコルを用いるかもしれません。
650 (注意: 現在メジャーな SLL 実装で圧縮をサポートしているものはありません)</p>
653 <img src="../images/ssl_intro_fig3.gif" alt="" width="423"
654 height="323" /><br />
655 <a id="figure3" name="figure3"><dfn>図 3</dfn></a>: SSL レコードプロトコル
659 <section id="securehttp">
660 <title>HTTP 通信の安全化</title>
661 <p>よくある SSL の使い方はブラウザとウェブサーバ間の HTTP 通信
663 これは、従来の安全ではない HTTP の使用を除外するものではありません。
664 安全化されたもの (HTTPS と呼ばれます) は、SSL 上での普通の HTTP で、
665 URL スキームに <code>http</code> の代わりに <code>https</code>
666 を用い、サーバで別のポートを使うことです (デフォルトでは443)。
667 これが主に <module>mod_ssl</module> が Apache
673 <section id="references">
676 <dt><a id="AC96" name="AC96">[AC96]</a></dt>
677 <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
678 1996. See <a href="http://www.counterpane.com/"
679 >http://www.counterpane.com/</a> for various other materials by Bruce
682 <dt><a id="X208" name="X208">[X208]</a></dt>
683 <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
684 One (ASN.1)</q>, 1988. See for instance <a
685 href="http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I"
686 >http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I</a>.
689 <dt><a id="X509" name="X509">[X509]</a></dt>
690 <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
691 Framework</q>. See for instance <a
692 href="http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509"
693 >http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509</a>.
696 <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
697 <dd><q>Public Key Cryptography Standards (PKCS)</q>,
698 RSA Laboratories Technical Notes, See <a
699 href="http://www.rsasecurity.com/rsalabs/pkcs/"
700 >http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
702 <dt><a id="MIME" name="MIME">[MIME]</a></dt>
703 <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
704 (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
705 See for instance <a href="http://ietf.org/rfc/rfc2045.txt"
706 >http://ietf.org/rfc/rfc2045.txt</a>.</dd>
708 <dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
709 <dd>Kipp E.B. Hickman, <q>The SSL Protocol</q>, 1995. See <a
710 href="http://www.netscape.com/eng/security/SSL_2.html"
711 >http://www.netscape.com/eng/security/SSL_2.html</a>.</dd>
713 <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
714 <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
715 Version 3.0</q>, 1996. See <a
716 href="http://www.netscape.com/eng/ssl3/draft302.txt"
717 >http://www.netscape.com/eng/ssl3/draft302.txt</a>.</dd>
719 <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
720 <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
721 1999. See <a href="http://ietf.org/rfc/rfc2246.txt"
722 >http://ietf.org/rfc/rfc2246.txt</a>.</dd>