この頁では、HTTPで使用される暗号化手法や、HTTPを利用する上でのセキュリティ上の問題について解説します。
HTTP アプリケーションを開発、実装する人、あるいはそれを使用する人も注意すべきものがセキュリティです。 多くの情報をやり取りする HTTP では、機密性の高い情報もそれに含まれるので、悪用されないようにその情報の管理が重要になってくるわけです。 しかし、HTTP が 利用している TCP/IP というプロトコルでは、いくつものサーバを経由してデータが転送するので、全ての転送途中の情報は盗み見されたり、書き換えられたりする可能性があり、それによって、深刻なセキュリティやプライバシー問題を引き起こしたり、なりすましが行われるかもしれません。
そこで、転送するデータを第三者が見ても分からないようにするために、通信データを暗号化する事が考えられました。 HTTP において、現在最も利用されている手法は SSL という Netscape Communications 社によって提案されたプロトコルです。 SSL は、送信中のデータの暗号化の他に、クライアントやサーバの認証を行う事もでき、データの盗聴や改竄、スプーフィング (なりすまし) 等を防ぎます。 OSI 参照モデルではトランスポート層 (第 4 層) にあたるプロトコルで、HTTP の他に FTP や SMTP 等のアプリケーションプロトコルでも利用できます。
SSL では、互いの認証に公開鍵暗号技術を用いています。 公開鍵暗号方式は、発信元でのデータの暗号化と、受信先でのデータの復号化に、異なる鍵を使用するのが大きな特徴です。 暗号化に使用される鍵を公開鍵、複合化にに使用される鍵を秘密鍵と言います。 公開鍵は、文字通り「広く公開しておく鍵」であり、秘密鍵は「生成したユーザが秘密にしておく鍵」です。 この 2 つの鍵の生成方式には、いくつかの種類がありますが、特に有名なアルゴリズムに、Rivest, Shamir, Adleman の 3 氏によって、1978 年に開発された RSA アルゴリズムがあります。 RSA 暗号を解読するには巨大な整数の素因数分解が必要があり、現在この暗号を解読する事は現実的には不可能であるとされています。
HTTP が SSL/TLS を利用する場合には、2 つの方法があります。
一つは専用のポート番号 (一般には 443) を使用して、初めから SSL/TLS 上でアプリケーションを実行する場合でというものです。
これは元々 Netscape 社によって提案された方法で、HTTPS と呼ばれ、HTTP に関する RFC としては HTTP Over TLS が公開されています。
もう一つは通常のポートでアプリケーションを起動後、SSL/TLS を呼び出して使用する方法で、HTTP/1.1 では Upgrading to TLS Within HTTP/1.1 にて Upgrade ヘッダを使って行う方法が示されています。
(※) 但し、現在では、専用ポートを利用する方法は IETF は非推奨としています。
通信連鎖上にプロクシなどが介在する場合には、CONNECTメソッドを使って、リクエストをトンネリングさせます。
この他の暗号化としては、Enterprise Integration Technologies 社によって提唱された SHTTP があり、その仕様は RFC 2660 として公開されています。 SSL/TLS は通信経路にセキュリティをかけるのに対し、SHTTP では送信される個々のデータにセキュリティをかけるもので、その目的が違うので、同時に使用する事ができます。 1995 〜 1996 年頃には、HTTPS と SHTTP のどちらが主要なセキュリティプロトコルになるかはわからない時代もあったようですが、現時点では明らかに HTTPS が主流となっており、SHTTP を実装するアプリケーションはありません。
SSL は、そのバージョン 1 の仕様が Netscape 社によって開発されてから、何度か改訂されています。 しかし、SSLv1 の仕様は、外部に公開されたり、実際に実装される事はありませんでした。 実際に利用され始めたのは SSLv2 で、1994 年 11 月に初めてその仕様が公開され、その後 1995 年 3 月に Netscape 1.1 に実装しました。 SSLv2 は、Netscape 社が内部のセキュリティ担当者を中心に開発され、外部の意見や他ベンダからの情報提供もほとんどないままに開発されたので、他ベンダが実装をしようとすると様々な問題が生じました。 1995年、Microsoft 社は SSLv2 のセキュリティホール上の重大な欠陥を修正した PCT を開発し、Internet Explorer 2.0 に実装しました。 SSL はプロトコル内にバージョン番号を持っていますが、PCT はこれを 2.0 としており、SSLv2 との下位互換性を維持していました。
SSLv2 の後継プロトコルとしては、SSLv2.1 というものが検討されていましたがそれは破棄され、新たなプロトコルの開発に取り組みました。 それが、SSLv3 です。 SSLv3 がリリースされたのは 1995 年末でした。 1996 年には、Microsoft は SSLv3 の修正版である STLP を提案して Internet Explorer に実装し、事実上 SSLv3 が主流となりました。
現在は、SSLv3 に若干の改良が加えられた TLS/1.0 が RFC 2246 として標準化されています。 TLS/1.0 は、厳密には SSLv3 の上位互換ではありませんが、実質的に SSLv3.1 とも言えるプロトコルで、実際にプロトコル内ではこの番号が使用されています。
SSLv3 による通信では、まずクライアントが ClientHello メッセージを送信し、サーバは ServerHello メッセージで応答します。
この hello 交換で、この通信での以下の情報を設定します。
ClientHello.random, ServerHello.random)これに成功すると、サーバは証明書認証局 (CA {certificate authorities}) によって証明された自らの証明書をクライアントに送信します。 証明書内にはサーバの公開鍵があり、この鍵をランダム値で暗号化して共有鍵が生成されます。 以降のデータのやり取りは全て共有鍵にて暗号化されます。
昨今、Web からの個人情報の流出が問題となっていますが、HTTP 経由でこれらの情報が流出しないように注意すべき事について RFC 2616 の section 15.1 に記述されています。
HTTP クライアントはしばしば多くの量の個人情報 (例えばユーザの名前、場所、メールアドレス、パスワード、暗号キー、等々) を管理しているので、この情報を HTTP プロトコル経由で他のリソースへと知らないうちに漏洩していないように特に気をつけるべきである。 我々は、ユーザがそのような情報の公開についてを制御するための便利なインタフェースが提供される事と、設計者や実装者はこの部分を特に注意する事を特に強く推奨する。 歴史的に、この部分のエラーがしばしば深刻なセキュリティやプライバシー問題を引き起こし、その結果実装者の会社に対して不利な評判を高めている。
HTTP クライアントの設計者やその実装者が、常に情報に敏感になり注意すべき事はもちろん、そのクライアントを使用するユーザも、クライアントの設計者や実装者からのアナウンスを定期的に受ける等して、そのセキュリティに関心を持つ必要があります。
個人情報の流出元として最も考えられるのが、HTTP サーバです。 ほぼ全てのサーバがクライアントからのアクセスをログを取得していますが、この情報の管理の重要性について、section 15.1.1 に記述されています。
サーバは、読み込みの傾向や興味の対象で識別されるであろうユーザのリクエストについての個人情報を保存する立場にある。 この情報は本質的に明らかに秘密であり、その扱いは国によっては法によって統制されているであろう。 データを供給するために HTTP プロトコルを使用している人々は、そのようなデータは発行された結果、身元がわかってしまうその個人の許可無しには配布されないという事を保証しなければならない。
サーバログに記録される情報の主なものとしては、以下のようなものがあります。
例えば、最もよく使用されている HTTP サーバである Apache では、以下のように記録されます。
127.0.0.1 - - [01/Jan/2004:00:00:00 +0900] "GET /security.html HTTP/1.1" 200 28158 "http://www.studyinghttp.net/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" |<-(1)->| |<----------(2)----------->| |<-----------(3)----------->| |<-(4)->| |<-----------(5)------------>| |<----------------------(6)----------------------->|
(※) もちろんこれは一例なので、これ以外の情報が記録されている可能性もあります。
特定のユーザは特定のクライアントから操作を行う場合が多いので、特定のクライアントからのアクセス情報を明らかにした場合、そのユーザに被害を与える可能性があります。 そのため、サーバ管理者はアクセスログ等の管理についてのセキュリティポリシーを設け、それを厳守する必要があります。
HTTP ヘッダとは、クライアントやサーバが、そのリソースに関連する情報やソフトウェア自身の情報をやりとりするために使用されるものです。 そのような性質を持つため、HTTP ヘッダにはユーザを特定するような情報が含まれる事になってしまいます。 section 15.1.2 をご覧下さい。
一般的なデータ転送プロトコルと同様に、HTTP は転送されるデータの内容を規制する事はできないし、与えられるリクエストの状況の中でその情報の特定の部分の機密性を決定するためのどんな優先的方法もない。 それ故に、アプリケーションはこの情報の供給者にできるだけ多くこの情報の制御機能を供給すべきである。 この状況において特に言及の価値がある四つのヘッダフィールドが Server, Via, Referer, From である。
これら四つのヘッダの意味については、それぞれ Server, Via, Referer, From をご覧下さい。
この他にも、section 15.1.4 では、Accept-Language の使用による民族差別の可能性を示唆しています。
Accept リクエストヘッダは、アクセスされたすべてのサーバにユーザに関する情報を表す事ができる。 特に Accept-Language ヘッダは、特定の言語を理解するという事がしばしば特定の民族グループの一員である事と強く関連付けられているため、個人的な性質であるとみなすであろう情報を表す。 リクエスト毎に送られる Accept-Language ヘッダの内容を設定するためのオプションを提供するユーザエージェントは、設定のプロセス中にそれがユーザのプライバシーの損失になるという事に気づかせるようなメッセージを含むようにする事が強く推奨される。
この他にも、例えば 基本認証 を使うと、WWW-Authenticate 中に暗号化されないパスワードが含まれる事になりますし、HTTP Cookie を利用して擬似的なセッションを実現しようとした時に、パスワードの暗号化を施さなければ、Cookie ヘッダ 中に暗号化しないパスワードが含まれてしまう事になります。
HTTP 利用者は、SSL 等で通信路を暗号化していない限り、HTTP ヘッダは常に盗聴される可能性があるという事を認識している必要があります。
スプーフィング{spoofing} は、「なりすまし」等と訳されます。 なりすましの危険性について、section 15.3 をご覧下さい。
HTTP を使用しているクライアントは Domain Name Service に非常に頼っており、従って一般的に IP アドレスと DNS 名の故意なる間違った組み合わせをベースとしたセキュリティアタックが行われる傾向にある。 クライアントは、IP アドレス/DNS 名の組み合わせの正当性の連続についての仮定にて注意深くある必要がある。
特に、HTTP クライアントは前回のホスト名 lookup の結果のキャッシュよりも、IP アドレス/DNS 名組み合わせの確認についてはそのネームリゾルバを頼るべきである。 多くのプラットフォームは適切な時期に既にローカルにホスト名 lookup をキャッシュできるので、そうするように設定すべきである。 しかし、これらの lookup はネームサーバによって報告された TTL (Time To Live) 情報がキャッシュされた情報がおそらく有効であるであろうとした時にのみキャッシュされるのが適切である。
もし HTTP クライアントがパフォーマンスを改善させるためにホスト名 lookup の結果をキャッシュするなら、DNS によって報告される TTL 情報を監視しなければならない。
もし HTTP クライアントがこの規定を守らないと、それらは直前にアクセスしたサーバの IP アドレスが変更された時にだまされる。 ネットワークの数値再割り当てがますます一般的になってくる事が予想されるため [24]、この形式のアタックの可能性は高くなる。 従って、この要求を監視する事によってこの潜在的なセキュリティの弱さを減らす。
また、この要求は同じ DNS 名を使用している複製されたサーバに対してクライアントのロードバランシング{load-balancing} 動作を改善し、この作戦を使うサイトをアクセスした場合にユーザが直面する失敗の可能性を減らす。
DNS とは、あるドメイン名とそれに対応する IP アドレスの変換を行う仕組みです。 しかし、この変換が正しく行われないと、意図しないホストへアクセスしてしまう事になります。 上の文書では、ホスト名をキャッシュしたデータが古くなっていた場合に意図しないアクセスをしてしまうという事が述べられていますが、この変換テーブルが悪意を持って変更された場合には、より深刻な被害を引き起こす可能性があります。
特に、ドメイン所有者と無関係な者が本来の所有者になりすまして登録情報の変更申請を行う等して、ドメインを管理するサーバのアドレスが本来のものとは別のものに書き換えられる事をドメインジャック (あるいはドメインハイジャック) と呼ぶ事があります。 ドメインジャックをされると、そのドメインは手続き上なりすましを行った者が所有している事になるので、そのドメインでアクセスされる Web も意図しないものに差し替えられてしまうだろうし、電子メールも本来の所有者が管理する所へは届きません。 従って、この問題は全てのドメイン管理者にとって関係のある問題です。 特にネームサーバを外部に委託しているような場合、そのネームサーバについてもドメインジャックを考慮する必要があるので、更なる注意が必要になります。
プロクシのセキュリティ問題について、section 15.7の中で記されています。
その性質から必然的に、HTTP プロクシは人と人の間に入り{men-in-the-middle}、中継者による攻撃{man-in-the-middle attacks} の機会が与えられる。 プロクシが運転されているシステムの妥協{compromise} が深刻なセキュリティとプライバシーの問題を引き起こす。 プロクシはセキュリティに関係した情報、ユーザ個人やその団体についての個別の情報、ユーザやそのプロバイダが所有する所有者情報にアクセスする。 妥協したプロクシや、セキュリティやプライバシーの問題に無関心に実装、形成されたプロクシは、様々な可能性を持つ攻撃に使われる。
プロクシのオペレータは、機密性の高い情報を含み、また転送するシステムを守るように、プロクシが運転しているシステムを守るべきである。 特に、プロクシによって集められたログ情報はしばしば特に機密性の高い個人情報や組織情報を含んでいる。 ログ情報は注意深く監視すべきであり、改善や更新のための使用にも適切なガイドラインを設けるべきである。 (section 15.1.1)
キャッシングプロクシは、キャッシュの内容が悪意ある利用には魅力的なターゲットを表しているので、潜在的な弱点が付け加えられる。 キャッシュの内容が HTTP リクエストが完了した後もずっと残っているので、キャッシュへのアタックでユーザがその情報はネットワークからは既に削除されたと信じているずっと後にその情報を見る事ができる。 それ故に、キャッシュの内容は機密性の高い情報として守られるべきである。
プロクシの実装者は、その設計やコーディングの決定、そしてプロクシオペレータへ提供する設定オプション (特に既定の設定) がプライバシーやセキュリティに関わるという事を考慮すべきである。
プロクシのユーザは、プロクシを運転する人間しか信頼する価値のある人はいないという事を知っておく必要がある。 HTTP 自身はこの問題を解決できない。
プロクシを介した HTTP サーバの場合、アクセスされたサーバからはまるでプロクシがクライアントとして動作しているように見えます。 このため、アクセス制限のされていないプロクシは、悪意を持つクラッカーがあるサーバを攻撃する際の中継地点として、また管理者の許可を得ずに使用しているユーザが匿名性向上のために、いわゆる踏み台として使われがちです。 この結果、プロクシの管理者が余計なトラブルに巻き込まれる可能性があります。 プロクシの管理者は、自身の管理するプロクシには適切なアクセス制限を施すべきでしょう。
また、プロクシを使用したとしても、プロクシのログ管理がずさんであった場合にはその効果が薄れてしまいます。 一般に、プロクシのログ情報は厳重に管理されるべきであり、その使用（第三者への公開等）には管理者の中で適切なガイドラインを設けるべきです。 プロクシのユーザは、そのプロクシを使うという事はそのプロクシの管理者を信頼したという事を表すという事をはっきりを理解していなければいけません。 しばしば、自身の匿名性を向上させたいがために、プロクシの管理者の許可を得ていないプロクシを使う人がいますが、その場合も上記の理由からその匿名性が十分に確保されているとは言えません。
サービス拒否攻撃 (DoS) とは、相手のコンピュータやルータなどに不正なデータを送信して、トラフィックを増大させる事によって、相手のネットワークを麻痺させ、サービスの提供を不能にさせる攻撃です。 また、多数のコンピュータを利用して、特定のサーバに向けて一斉にパケットを送出し、組織的にサービス拒否攻撃を行なう事を分散型サービス拒否 (DDoS) 攻撃といいます。 この攻撃では、実際にパケットを送る、すなわち攻撃を実行するコンピュータの管理者や利用者に攻撃の意図はなくても、無意識に攻撃の手助けをさせられてしまうという特徴があります。 この攻撃では、クラッカーが、パケットを送信させるための攻撃対象とは無関係なコンピュータに侵入し、トロイの木馬と呼ばれる攻撃実行用のプログラムをこっそりしかけます。 これによって、あらかじめ仕掛けたトロイの木馬にパケットの送出命令を発行すれば、一瞬のうちに、数百、または数千のコンピュータから、標的となったサーバに向けてパケットが送り込まれます。
プロクシを使ったサービス拒否攻撃について section 15.7.1 をご覧下さい。
この攻撃は存在する。この攻撃を防御する事は難しい。調査を続けよ。用心せよ。
基本的に、この攻撃は通常のアクセスと同様のプロセスをとるため、この攻撃を排除する事はできません。 但し、クラッカーにトロイの木馬を仕掛けられないように、各コンピュータの管理者が注意すれば、自分の管理するコンピュータが攻撃の踏み台に利用されるのを防ぐ事ができ、ネットワークの渋滞を引き起こさずにすむでしょう。 サーバの管理者は、自分が攻撃者とならない様に、定期的にスキャンを行うべきです。
, All Rights Reserved.
