仕様書

[49] RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (2014-06-07 01:55:45 +09:00 版) https://tools.ietf.org/html/rfc7231#section-4.3.6
[45] RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (2014-06-07 01:59:35 +09:00 版) https://tools.ietf.org/html/rfc7230#section-3.3
[10] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-7
[12] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-8.3
[32] RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) (2015-05-15 10:14:54 +09:00 版) https://tools.ietf.org/html/rfc7540#section-10.5.2

意味

[50] CONNECT メソッドは、要求対象によって識別される起源鯖を出口とするトンネルを確立し、成功した場合には、トンネルが閉じられるまでの間、パケットを盲目的に転送するだけの動作をすることを受信者に対して要求するものです >>49。

C: クライアント
P: 串
S: 鯖
C -> P: 鯖への CONNECT 要求
P ## S: 接続の確立
P -> C: 200 応答
C ## S: 以後串は無変更で鯖・クライアント間を中継
C ## S: 串は一方の接続が閉じられたら、他方の接続も閉じる

[65] CONNECT は、動作としては Upgrade: によるプロトコルの切り替えと然程違いません。どちらも一旦切り替えられると元の HTTP とは異なるプロトコルの規定に支配される接続となり、基本的に元の HTTP に戻ってくることはできません。それでも Upgrade: は理論上は元の要求の処理を鯖が新しいプロトコルで継続することが期待されるのに対し、 CONNECT は新しいプロトコルではじめから通信が始まることが期待されています。また Upgrade: は受信者である鯖が直接処理することを期待されているのに対し、 CONNECT は受信者自身ではなく中継された先にあるはずの鯖が処理することが期待されているという大きな違いがあります。

[14] CONNECT メソッドは、主として HTTP プロキシを通して https 資源にアクセスするために起源サーバーとの間に TLSセッションを確立するために使います >>12。

[15]

RFC 7540 は CONNECT のことを「疑似メソッドpseudo-method」と呼んでおり

>>12

、それがどういう意味かは不明ですが、通常の要求メソッドとは性質が違うことをほのめかしています。

[16] HTTP/2 では CONNECT メソッドは、 (接続全体ではなく) ストリームにおいてトンネルを確立するために使います >>12。

[48] このような動作をするものは一般的にはプロキシと呼ばれていますが、 RFC 7230 の用語では中間器の一種であるトンネルに分類されています。

文脈

[75] CONNECT メソッドは、 HTTPS の通信にプロキシを通過させたい時に使われます。

[76] 素のHTTPのプロキシは、プロキシに素のHTTPで接続し、プロキシがこれを一旦解釈してから接続先のサーバーへと中継します。しかし、これと同じ方法では HTTPS の TLS の目的である盗聴や改竄の防止が実現できません (プロキシの挙動は盗聴と改竄そのものだからです)。そのため、プロキシがデータを無条件に中継し何の解釈も行わないトンネルモードへと CONNECT メソッドで切り替えてから、 TLS でサーバーとの間を結ぶ方法を採るのです。

[78] プロトコルの階層関係を図にすると、次のようになります。

     <----------------- HTTP ---------------->
     <----------------- TLS ----------------->
     <- HTTP (CONNECT) -> <------ TCP ------->
     <------ TCP ------->
クライアント         プロキシ             サーバー

構文

[54] HTTP/1.1 以下の CONNECT 要求の要求対象は、 authority-form でなければなりません >>49。

[17] HTTP/2 では、疑似ヘッダーを次のようにします。

[18] :method は、 CONNECT とします >>12。
[19] :scheme は、省略しなければなりません >>12。
[20] :path は、省略しなければなりません >>12。
[21] :authority は、ホストとポートを指定します。要求対象の authority-form に相当します。 >>12

[62] CONNECT 要求の payload の意味は定義されていません。 >>49

[63]

payload body があると実装によっては要求を拒絶するかもしれません。

>>49

[34] Chrome は次のヘッダーを指定するようです。 2015-08-04T10:02:41.00Z

HTTP/1.1
Host:
Proxy-Connection: keep-alive
User-Agent:

[35] Firefox は次のヘッダーを指定するようです。 2015-08-04T10:02:41.00Z

HTTP/1.1
User-Agent:
Proxy-Connection: keep-alive
Connection: keep-alive
Host:

[36] IE は次のヘッダーを指定するようです。 2015-08-04T10:02:41.00Z

HTTP/1.0
User-Agent:
Connection: keep-alive
Content-Length: 0
Host:
Pragma: no-cache

性質

[64] CONNECT 要求に対する応答は、キャッシュ可能ではありません >>49。

処理

[51] CONNECT 要求は串に対する要求での利用のみを想定しています >>49。

