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