granicus.if.org Git - apache/blob - docs/manual/ssl/ssl_intro.html.ja.utf8

   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 <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
   5 <!--
   6         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   7               This file is generated from xml source: DO NOT EDIT
   8         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   9       -->
  10 <title>SSL/TLS 暗号化: はじめに - Apache HTTP サーバ バージョン 2.5</title>
  11 <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
  12 <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
  13 <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" />
  14 <script src="../style/scripts/prettify.min.js" type="text/javascript">
  15 </script>
  16
  17 <link href="../images/favicon.ico" rel="shortcut icon" /></head>
  18 <body id="manual-page"><div id="page-header">
  19 <p class="menu"><a href="../mod/">モジュール</a> | <a href="../mod/quickreference.html">ディレクティブ</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">用語</a> | <a href="../sitemap.html">サイトマップ</a></p>
  20 <p class="apache">Apache HTTP サーバ バージョン 2.5</p>
  21 <img alt="" src="../images/feather.png" /></div>
  22 <div class="up"><a href="./"><img title="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div>
  23 <div id="path">
  24 <a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">HTTP サーバ</a> &gt; <a href="http://httpd.apache.org/docs/">ドキュメンテーション</a> &gt; <a href="../">バージョン 2.5</a> &gt; <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS 暗号化: はじめに</h1>
  25 <div class="toplang">
  26 <p><span>翻訳済み言語: </span><a href="../en/ssl/ssl_intro.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
  27 <a href="../fr/ssl/ssl_intro.html" hreflang="fr" rel="alternate" title="Français">&nbsp;fr&nbsp;</a> |
  28 <a href="../ja/ssl/ssl_intro.html" title="Japanese">&nbsp;ja&nbsp;</a></p>
  29 </div>
  30 <div class="outofdate">この日本語訳はすでに古くなっている
  31             可能性があります。
  32             最近更新された内容を見るには英語版をご覧下さい。
  33         </div>
  34
  35 <blockquote>
  36 <p>標準規格の良い所は、たくさんの規格から選べるということだ。
  37 そして、もし本当にどの規格も気に入らなければ、
  38 一年待つだけで探していた規格が現れる。</p>
  39
  40 <p class="cite">-- <cite>A. Tanenbaum</cite>, "Introduction to
  41 Computer Networks"</p>
  42 </blockquote>
  43
  44 <p>
  45 入門ということで、この章は Web、HTTP、Apache に通じている
  46 読者向けですが、セキュリティ専門家向けではありません。
  47 SSL プロトコルの決定的な手引きであるつもりはありません。
  48 また、組織内の認証管理のための特定のテクニックや、
  49 特許や輸出規制などの重要な法的な問題についても扱いません。
  50 むしろ、更なる研究への出発点として色々な概念、定義、例を並べることで
  51 <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> のユーザに基礎知識を提供する事を目的としています。</p>
  52
  53 <p>ここに示された内容は主に、原著者の許可の下
  54 The Open Group Research Institute の <a href="http://home.earthlink.net/~fjhirsch/">Frederick J. Hirsch</a>
  55  氏の記事 <a href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/">
  56 Introducing SSL and Certificates using SSLeay</a> を基にしています。
  57 氏の記事は <a href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of
  58 Trust</a>, World Wide Web Journal, Volume 2, Issue 3, Summer 1997
  59 に掲載されました。
  60 肯定的な意見は <a href="mailto:hirsch@fjhirsch.com">Frederick Hirsch</a> 氏
  61  (元記事の著者) へ全ての苦情は <a href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> (
  62 <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> の作者) へお願いします。
  63 <span class="transnote">(<em>訳注:</em> 訳については <a href="mailto:apache-docs@ml.apache.or.jp">
  64 Apache ドキュメント翻訳プロジェクト</a>
  65 へお願いします。)</span></p>
  66 </div>
  67 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cryptographictech">暗号化技術</a></li>
  68 <li><img alt="" src="../images/down.gif" /> <a href="#certificates">証明書</a></li>
  69 <li><img alt="" src="../images/down.gif" /> <a href="#ssl">Secure Sockets Layer (SSL)</a></li>
  70 <li><img alt="" src="../images/down.gif" /> <a href="#references">参考文献</a></li>
  71 </ul><h3>参照</h3><ul class="seealso"><li><a href="#comments_section">コメント</a></li></ul></div>
  72 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
  73 <div class="section">
  74 <h2><a name="cryptographictech" id="cryptographictech">暗号化技術</a> <a title="Permanent link" href="#cryptographictech" class="permalink">&para;</a></h2>
  75
  76 <p>SSL を理解するには、暗号アルゴリズム、
  77 メッセージダイジェスト関数(別名: 一方向関数、ハッシュ関数)、
  78 電子署名などへの理解が必要です。
  79 これらの技術は本が丸ごと必要な題目で
  80 (例えば [<a href="#AC96">AC96</a>] を参照)、
  81 プライバシー、信用、認証などの技術の基礎となっています。</p>
  82
  83 <h3><a name="cryptographicalgo" id="cryptographicalgo">暗号アルゴリズム</a></h3>
  84
  85     <p>例えば、アリスが送金のために銀行にメッセージを送りたいとします。
  86     口座番号や送金の金額が含まれるため、
  87     アリスはそのメッセージを秘密にしたいと思います。
  88     解決方法の一つは暗号アルゴリズムを使って、メッセージを
  89     復号されるまで読むことができない暗号化された
  90     形態に変えてしまうことです。
  91     その形態になると、
  92     メッセージは秘密の鍵によってのみ復号化することができます。
  93     鍵なしでは、メッセージは役に立ちません。
  94     良い暗号アルゴリズムは、侵入者が元のテキストを解読することを
  95     非常に難しくするため、努力が割に合わなくさせます。</p>
  96
  97     <p>暗号アルゴリズムには
  98     従来型と公開鍵の二つの種類があります。</p>
  99
 100     <dl>
 101     <dt>従来型暗号</dt>
 102     <dd>対称暗号としても知られ、
 103     送信者と受信者が鍵を共有することが必要です。
 104     鍵とは、メッセージを暗号化したり復号するのに使われる秘密
 105     の情報のことです。
 106     この鍵が秘密になっている限り、送信者と受信者以外は誰もメッセージを読
 107     むことができません。
 108     もしも、アリスと銀行が秘密の鍵を知っているなら、
 109     彼らはお互いに秘密のメッセージを送ることができるでしょう。
 110     ただし交信の前に、事前に内密に鍵を共有するという作業自体は難題かもしれません。</dd>
 111
 112     <dt>公開鍵暗号</dt>
 113     <dd>非対称暗号としても知られ、
 114     メッセージを暗号化することのできる二つの鍵
 115     を使用するアルゴリズムを定義することで鍵のやり取りの問題を解決
 116     します。
 117     もし、ある鍵が暗号化に使われたなら、
 118     もう片方の鍵で復号しなければいけません。
 119     この方式によって、一つの鍵を公表して(公開鍵)、
 120     もう片方を秘密にしておく(秘密鍵)だけで、
 121     安全なメッセージを受け取ることができます。</dd>
 122     </dl>
 123
 124     <p>公開鍵を使って誰もがメッセージを暗号化できますが、秘
 125     密鍵の持ち主だけがそれを読むことができます。
 126     この方法で、銀行の公開鍵を使って暗号化することで、
 127     アリスは秘密のメッセージを送ることができます。
 128     銀行のみが送られたメッセージを復号することができます。</p>
 129
 130
 131 <h3><a name="messagedigests" id="messagedigests">メッセージダイジェスト</a></h3>
 132
 133     <p>アリスはメッセージを秘密にすることができますが、
 134     誰かが例えば自分に送金するようにメッセージを変更したり、
 135     別のものに置き換えてしまうかもしれないという問題があります。
 136     アリスのメッセージだという信憑性を保証する方法の一つは、
 137     メッセージの簡潔なダイジェストを作って、それも銀行に送るというものです。
 138     メッセージを受け取ると銀行側でもダイジェストを作成し、
 139     アリスが送ったダイジェストと比べます。もし一致したなら、
 140     受け取ったメッセージは無傷だということになります。</p>
 141
 142     <p>このような要約は<dfn>メッセージダイジェスト</dfn>、
 143     <em>一方行関数</em>、または<em>ハッシュ関数</em>と呼ばれます。
 144     メッセージダイジェストは長い可変長のメッセージから
 145     短い固定長の表現を作るのに使われます。
 146     ダイジェストアルゴリズムはメッセージから
 147     一意なダイジェストを生成するように作られています。
 148     メッセージダイジェストはダイジェストから元のメッセージを
 149     判定するのがとても難しいようにできていて、
 150     同じ要約を作成する二つのメッセージを探すのは(理論上)不可能です。
 151     これによって、要約を変更することなくメッセージを置き換えられる
 152     可能性を排除しています。</p>
 153
 154     <p>アリスへのもう一つの問題は、このダイジェストを安全に送る方法を探すことです。
 155     ダイジェストが安全に送られればダイジェストの信憑性が保障されて、
 156     ダイジェストの信憑性をもってオリジナルメッセージの信憑性を得ることができます。
 157     ダイジェストを安全に送った場合にのみ、そのメッセージの
 158     信憑性が得られます。</p>
 159
 160     <p>ダイジェスト安全に送る方法の一つは、電子署名に含める方法です。</p>
 161
 162
 163 <h3><a name="digitalsignatures" id="digitalsignatures">電子署名</a></h3>
 164 <p>アリスが銀行にメッセージを送ったとき、
 165 侵入者が彼女になりすまして彼女の口座への取引を申請できないように、
 166 銀行側ではメッセージが本当に彼女からのものか確実に分かるようにしなければなりません。
 167 アリスによって作成されて、メッセージに含まれた
 168 <em>電子署名</em>がここで役に立ちます。</p>
 169
 170 <p>電子署名はメッセージのダイジェストやその他の情報(処理番号など)を
 171 送信者の秘密鍵で暗号化することで作られます。
 172 誰もが公開鍵を使って署名を<em>復号</em>することができますが、
 173 送信者のみが秘密鍵を知っています。
 174 これは送信者のみが署名しえたことを意味します。
 175 ダイジェストを電子署名に含むことは、
 176 その署名がそのメッセージのみに有効であることを意味します。
 177 これは、誰もダイジェストを変えて署名をすることができないため、
 178 メッセージの信用も保証します。</p>
 179
 180 <p>侵入者が署名を傍受して後日に再利用するのを防ぐため
 181 電子署名には一意な処理番号が含まれます。
 182 これは、アリスがそんなメッセージは送っていないと言う詐欺
 183 から銀行を守ります。
 184 彼女だけが署名しえたからです。(否認防止)</p>
 185
 186 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 187 <div class="section">
 188 <h2><a name="certificates" id="certificates">証明書</a> <a title="Permanent link" href="#certificates" class="permalink">&para;</a></h2>
 189
 190 <p>アリスは秘密のメッセージを銀行に送り、
 191 署名をして、メッセージの信用を保証することができるおうになりましたが、
 192 通信している相手が本当に銀行なのか確かめなくてはいけません。
 193 つまり彼女が使おうとしている公開鍵が、銀行の秘密鍵と対になっていて、
 194 侵入者の秘密鍵と対になっているわけではないことを
 195 確かめなくてはいけないことを意味しています。
 196 同様に銀行は、メッセージの署名が本当にアリスの持っている
 197 秘密鍵で署名された署名かを確認する必要があります。</p>
 198
 199 <p>もし両者に身元を証明し、公開鍵を確認し、また信頼された機関が署名
 200 した証明書があれば、両者とも通信相手について正しい相手だと
 201 確信することができます。
 202 そのような信頼された機関は<em>認証局</em>
 203  (Certificate Authority または CA) と呼ばれ、
 204 証明書 (certificate) が認証 (authentication) に使われます。</p>
 205
 206 <h3><a name="certificatecontents" id="certificatecontents">証明書の内容</a></h3>
 207
 208     <p>証明書は公開鍵と個人、サーバ、その他の主体の実在の身元を
 209     関連付けます。
 210     <a href="#table1">表1</a>に示されるように証明対象の情報は
 211     身元証明の情報(識別名)と公開鍵が含まれます。
 212     証明書はまた、認証局の身元証明と署名、そして証明書の有効期間を
 213     含みます。
 214     シリアルナンバーなどの認証局の管理上の情報や
 215     その他の追加の情報が含まれているかもしれません。</p>
 216
 217     <h4><a name="table1" id="table1">表1: 証明書情報</a></h4>
 218
 219     <table>
 220
 221     <tr><th>証明対象</th>
 222         <td>識別名、公開鍵</td></tr>
 223     <tr><th>発行者</th>
 224         <td>識別名、公開鍵</td></tr>
 225     <tr><th>有効期間</th>
 226         <td>開始日、失効日</td></tr>
 227     <tr><th>管理情報</th>
 228         <td>バージョン、シリアルナンバー</td></tr>
 229     <tr><th>拡張情報</th>
 230         <td>基本的な制約、ネットスケープフラッグ、その他</td></tr>
 231     </table>
 232
 233
 234     <p>識別名(ディスティングイッシュ・ネーム)は特定の状況における
 235     身分証明を提供するのに使われています。例えば、ある人は
 236     私用と会社とで別々の身分証明を持つかもしれません。
 237
 238     識別名は X.509 標準規格 [<a href="#X509">X509</a>] で定義されています。
 239     X.509 標準規格は、項目、項目名、そして項目の略称を定義しています。(<a href="#table2">表
 240     2</a> 参照)</p>
 241
 242     <h4><a name="table2" id="table2">表 2: 識別名情報</a></h4>
 243
 244     <table class="bordered">
 245
 246     <tr><th>識別名項目</th>
 247         <th>略称</th>
 248         <th>説明</th>
 249         <th>例</th></tr>
 250     <tr><td>Common Name (コモンネーム)</td>
 251         <td>CN</td>
 252         <td>認証される名前<br />
 253         SSL接続するURL</td>
 254         <td>CN=www.example.com</td></tr>
 255     <tr><td>Organization or Company (組織名)</td>
 256         <td>O</td>
 257         <td>団体の正式英語組織名</td>
 258         <td>O=Example Japan K.K.</td></tr>
 259     <tr><td>Organizational Unit (部門名)</td>
 260         <td>OU</td>
 261         <td>部署名など</td>
 262         <td>OU=Customer Service</td></tr>
 263     <tr><td>City/Locality (市区町村)</td>
 264         <td>L</td>
 265         <td>所在してる市区町村</td>
 266         <td>L=Sapporo</td></tr>
 267     <tr><td>State/Province (都道府県)</td>
 268         <td>ST</td>
 269         <td>所在してる都道府県</td>
 270         <td>ST=Hokkaido</td></tr>
 271     <tr><td>Country(国)</td>
 272         <td>C</td>
 273         <td>所在している国名の ISO コード<br />
 274         日本の場合 JP
 275         </td>
 276         <td>C=JP</td></tr>
 277     </table>
 278
 279
 280     <p>認証局はどの項目が省略可能でどれが必須かの方針を定義する
 281     かもしれません。項目の内容についても認証局や証明書のユーザからの
 282     要件があるかもしれません。
 283     例えばネットスケープのブラウザは、サーバの証明書の
 284      Common Name (コモンネーム)がサーバのドメイン名の
 285      <code>*.snakeoil.com</code>
 286     というようなワイルドカードのパターンにマッチすること
 287     を要求します。</p>
 288
 289     <p>バイナリ形式の証明書は ASN.1 表記法
 290      [<a href="#X208">X208</a>] [<a href="#PKCS">PKCS</a>] で
 291     定義されています。
 292     この表記法は内容をどのように記述するかを定義し、
 293     符号化の規定がこの情報がどのようにバイナリ形式に変換されるかを
 294     定義します。
 295     証明書のバイナリ符号化は Distinguished Encoding
 296     Rules (DER) で定義され、それはより一般的な Basic Encoding Rules
 297     (BER) に基づいています。
 298     バイナリ形式を扱うことのできない送信では、
 299     バイナリ形式は Base64 符号化 [<a href="#MIME">MIME</a>] で
 300     ASCII 形式に変換されることがあります。
 301     開始デリミタ行と終了デリミタ行で囲まれた、この形式のことを
 302     PEM ("Privacy Enhanced Mail") 符号化された証明書と言います。</p>
 303
 304     <div class="example"><h3>PEM 符号化された証明書の例 (example.crt)</h3><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></div>
 322
 323
 324 <h3><a name="certificateauthorities" id="certificateauthorities">認証局</a></h3>
 325
 326     <p>証明書を承認する前に、証明書要求に記載されている情報を確認し、
 327     認証局は鍵の所有者の身元を確認します。
 328     例えば、アリスが個人証明書を申請したとすると、
 329     認証局はアリスが証明書の申請が主張する通りの
 330     当の本人だということを確認しなくてはいけません。</p>
 331
 332     <h4><a name="certificatechains" id="certificatechains">証明書の連鎖</a></h4>
 333
 334         <p>認証局は他の認証局への証明書を発行することができます。
 335         未知の証明書を調べる時に、アリスはその証明書の発行者
 336         に自信が持てるまで、発行者の証明書を
 337         その上位階層の認証局をたどって調べる必要があります。
 338         「悪質な」証明書の危険性を減らすため、
 339         彼女は限られた連鎖の発行者のみ信頼するように
 340         決めることもできます。</p>
 341
 342
 343     <h4><a name="rootlevelca" id="rootlevelca">最上位認証局の作成</a></h4>
 344
 345         <p>前に述べたように、全ての証明書について、
 346         最上位の認証局(CA)までそれぞれの発行者が
 347         対象の身元証明の有効性を明らかにする必要があります。
 348         問題は、誰がその最上位の認証機関の証明書を保証するのか、
 349         ということです。
 350         このような場合に限り、証明書は「自己署名」されます。
 351         ブラウザには、とてもよく知られている認証局が初期登録されていますが、
 352         自己署名された証明書を信用する際には
 353         細心の注意が必要です。
 354         最上位認証局が公開鍵を広く公表することで、
 355         その鍵を信頼するリスクを低くすることができます。
 356         もし、他人がその認証局になりすました時に、それが露見しや
 357         すいからです。</p>
 358
 359         <p><a href="http://www.thawte.com/">Thawte</a>
 360         や <a href="http://www.verisign.com/">VeriSign</a>
 361         のような多くの会社が認証局として開設しました。
 362         このような会社は以下のサービスを提供します:</p>
 363
 364         <ul>
 365         <li>証明書申請の確認</li>
 366         <li>証明書申請の処理</li>
 367         <li>証明書の発行と管理</li>
 368         </ul>
 369
 370         <p>自分で認証局を作ることも可能です。
 371         インターネット環境では危険ですが、
 372         個人やサーバの身元証明が簡単に行える組織の
 373         イントラネット内では役に立つかもしれません。</p>
 374
 375
 376     <h4><a name="certificatemanagement" id="certificatemanagement">証明書管理</a></h4>
 377
 378         <p>認証局の開設は徹底した管理、技術、運用の体制を必要とする
 379         責任のある仕事です。
 380         認証局は証明書を発行するだけでなく、
 381         管理もしなければなりません。
 382         具体的には、証明書がいつまで有効であり続けるかを決定し、更新し、
 383         また過去発行されて失効した証明書のリスト
 384         (Certificate Revocation Lists または CRL)
 385         を管理しなければいけません。</p>
 386
 387         <p>例えばアリスが過去、会社の社員であることを証明する証明書を持っていたが、
 388         現在は退職していた際、その証明書は失効されなければなりません。
 389         証明書は次々と人に渡されていくものなので、
 390         証明書そのものから、それが取り消されたか判断することは
 391         不可能です。
 392         よって、証明書の有効性を調べるときには、
 393         認証局に連絡して CRL を照合する必要があります。
 394         普通この過程は自動化されているものではありません。</p>
 395
 396         <div class="note"><h3>注意</h3>
 397         <p>ブラウザに信用できる認証局としてデフォルトで登録されていない
 398         認証局を使おうとした場合、
 399         認証局の証明書をブラウザに読み込んで、
 400         ブラウザがその認証局によって署名されたサーバの証明書を
 401         有効にする必要があります。
 402         一度読み込まれると、その認証局によって署名された全ての
 403         証明書を受け入れるため、危険を伴います。</p>
 404         </div>
 405
 406
 407
 408 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 409 <div class="section">
 410 <h2><a name="ssl" id="ssl">Secure Sockets Layer (SSL)</a> <a title="Permanent link" href="#ssl" class="permalink">&para;</a></h2>
 411
 412 <p>Secure Sockets Layer プロトコルは信頼性のあるコネクション型の
 413 ネットワーク層のプロトコル(例えば、TCP/IP)と
 414 アプリケーション層のプロトコル(例えば、HTTP)
 415 の間に置くことができます。
 416 SSL は、相互認証によってサーバとクライアント間の安全な通信を、
 417 電子署名によってデータの完全性を、
 418 そして暗号化によってプライバシを提供します。</p>
 419
 420 <p>SSL プロトコルは暗号化、ダイジェスト、電子署名について、
 421 様々なアルゴリズムをサポートするようにできています。
 422 こうすることで、法や輸出の規制を考慮に入れて、サーバに合わせた
 423 アルゴリズムを選ぶことができ、また、新しいアルゴリズムを
 424 利用していくことも可能にしています。
 425 アルゴリズムの選択はプロトコルセッション開始時に
 426 サーバとクライアント間で取り決められます。</p>
 427
 428 <h3><a name="table4" id="table4">表4: SSL プロトコルのバージョン</a></h3>
 429
 430     <table class="bordered">
 431
 432     <tr><th>バージョン</th>
 433         <th>出典</th>
 434         <th>説明</th>
 435         <th>ブラウザのサポート</th></tr>
 436     <tr><td>SSL v2.0</td>
 437         <td>Vendor Standard (Netscape Corp. より) [<a href="#SSL2">SSL2</a>]</td>
 438         <td>実装が現存する初めての SSL プロトコル</td>
 439         <td>- NS Navigator 1.x/2.x<br />
 440         - MS IE 3.x<br />
 441         - Lynx/2.8+OpenSSL</td></tr>
 442     <tr><td>SSL v3.0</td>
 443         <td>Expired Internet Draft (Netscape Corp. より) [<a href="#SSL3">SSL3</a>]</td>
 444         <td>特定のセキュリティ攻撃を防ぐための改訂、
 445         非RSA 暗号の追加、証明書階層構造のサポート</td>
 446         <td>- NS Navigator 2.x/3.x/4.x<br />
 447         - MS IE 3.x/4.x<br />
 448         - Lynx/2.8+OpenSSL</td></tr>
 449     <tr><td>TLS v1.0</td>
 450         <td>Proposed Internet Standard (IETF より) [<a href="#TLS1">TLS1</a>]</td>
 451         <td>MAC レイヤを HMAC へ更新、ブロック暗号の block
 452         padding、メッセージ順序の標準化、警告文の充実などのため
 453         SSL 3.0 を改訂。</td>
 454         <td>- Lynx/2.8+OpenSSL</td></tr>
 455     </table>
 456
 457
 458 <p><a href="#table4">表4</a>に示されるとおり、SSL プロトコルには
 459 いくつものバージョンがあります。
 460 表にも書かれているように、SSL 3.0 の利点の一つは
 461 証明書階層構造をサポートすることです。
 462 この機能によって、サーバは自分の証明書に加えて、
 463 発行者の証明書をブラウザに渡すことができます。
 464 証明書階層構造によって、
 465 ブラウザに発行者の証明書が直接登録されていなくても、
 466 階層の中に含まれていれば、
 467 ブラウザはサーバの証明書を有効化することができます。
 468 SSL 3.0 は現在 Internet Engineering Task Force (IETF)
 469 によって開発されている Transport Layer Security
 470 [<a href="#TLS1">TLS</a>] プロトコル標準規格の基礎となっています。</p>
 471
 472 <h3><a name="session" id="session">セッションの確立</a></h3>
 473
 474     <p><a href="#figure1">図1</a>で示されるように、
 475     セッションの確立はクライアントとサーバ間の
 476     ハンドシェークシークエンスによって行なわれます。
 477     サーバが証明書を提供するか、クライアントの証明書をリクエストするか
 478     というサーバの設定により、このシークエンスは異なるものとなります。
 479     暗号情報の管理のために、追加のハンドシェーク過程が必要になる
 480     場合もありますが、この記事では
 481     よくあるシナリオを手短に説明します。
 482     全ての可能性についは、SSL 仕様書を参照してください。</p>
 483
 484     <div class="note"><h3>注意</h3>
 485     <p>一度 SSL セッションが確立すると、セッションを再利用することで、
 486     セッションを開始するための多くの過程を繰り返すという
 487     パフォーマンスの損失を防ぎます。
 488     そのため、サーバは全てのセッションに一意なセッション識別名を
 489     割り当て、サーバにキャッシュし、クライアントは次回から
 490     (識別名がサーバのキャッシュで期限切れになるまでは)
 491     ハンドシェークなしで接続することができます。</p>
 492     </div>
 493
 494     <p class="figure">
 495     <img src="../images/ssl_intro_fig1.gif" alt="" width="423" height="327" /><br />
 496     <a id="figure1" name="figure1"><dfn>図1</dfn></a>: SSL
 497     ハンドシェークシークエンス概略</p>
 498
 499     <p>サーバとクライアントで使われる
 500     ハンドシェークシークエンスの要素を以下に示します:</p>
 501
 502     <ol>
 503     <li>データ通信に使われる暗号スイートの取り決め</li>
 504     <li>クライアントとサーバ間でのセッション鍵の確立と共有</li>
 505     <li>オプションとして、クライアントに対するサーバの認証</li>
 506     <li>オプションとして、サーバに対するクライアントの認証</li>
 507     </ol>
 508
 509     <p>第一ステップの暗号スイート取り決めによって、
 510     サーバとクライアントはそれぞれにあった
 511     暗号スイートを選ぶことができます。
 512     SSL3.0 プロトコルの仕様書は 31 の暗号スイートを定義しています。
 513     暗号スイートは以下のコンポーネントにより定義されています:</p>
 514
 515     <ul>
 516     <li>鍵の交換手段</li>
 517     <li>データ通信の暗号術</li>
 518     <li>Message Authentication Code (MAC) 作成のための
 519     メッセージダイジェスト</li>
 520     </ul>
 521
 522     <p>これらの三つの要素は以下のセクションで説明されています。</p>
 523
 524
 525 <h3><a name="keyexchange" id="keyexchange">鍵の交換手段</a></h3>
 526
 527     <p>鍵の交換手段はアプリケーションのデータ通信に使われ、
 528     共有される対称暗号鍵をどのようにがクライアントとサーバで
 529     取り決めるかを定義します。
 530     SSL 2.0 は RSA 鍵交換しか使いませんが、
 531     SSL 3.0 は (証明書が使われるときの) RSA 鍵交換や、
 532     (証明書無しの場合やクライアントとサーバの事前の通信が無い場合の)
 533     Diffie-Hellman 鍵交換
 534     など様々な鍵交換アルゴリズムをサポートします。</p>
 535
 536     <p>鍵の交換方法における一つの選択肢は電子署名です。
 537     電子署名を使うかどうか、また、
 538     どの種類の署名を使うかという選択があります。
 539     秘密鍵で署名することで共有鍵を保護し、情報交換する時の
 540     マン・イン・ザ・ミドル攻撃を防ぐことができます。
 541     [<a href="#AC96">AC96</a>, p516]</p>
 542
 543
 544 <h3><a name="ciphertransfer" id="ciphertransfer">データ通信の暗号術</a></h3>
 545
 546     <p>SSL はセッションのメッセージの暗号化に前述した
 547     対称暗号方式を用います。
 548     暗号化しないという選択肢も含め九つの暗号方式の選択肢があります:</p>
 549
 550     <ul>
 551     <li>暗号化なし</li>
 552     <li>ストリーム暗号
 553         <ul>
 554         <li>40-bit 鍵での RC4</li>
 555         <li>128-bit 鍵での RC4</li>
 556         </ul></li>
 557     <li>CBC ブロック暗号
 558         <ul><li>40 bit 鍵での RC2</li>
 559         <li>40 bit 鍵での DES</li>
 560         <li>56 bit 鍵での DES</li>
 561         <li>168 bit 鍵での Triple-DES</li>
 562         <li>Idea (128 bit 鍵)</li>
 563         <li>Fortezza (96 bit 鍵)</li>
 564         </ul></li>
 565     </ul>
 566
 567     <p>CBC とは暗号ブロック連鎖 (Cipher Block Chaining)
 568      の略で、一つ前の暗号化された暗号文の一部が
 569     ブロックの暗号化に使われることを意味します。
 570     DES はデータ暗号化標準規格 (Data Encryption Standard)
 571      [<a href="#AC96">AC96</a>, ch12] の略で、
 572     DES40 や 3DES_EDE を含むいくつもの種類があります。
 573     Idea は現在最高なものの一つで、暗号術的には現在ある中で
 574     最も強力なものです。
 575     RC2 は RSA DSI による独占的なアルゴリズムです。
 576      [<a href="#AC96">AC96</a>,
 577     ch13]</p>
 578
 579
 580 <h3><a name="digestfuntion" id="digestfuntion">ダイジェスト関数</a></h3>
 581
 582     <p>
 583     ダイジェスト関数の選択はレコードユニットからどのようにダイジェストが生成されるかを決定します。
 584     SSL は以下をサポートします:</p>
 585
 586     <ul>
 587     <li>ダイジェストなし</li>
 588     <li>MD5 (128-bit ハッシュ)</li>
 589     <li>Secure Hash Algorithm (SHA-1) (160-bit ハッシュ)</li>
 590     </ul>
 591
 592     <p>メッセージダイジェストは Message Authentication Code (MAC)
 593     の生成に使われ、メッセージと共に暗号化され、メッセージの信憑性を
 594     確認し、リプレイ攻撃を防ぎます。</p>
 595
 596
 597 <h3><a name="handshake" id="handshake">ハンドシェークシークエンスプロトコル</a></h3>
 598
 599     <p>ハンドシェークシークエンスは三つのプロトコルを使います:</p>
 600
 601     <ul>
 602     <li><dfn>SSL ハンドシェークプロトコル</dfn>は
 603     クライアントとサーバ間での SSL セッションの確立に使われます。</li>
 604     <li><dfn>SSL 暗号仕様変更プロトコル</dfn>は
 605     セッションでの暗号スイートの取り決めに使われます。</li>
 606     <li><dfn>SSL 警告プロトコル</dfn>は
 607     クライアントサーバ間で SSL エラーを伝達するのに使われます。</li>
 608     </ul>
 609
 610     <p>三つのプロトコルは、アプリケーションプロトコルデータとともに、
 611     <a href="#figure2">図2</a>に示すとおり <dfn>SSL レコードプロトコル</dfn>
 612     でカプセル化されます。
 613     カプセル化されたプロトコルはデータを検査しない
 614     下層のプロトコルによってデータとして伝達されます。
 615     カプセル化されたプロトコルは下層のプロトコルに関して一切関知しません。</p>
 616
 617     <p class="figure">
 618     <img src="../images/ssl_intro_fig2.gif" alt="" width="428" height="217" /><br />
 619     <a id="figure2" name="figure2"><dfn>図2</dfn></a>: SSL プロトコルスタック
 620     </p>
 621
 622     <p>
 623     レコードプロトコルで SSL コントロールプロトコルがカプセル化されているということは、
 624     アクティブなセッション上で再ネゴシエーションされたときにも、
 625     コントロールプロトコルは安全であることを意味します。
 626     既存のセッションが無い場合は、Null 暗号スイートが使われ、
 627     暗号化は行なわれず、セッションが確立するまでは
 628     ダイジェストも無い状態となります。</p>
 629
 630
 631 <h3><a name="datatransfer" id="datatransfer">データ通信</a></h3>
 632
 633     <p><a href="#figure3">図3</a>に示される SSL レコードプロトコル
 634     はクライアントとサーバ間のアプリケーションや
 635     SSL コントロールデータの通信に使われます。
 636     必要に応じてこのデータはより小さいユニットに分けられたり、
 637     いくつかの高級プロトコルをまとめて一ユニットとして通信が
 638     行なわれることもあります。
 639     データを圧縮し、ダイジェスト署名を添付して、
 640     これらのユニットを暗号化したのち、ベースとなっている
 641     信頼性のあるトランスポートプロトコルを用いるかもしれません。
 642     (注意: 現在メジャーな SLL 実装で圧縮をサポートしているものはありません)</p>
 643
 644     <p class="figure">
 645     <img src="../images/ssl_intro_fig3.gif" alt="" width="423" height="323" /><br />
 646     <a id="figure3" name="figure3"><dfn>図 3</dfn></a>: SSL レコードプロトコル
 647     </p>
 648
 649
 650 <h3><a name="securehttp" id="securehttp">HTTP 通信の安全化</a></h3>
 651
 652     <p>よくある SSL の使い方はブラウザとウェブサーバ間の HTTP 通信
 653     の安全化です。
 654     これは、従来の安全ではない HTTP の使用を除外するものではありません。
 655     安全化されたもの (HTTPS と呼ばれます) は、SSL 上での普通の HTTP で、
 656     URL スキームに <code>http</code> の代わりに <code>https</code>
 657     を用い、サーバで別のポートを使うことです (デフォルトでは443)。
 658     これが主に <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> が Apache
 659     ウェブサーバに提供する機能です。</p>
 660
 661 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 662 <div class="section">
 663 <h2><a name="references" id="references">参考文献</a> <a title="Permanent link" href="#references" class="permalink">&para;</a></h2>
 664
 665 <dl>
 666 <dt><a id="AC96" name="AC96">[AC96]</a></dt>
 667 <dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,
 668 1996. See <a href="http://www.counterpane.com/">http://www.counterpane.com/</a> for various other materials by Bruce
 669 Schneier.</dd>
 670
 671 <dt><a id="X208" name="X208">[X208]</a></dt>
 672 <dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation
 673 One (ASN.1)</q>, 1988. See for instance <a href="http://www.itu.int/rec/recommendation.asp?type=items&amp;lang=e&amp;parent=T-REC-X.208-198811-I">http://www.itu.int/rec/recommendation.asp?type=items&amp;lang=e&amp;parent=T-REC-X.208-198811-I</a>.
 674 </dd>
 675
 676 <dt><a id="X509" name="X509">[X509]</a></dt>
 677 <dd>ITU-T Recommendation X.509, <q>The Directory - Authentication
 678 Framework</q>. See for instance <a href="http://www.itu.int/rec/recommendation.asp?type=folders&amp;lang=e&amp;parent=T-REC-X.509">http://www.itu.int/rec/recommendation.asp?type=folders&amp;lang=e&amp;parent=T-REC-X.509</a>.
 679 </dd>
 680
 681 <dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>
 682 <dd><q>Public Key Cryptography Standards (PKCS)</q>,
 683 RSA Laboratories Technical Notes, See <a href="http://www.rsasecurity.com/rsalabs/pkcs/">http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>
 684
 685 <dt><a id="MIME" name="MIME">[MIME]</a></dt>
 686 <dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
 687 (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
 688 See for instance <a href="http://ietf.org/rfc/rfc2045.txt">http://ietf.org/rfc/rfc2045.txt</a>.</dd>
 689
 690 <dt><a id="SSL2" name="SSL2">[SSL2]</a></dt>
 691 <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>
 692
 693 <dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
 694 <dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
 695 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>
 696
 697 <dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
 698 <dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
 699 1999. See <a href="http://ietf.org/rfc/rfc2246.txt">http://ietf.org/rfc/rfc2246.txt</a>.</dd>
 700 </dl>
 701 </div></div>
 702 <div class="bottomlang">
 703 <p><span>翻訳済み言語: </span><a href="../en/ssl/ssl_intro.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
 704 <a href="../fr/ssl/ssl_intro.html" hreflang="fr" rel="alternate" title="Français">&nbsp;fr&nbsp;</a> |
 705 <a href="../ja/ssl/ssl_intro.html" title="Japanese">&nbsp;ja&nbsp;</a></p>
 706 </div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">コメント</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&amp;A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
 707 <script type="text/javascript"><!--//--><![CDATA[//><!--
 708 var comments_shortname = 'httpd';
 709 var comments_identifier = 'http://httpd.apache.org/docs/trunk/ssl/ssl_intro.html';
 710 (function(w, d) {
 711     if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
 712         d.write('<div id="comments_thread"><\/div>');
 713         var s = d.createElement('script');
 714         s.type = 'text/javascript';
 715         s.async = true;
 716         s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
 717         (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
 718     }
 719     else {
 720         d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
 721     }
 722 })(window, document);
 723 //--><!]]></script></div><div id="footer">
 724 <p class="apache">Copyright 2019 The Apache Software Foundation.<br />この文書は <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a> のライセンスで提供されています。.</p>
 725 <p class="menu"><a href="../mod/">モジュール</a> | <a href="../mod/quickreference.html">ディレクティブ</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">用語</a> | <a href="../sitemap.html">サイトマップ</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
 726 if (typeof(prettyPrint) !== 'undefined') {
 727     prettyPrint();
 728 }
 729 //--><!]]></script>
 730 </body></html>