[22] HTTP/2 で >>17 の疑似ヘッダーの制約に違反する場合は、奇形です >>12。

[55] 串は、要求対象に直接接続しても構いませんし、他の串を使うよう設定されている場合には次の内向きの串に CONNECT 要求を転送しても構いません >>49。

[84] MITM proxy として動作するプロキシは、自身が CONNECT のデータを読み書きする HTTPS サーバーとして動くことになります。 MITM proxy

[23] CONNECT に対応する HTTP/2 プロキシは、 :authority 疑似ヘッダーで識別されるサーバーへの TCP接続を確立します。確立に成功したら、状態符号 2xx の HEADERS フレームをクライアントに送信します。 >>12

[52] 自身への CONNECT 要求を受信した起源鯖は、接続が確立されたことを示す 2xx 応答を返しても構いません >>49。

[57]

持続接続により引き続き HTTP の接続の処理が継続されているのか、 CONNECT によってトンネルとして動作しているのか、クライアント側から判別する方法はありません。

[53] ただしほとんどの起源鯖は、 CONNECT を実装していません

>>49

。

[60] トンネルの確立は大きな危険を生じさせるものですから、串は、既知のポートや安全な要求対象のホワイトリストにより、 CONNECT の利用を制限するべきです >>49。

[46] CONNECT 要求に対する 2xx 応答は、メッセージ本体を持ちません >>45, >>49。

[24] HTTP/1.1 以下では、メッセージ本体の代わりに、ヘッダーの次の CRLF の直後から、トンネルモードに切り替わります。 >>45, >>49

[61] 鯖は、 Transfer-Encoding: や Content-Length: を 2xx 応答に含めてはなりません >>49。クライアントはこれらを無視しなければなりません >>49。

[25] HTTP/2 では、最初の HEADERS フレームの後、以後のすべての DATA フレームは TCP接続上のデータに対応します。クライアントから送信された DATA フレームはプロキシから TCPサーバーへと送信され、 TCPサーバーから受信したデータはプロキシからクライアントへと DATA フレームで送信されます。 >>12

[26] DATA フレームとストリーム管理のためのフレーム (RST_STREAM, WINDOW_UPDATE, PRIORITY) を除き、当該ストリームを使って送信してはならず、受信したらストリームエラーとしなければなりません。 >>12

[56] 2xx 以外の応答は、トンネルが形成されていないことを表し、トンネルとしてではなく HTTP による解釈を継続するべきものです >>49。

[58] HTTP/1.1 以下のトンネルは、そのいずれかの側の接続が閉じられたと検出した時、閉じられます。その場合、閉じられた側からの残りのデータをすべて送信し、両方の接続を閉じ、残ったデータがあれば捨てる、という処理を試みなければなりません。 >>49

[27] HTTP/2 では END_STREAM フラグが TCP FIN フラグに相当します。クライアントは、 END_STREAM フラグが設定された DATA フレームを受信したら、 END_STREAM フラグが設定された DATA フレームを送信することが期待されています。プロキシは、END_STREAM フラグが設定された DATA フレームを受信したら、 FI ビットを設定した TCPセグメントを最後に送ります。プロキシは FIN ビットが設定された TCPセグメントを受信したら、 END_STREAM フラグが設定された DATA フレームを送信します。 >>12

[28] 最後の DATA フレームや TCPセグメントは、空になることもあります。

>>12

[29] HTTP/2 プロキシは、 RST ビットが設定された TCPセグメントをはじめとする TCP接続のエラーを検出したら、ストリームエラー CONNECT_ERROR とします。 >>12

[30] HTTP/2 プロキシは、 HTTP/2 のストリームや接続でエラーを検出したら、 RST ビットが設定された TCPセグメントを送信しなければなりません >>12。

[31]

HTTP/1.1 以下でも同じようにエラー処理が必要なのかもしれませんが、 RFC では規定されていません。

[33] CONNECT は、 TCP接続を維持しなければならず、その分の資源を消費することに注意が必要です。 CONNECT が閉じられた後も TIME_WAIT 状態の間、 TCP接続の情報を残す必要があることにも注意が必要です。設定 SETTINGS_MAX_CONCURRENT_STREAMS とは別に CONNECT の資源消費にも制限が必要かもしれません。 >>32

[6] トンネル内では HTTPS (HTTP over TLS) を用いるのが主たる用途ですが、 TCP で動作する任意のプロトコルを使うことができます。トンネルとしてはどのようなプロトコルが使われているか感知しません。

