INTERNET-DRAFT Ari Luotonen Expires: September 26, 1997 Netscape Communications Corporation March 26, 1997 WWWプロキシにおけるSSLトンネリング このメモの位置付け このドキュメントはインターネットドラフトである。インターネットドラフトは、 Internet Engineering Task Force(IETF)とそのエリア、そしてそのワーキング グループにおいて作成中のドキュメントのことである。その他のグループが、 作成中のドキュメントをインターネットドラフトとして配布することも認められ ている。 インターネットドラフトは最大6ヶ月間有効で、その後アップデートや置き換え をすることができる。もしくは、他のドキュメントによりいつでも無効にする ことができる。インターネットドラフトを参考文献として引用すること、もし くは "work in progress" 以上の扱いで引用するのは適切ではない。 インターネットドラフトの現在のステータスは、インターネットドラフトの ミラーサイトftp.is.co.za（アフリカ）、nic.nordu.net（ヨーロッパ）、 munnari.oz.au （太平洋岸）、ds.internic.net （US東海岸）、ftp.isi.edu （US西海岸）にある、"1id-abstracts.txt"のリストを参照のこと。 目次 * 概要 * 考察 * CONNECTメソッド * プロキシのレスポンス * セキュリティに関する考察 * 拡張性 概要 （Netscape Communications Corporationにより開発された）SSL (Secure Sockets Layer) の成功により、現在のWWWプロキシプロトコルを拡張し、 SSLクライアントがプロキシを通じてセキュアなトンネルをオープンできる ようにすることが、大変重要となっている。 HTTPSプロトコルはSSL上で動作するHTTPであるが、これは現在プロキシに より処理されている他のプロトコルと同様の方法によりプロキシ処理すること ができる。すなわち、プロキシにリモートHTTPSサーバとの間でセキュアな セションを開始させることで、HTTPSトランザクションを実行する。これはFTPや Gopherにおけるプロキシ処理と同じである。しかし、この方法には次の2つの 欠点がある。 * クライアントとプロキシの間のコネクションは通常のHTTPであり、それ ゆえセキュアではない。しかしこれは、クライアントが信頼のおける サブネットワーク（ファイアウォールの内側）にいる場合には許容 することができる。 * プロキシにおいて完全なSSLを実装している必要がある。 本ドキュメントでは、SSL実装をすることなくSSLをトンネリングする方法を 記述する。これは（HTTP/1.0仕様で定義されている）現在のWWWプロキシプロト コルと互換性をもつ。Netscape NavigatorとNetscape Proxy Serverで実装され ているSSLトンネリングは、この仕様書に従ったものである。この仕様を実装 したCERNプロキシサーバ(CERN httpd)用のパッチも存在する。 考察 SSLをトンネリングする際、プロキシは転送される双方向のデータにアクセス してはならない。これはセキュリティのためである。プロキシは単に、リク エスト元とリクエスト先のアドレス、そしてプロキシがユーザ認証をサポート している場合には、リクエストを行っているユーザ名を知るのみである。 クライアントとプロキシがハンドシェイクを行い、プロキシを通じてクライ アントとリモートサーバの間でコネクションを確立するとする。本仕様が 下方互換性をもつようにするため、このハンドシェイクはHTTP/1.0リクエスト と同じフォーマットで行われなければならない。そのため本仕様をサポート していないプロキシでは、リクエストに対するサービスを行うことができない ことを明確に決定することができ、そして適切なエラーレスポンスを返送 することができる（例えばコネクションがハングアップすることはない）。 SSLトンネリングは実際にはSSL仕様ではない。これはサードパーティーに対して 2点間のコネクションを確立させるための一般的な方法である。この後、この 中間者によりバイトデータがコピーされ送受信される。 SSLのソースコードにおいてSSLトンネリングサポートを行った場合には、 これはSSLサポートされたどのアプリケーションでも動作する。 CONNECTメソッド クライアントがプロキシに接続する際には、CONNECTメソッドを使用して、 接続するホスト名とポート番号を指定する。ホスト名とポート番号はコロンで 区切られる。ホスト名、ポート番号とも指定されていなければならない。 "ホスト名:ポート番号"部分の後に、1つのスペースと、HTTPバージョン番号を 示す文字列、すなわち"HTTP/1.0"が続き、そして行の終端文字（CRLFペアまたは LF）と続く。 そして0以上のHTTPリクエストヘッダ行があり、その後に1つの空行が続く。 それぞれのヘッダ行はCRLFペアまたはLFで終了する。空行は1つのCRLFペア またはLFである。 空行の後、コネクションを確立するためのハンドシェイクが成功すると、 SSLデータの転送を開始することができる。 例: CONNECT home.netscape.com:443 HTTP/1.0 User-agent: Mozilla/4.0 ...SSLデータ... この方法の利点は、プロトコルを自由に拡張することができることである。 例えば、プロキシ認証を使用することができる。 例: CONNECT home.netscape.com:443 HTTP/1.0 User-agent: Mozilla/4.0 Proxy-authorization: basic dGVzdDp0ZXN0 ...SSLデータ... プロキシのレスポンス リクエストにおける空行の後、クライアントはプロキシからのレスポンスを 待つ。プロキシはリクエストを検証してそれが有効であることを確認し、また ユーザはコネクションをリクエストする権限をもっていることを確認する。 もしすべてがうまくいけば、プロキシは目的となるサーバに対してコネク ションを確立しようとし、そしてもしそれが成功すれば、クライアントに 対して"200 Connection established"レスポンスを送信する。リクエストの 場合と同様、レスポンスはHTTP/1.0プロトコルに従う。そのためレスポンス行 はプロトコルバージョンを示す文字列から始まる。レスポンス行の後には 0以上のレスポンスヘッダ行が続き、その後に1つの空行が続く。行の区切り 文字はCRLFペアまたはLFである。 例: HTTP/1.0 200 Connection established Proxy-agent: Netscape-Proxy/1.1 ...SSLデータ... 空行の後、プロキシはクライアントとのコネクションで受信したデータを リモートサーバへ転送、またはその逆方向のデータ転送を開始する。接続中 には常に、それぞれのコネクションからデータを受信する可能性があり、 またそのデータは、他方のコネクションへ即座に転送すべきである。 ある時点で、どちらかのピアがコネクションを切断した場合には、そのピア から受信した未送信データは他方へ転送され、その後他方のコネクションを プロキシが切断する。コネクションを切断したピアへの未送信データが ある場合には、そのデータは破棄される。 セキュリティに関する考察 CONNECTは他のHTTPメソッドに比べるとかなり低レベルに位置する機能であり、 ある種のエスケープメカニズムである。すなわちプロキシはトランザクションに 対して何かしらの影響を与えるのではなく、単にデータ転送のみを行うべきで ある。これは、プロキシはアクセスを行おうとしている完全なURIを（プライ バシー、セキュリティのため）知るべきではなく、明らかに必要となる情報 （ホスト名とポート番号）のみ知る必要があるからである。このことから、 プロキシは通信しているプロトコルが本当にSSLであるかを確認することは できず、それゆえプロキシではSSLのウエルノウンポート（例えばHTTPSでは443、 SNEWSでは563であり、これらはInternet Assigned Numbers Authorityにより 割り当てられている）に対するコネクションのみにアクセスを許可するような、 明確な設定を行うべきである。 拡張性 SSLトンネリングハンドシェイクは、HTTP/1.0のヘッダを使用して自由に拡張 することができる。例えばプロキシ認証を行う場合には、プロキシは407 ステータスコードと（HTTP/1.0仕様書で定義されている）Proxy-authenticate レスポンスヘッダを使用して、クライアントに対し認証情報の送信を要求すれ ばよい。 HTTP/1.0 407 Proxy authentication required Proxy-authenticate: ... ...SSLデータ... クライアントはProxy-authorizationヘッダに認証情報を格納して送信する。 CONNECT home.netscape.com:443 HTTP/1.0 User-agent: ... Proxy-authorization: ... ...SSLデータ... 多重プロキシサーバ 本仕様書は、プロキシサーバ間の通信にも適用される。例えば、二重ファイア ウォールではこの通信が必要となる。この場合、内部プロキシは、外部プロキシ からはクライアントと見なすことができる。 参考文献 [HTTP/1.0] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [HTTP/1.1] R. Fiedling et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [SSL] K. Hickman, T. Elgamal, "The SSL Protocol", draft-hickman-netscape-ssl-01.txt, Netscape Communications Corporation, June 1995 [SSL3] A. O. Freier, P. Karlton, Paul C. Kocher, "The SSL Protocol -- Version 3.0", draft-ietf-tls-ssl-version3-00.txt, November 18, 1996 著者のアドレス Ari Luotonen Netscape Communications Corporation 501 E. Middlefield Road Mountain View, CA 94043 USA 日本語訳 西原 啓輔 2002年11月 訳者は、訳出した文書を利用することにより発生したいかなる損害に対しても 責任を負いません。 本文書には、技術的あるいは翻訳上の誤りがある可能性があります。技術的に 正しい知識を獲得しなければならない場合は、InterNIC/IETFから発行されて いる原文を参照してください。