[37] HTTPS プロキシとしての利用の際、 Firefox は応答を待たずにヘッダーと空行の後直ちに TLS を開始します。 Chrome と IE は、応答を待ちます。応答が 200 以外の場合、 Chrome と IE は接続を閉じますが、 Firefox は接続が閉じられるのを待ちます。ただし 101 なら直ちに閉じます。 2015-08-04T10:16:18.800Z

[83] curl は 200 以外の 2xx をエラーとして扱います。 2018-08-30T15:29:36.00Z

[80] 仕様上は 200 以外の 2xx を返すこともできますが、実際には使えないということです。サーバーとクライアントで何をトンネルと解釈するかが異なると HTTP としての解釈とトンネルデータの区分が両者で異なり、セキュリティー問題を引き起こす危険性があります。クライアントは Chrome 同様にエラーと扱うべきでしょう。

[77] 仕様上は CONNECT 要求に対して 200 以外の応答を返した場合に、持続的接続で次の要求を送ることができます。実際には Webブラウザーは 407 でHTTP認証情報付きで CONNECT を再送信する以外で失敗した接続を再利用することはありません。また、 CONNECT 以外で使ったHTTP接続に CONNECT を送信することもありません (が認められてはいます)。

[79] 応答を待たずに要求直後にトンネルデータの送信を開始する場合、 200 以外の応答が返った場合に次の要求を送れないことになります。場合によっては、トンネルデータがHTTP要求と解釈されてしまい困るかもしれません。

[68] Firefox と Chrome は HTTP/0.9 応答をネットワークエラーとします。 2015-09-14T02:31:35.100Z

[69] Firefox も Chrome も、 HTTP/1.0 か HTTP/1.1 かは動作に影響しません。 2015-09-14T02:36:03.800Z

[38] Firefox も Chrome も IE も、 1xx はエラーとみなし、その後の応答を待ちません。 2015-08-04T10:19:45.500Z

[39] Firefox も Chrome も IE も、 407 で Proxy-Authenticate: があれば、モーダルダイアログを表示します。 2015-08-04T10:26:52.400Z

[40] Firefox と Chrome は持続的接続により 407 の接続を再利用しようとします。 IE は再利用しないようにみえます (が条件次第で再利用するかもしれず断言はできません)。 2015-08-04T10:32:16.00Z

[41] Chrome も IE も 200 応答の Content-Length: は無視するようです。しかし Chrome は Content-Length: が不正かどうかのチェックは行っているようです。 2015-08-04T11:33:28.00Z

[42] Chrome も Firefox も IE も、 200 応答の Connection: close や Proxy-Connection: close は無視するようです。 2015-08-04T11:44:09.700Z

誤り符号 `CONNECT_ERROR`

[11] 誤り符号 CONNECT_ERROR (0xa) は、 CONNECT 要求により確立された接続が再設定または異常に閉じられたことを表します >>10。

セキュリティー

[71] CONNECT は、そのサーバーから接続可能な任意の TCP サーバーに、任意のプロトコルでアクセスできます。従って、杜撰な実装や設定のサーバーは、攻撃の踏み台として使われてしまいます。

[72] 例えば、イントラネットに接続されたサーバーが外部からアクセス可能になっていて、 CONNECT による接続先の制限が何もなければ、外部からイントラネットに自由にアクセスできるセキュリティーホールでしかありません。

[73] このため CONNECT メソッドは危険だと言われることがしばしばありますが、どちらかといえばプロトコルが危険なのではなくサーバーの開発者や管理者の責任でしょう。

歴史

draft-luotonen-web-proxy-tunneling (1998)

[1] draft-luotonen-web-proxy-tunneling - Tunneling TCP based protocols through Web proxy servers http://tools.ietf.org/html/draft-luotonen-web-proxy-tunneling

RFC 2616

[2] RFC 2616 (HTTP/1.1) 9.9 CONNECT

This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).
この仕様書は、方式名 CONNECT を、動的にトンネルになるように切り替える串 (たとえば SSL トンネル化) で使うために予約します。

RFC 2817

[4] RFC 2817 が CONNECT 要求メソッドを初めて正式に規定する仕様書となりました。

[8] RFC 2817 は >>1 に言及しつつ、既に串で広く実装されている >>3 と述べています。

[3] RFC 2817 - Upgrading to TLS Within HTTP/1.1 (2012-01-09 20:05:09 +09:00 版) http://tools.ietf.org/html/rfc2817#section-5

RFC 723x

[7] RFC 7230 と RFC 7231 により RFC 2817 が更新され、より正確に動作が規定されるようになりました。これにより RFC 2817 の該当部分の規定は失効したものと考えられます。

[13] RFC 7540 >>12 は HTTP/2 における用法を規定しています。

仕様書

意味

文脈

構文

性質

処理

誤り符号 CONNECT_ERROR