[22] SOCKS は、 TCP アプリケーションのためのトンネル化プロトコルです。 防火壁等を越えて HTTP その他のアプリケーション層プロトコルで通信するために使います。
[54] SOCKS は TCP の上位層、アプリケーション層プロトコルの下位層として動作します。
[67] SOCKS には 4、4A、5 の3つの版があります。
[68] 最初に普及したのが 4 で、それにドメイン名対応を追加したのが 4A です。
[70] サーバーは 4/4A と 5 のいずれであるかを受信内容 (先頭1バイト) から区別できます。 4 と 4A のいずれであるかも実用上は区別できます。つまりサーバーはすべての版を同時に実装可能です。
[71] クライアントは 4、4A、5 のいずれを使うべきか事前の知識なく決めることができません。 この意味で版間の互換性がありません。
[163] クライアントは利用者にどの版を使うか指定させる必要があります。 SOCKS に対応したライブラリーの類は、3つの版のいずれかを指定する方法を提供しているのが普通です。 Firefox の設定画面では 4 と 5 のいずれかを指定できます。 PAC (>>73) は、 4 と 5 のいずれかを指定できます。
SOCKS5 と指定した時は、ドメイン名をそのまま使うようです。
[165] Chrome は 4 が選ばれた場合に 4 と 4A のどちらを使うかを次のように決めています
>>66。
[170] Firefox は名前解決に成功して IPv4アドレスを得たら 4 を使い、それ以外ではネットワークエラーとするようにみえます。
[174] Chrome も Firefox も名前解決結果が IPv4アドレス
0.0.0.0/8 だったら、名前解決に失敗したとしてネットワークエラーにするようです。
これを SOCKS4 で送信することはありませんから、 4A とサーバーに誤認されることはありません。
0.0.0.0 自体に接続しようとすると、
ERR_ADDRESS_INVALID エラーとなります (127.0.0.1 でサーバーが動作していても、
エラーになります)。その他の 0.0.0.0/8
に接続しようとすると、 ERR_ADDRESS_UNREACHABLE エラーとなります。
0.0.0.0/8 に解決される名前に接続しようとすると、
ERR_NAME_NOT_RESOLVED エラーとなります (名前解決できない時と同じエラーです)。
[141] SOCKS プロトコルの通信には、次の3種類のものが関わります。
[142] クライアントは、 SOCKS プロトコルの通信を開始します。 クライアントは SOCKS プロトコルを通じて他の (普通は防火壁の向こう側にあって SOCKS がないとアクセスできない) アプリケーションサービスを利用しようとするものです。
[143] サーバーは、 SOCKS プロトコルの通信を受け付けます。 SOCKS クライアントとの接続が確立されると、 クライアントが通信したい相手 (アプリケーションサーバー) との TCP 通信を中継することになります。
[144] UDP 中継サーバーは、 SOCKS5 UDP ASSOCIATE
により確立され、クライアントとクライアントが通信したい相手
(アプリケーションサーバー) との UDP 通信を中継することになります。
[147] SOCKS はクライアントがサーバーに接続して、 そのサーバーを介して他のサーバー (アプリケーションサーバー) に接続するものです。 SOCKS サーバーは防火壁であることが主として想定されていますが、 それに限られるわけではありません。いずれにせよ、クライアントが直接アプリケーションサーバーに接続するのではなく、 SOCKS サーバーをプロキシとして利用して通信するものです。
[148] SOCKS では TCP や UDP の通信を扱うことができます。 HTTPプロキシのようにアプリケーション層プロトコルの通信を解釈することなく、 透過的にクライアントとアプリケーションサーバーとの間の通信路として機能しますから、 アプリケーション層プロトコル側で特別な対応は必要ありません。
[146] 下位層として基本的には TCP を使います。 UDP ASSOCIATE
では UDP も使います。
[149] SOCKS プロトコル上のパケット単位は「メッセージ」 と呼ばれています。クライアントからサーバーへの指示のメッセージのことを要求、 サーバーからクライアントへの返答のメッセージのことを返信といいます。
[19] SOCKS 4 には CONNECT と BIND の2つの操作があります >>9。
[139] SOCKS 5 には CONNECT と BIND と
UDP ASSOCIATE の3つの命令があります。
[151] SOCKS 4 では操作と認証を同じメッセージでまとめて行います。
CONNECT の場合、一往復で SOCKS としての必要手続きは完了します。
[152] SOCKS 5 では版と認証方式の折衝、認証、命令の3段階があり、 最低 (認証なし) でも二往復しないといけません。
[160] SOCKS 4 も SOCKS 5 も、時代背景や標準化団体が IETF であることから、仕様書の規定はあまり明瞭ではなく、通信相手が仕様に反する場合の扱いも定かではありません。
VN4 とするべきです >>9。CDCONNECT では 1 とするべきで、
BIND では 2 としなければなりません >>9。DSTPORTDSTIPUSERIDNULL0 とします >>9。NULL0 とします >>14。[32] 明記されていませんが、 USERID やドメイン名に NULL
は含められないと思われます。 USERID やドメイン名を空 (長さ0)
にすることも禁止はされていません。
[49] SOCKS 4 では、 USERID の後の NULL までで終わりでした。
SOCKS 4A では、 DSTIP の先頭3バイトをすべて 0、
最終バイトを非 0 とすることで、ドメイン名とその終端の NULL
を使うことができます >>14。
[50] DSTIP の先頭3バイトが 0、最終バイトが非 0
の時、 IPアドレスではなく、ドメイン名の指定によることを表します >>14。
. で区切られたラベルの列と思われます。
時代的に ASCII のみのドメイン名が期待されていると思われますが、
非ASCII文字をどう扱うべきなのかは定かではありません。[172] Chrome も Firefox も認証には対応しておらず、
userid は常に空とするようです。
[48] 明記されていませんが、ネットワークバイト順と思われます。
[53] VN や CD が未知の値や想定外の文脈だった時にどう扱うべきかは定かではありません。
CONNECT 操作[20] クライアントは、他のホストに接続したい時、 SOCKS サーバーに接続して、
CONNECT 要求を送信します >>9。
[31] DSTIP は終点の IPアドレス
(またはドメイン名の指定があることを表す値 >>14)、
DSTPORT は終点のポート番号とします >>9。
[23] サーバーは、 CONNECT 要求を受信したら、
受け付けるかどうかを次の情報の一部または全部を使って検査します >>9。
[24] サーバーは、要求を受け付ける場合には、 指定された終点のホストとポートに接続します >>9。
[25] サーバーは、接続が確立されたら、 または拒絶する時や操作が失敗した時は、 返答パケットを送信します >>9。
[38] 返答パケットの DSTIP と DSTPORT は、無視します >>9。
[27] サーバーは失敗または拒絶を通知したら、直ちに接続を閉じます >>9。
[45] 一定時間 (例えば2分) 経過後接続が確立できていなければ、 断念してクライアントとの接続も閉じます >>9。
[171] Chrome も Firefox も、正しい結果 90 の返答でなければ、
TCP 接続を閉じてネットワークエラーとするようです。
[176] Chrome も Firefox も、要求への返答全体を受信するまで、 その内容の評価を行わないようです。
[177] Chrome も Firefox も、仕様通り返答中の IPアドレスとポート番号を無視するようです。
[175] 要求後 Chrome は 30s、 Firefox は 90s、 返答がなければタイムアウトとするようです。
BIND 操作[29] クライアントは、他のホストからの接続を受け付けたい時、
SOCKS サーバーに接続して BIND
要求を送信します >>9。
CONNECT で主たる接続を確立済みの同じアプリケーションでサーバーからクライアントへと補助的な接続を確立する
(のを待ち受ける) ためのもののようです。[33] DSTIP はアプリケーションサーバーの IPアドレス
(またはドメイン名の指定があることを表す値 >>14)、
DSTPORT は主たる接続のポート番号とします >>9。
[35] サーバーは、クライアントの情報により、 受け付けるかどうか決定します >>9。
[36] サーバーは、受け付ける場合も受け付けない場合も、 返答パケットを送信します >>9。
[40] 受け入れる場合 (CD = 90) は、
サーバーは接続を待ち受けることとし、そのIPアドレスとポート番号を返答パケットの
DSTIP と DSTPORT にそれぞれ設定します >>9。
[41] DSTIP が 0 (INADDR_ANY)
の場合、クライアントは、SOCKS サーバーの
IPアドレスとみなすべきです >>9。
[42] それ以外の場合は DSTIP と DSTPORT は無視されます >>9。
[43] サーバーが待ち受けるアドレスに接続があると、
次のようにします。
[44] 一定時間 (例えば2分) 経過後接続が確立できていなければ、 断念してクライアントとの接続も閉じます >>9。
[153] SOCKS 5 では最初にクライアントとサーバーの間で認証方式を折衝し、 それに応じて認証します。
[154] 更に認証後のメッセージその他の送受信におけるデータのカプセル化の方法は認証方式によって規定できます。 例えば認証方式によっては暗号化や署名の方法と構文を規定できます。
[99] 方式識別子 (METHOD) には次の値があります。
[101] METHOD の開発者は、 IANA登録簿に登録するべきです >>6。
[102] GSSAPI を実装しなければなりません >>6。
[103] USERNAME/PASSWORD を実装するべきです >>6。
[156] 0x03-0x7F はIANA登録簿 >>75 の登録対象 >>6
とされています。
[155] 実際幾つかの認証方式が開発され、 IANA登録簿 >>75 に登録されています。 実装も存在していたようです。しかしいずれも I-D のまま放置されています。
[158] Webブラウザーは、認証方式なし (0x00) にしか対応していないようです。
現在の SOCKS の利用の多くは同一環境で動作している SOCKSプロキシを使うものでしょうから、
認証は不要なのだと思われます。認証に対応するよう要望が出されてもいますが、
長年未対応のままで、それほど需要は大きくないようです。
[107] ATYP 欄は、 DST.ADDR 欄や BND.ADDR
欄のアドレスの種別を表すものです >>6。
[108] 次の値があります。
[159] FQDN は、時代的に IDN が考慮されておらず、どう扱われるのかは定かではありません。 また末尾の点の扱いも明確ではありません。更に FQDN と規定されてはいますが、 実際にはサーバーの名前解決の実装に依存する可能性もあります。
[88] TCP による接続は、クライアントから次のようにします。
[100] その後、クライアントとサーバーの間で方式依存の折衝を行います >>6。
[157] 認証方式が 0x00 の場合は、何もしないと思われます。
[179] Chrome も Firefox も、最初に受信した2バイトが 0x0500
でなければ TCP 接続を閉じます。(2バイトを受信するまで待ちます。)
[87] それに対してサーバーは、普通は始点と終点のアドレスを評価して、 適切な接続を確立して要求の種類に応じたメッセージを返すか、 または拒絶します >>6。
[123] 返答が失敗の時 (REP ≠ 0x00)、
サーバーは返答の送信のすぐ後に TCP接続を閉じなければなりません。
これは失敗検出の後10s以下でなければなりません。 >>6
[124] 返答が成功の時 (REP = 0x00) で要求が
BIND や CONNECT なら、
クライアントはデータを送信できるようになります >>6。
サーバーは受信したデータをクライアントに送信します。
[125] 認証方式が規定する場合は、クライアントやサーバーは送信するデータを適当にカプセル化しなければなりません >>6。
[178] Chrome も Firefox も、 BND.ADDR の第1バイトまで読み込んでから、
そこまでの各バイトを評価して、問題があればエラーとして TCP 接続を閉じます。
[180] 返答待ちのタイムアウトは Chrome は30s、 Firefox は90sのようです。
[186] サーバーやクライアントは相手のメッセージの受信をまたずに自身のメッセージ (や確立後の TCP データ) を送信できてしまいます。そのような場合に受信者がこれをどう処理するべきかは不明です。
CONNECT 要求[114] CONNECT 要求に対する返答の場合、
BND.PORT はサーバーが対象ホストへの接続に割り当てたポート番号、
BND.ADDR は関連付けられた IPアドレスです >>6。
[116] BIND 要求は、サーバーからの接続を受け付ける必要がある時に使います 。
CONNECT 要求により確立された主たる接続の後に二次的な接続を確立するために使うことを想定しています。
BIND 要求の評価には要求の DST.ADDR
と DST.PORT っを使うことが想定されています。 >>6
[181] Chrome でも Firefox でも、 BND.ADDR と
BND.PORT は無視されます。しかし何らかの適切な ATYP
と ATYP に応じだ BND.ADDR を指定しなければエラーになります。
BIND 要求[115] BIND 要求によってサーバーが新しいソケットを作成、
束縛したら、クライアントに最初の返答を送信します。
ここでは、 BND.PORT に接続を待つべく listen
するよう割り当てたポート番号を、
BND.ADDR には関連付けられたIPアドレスを指定します。 >>6
[117] その後当該ソケットへの接続が成功または失敗したら、
次の返答を送信します。
BND.PORT と BND.ADDR
は、接続してきたホストのポート番号とアドレスとします。 >>6
UDP ASSOCIATE 要求[118] UDP ASSOCIATE 要求は、
UDP データグラムの中継を確立するものです。 >>6
[119] 要求の DST.ADDR と DST.PORT
は、クライアントが UDP データグラムを送信したいアドレスとポートです。
クライアントが UDP ASSOCIATION 要求の送信時点で決定できないときは、
ポート番号 0 を使わなければなりません。
>>6
[120] サーバーは、 UDP ASSOCIATE 要求の
DST.ADDR や DST.PORT に基づきアクセスを制限できます。
>>6
[121] UDP ASSOCIATE 要求による UDP との関連付けは、
当該 TCP接続が終了した時に終了します。 >>6
[122] UDP ASSOCIATE 要求への返答では、
BND.PORT と BND.ADDR
には(中継されることとなる) UDP の宛先としてクライアントが使うべきポート番号とアドレスを指定します。
>>6
[129] UDP を使うクライアントは、
UDP ASSOCIATE 要求に対する返答の UDP 中継サーバーの
BND.PORT で指定された UDP ポートに対してデータグラムを送信しなければなりません >>6。
[130] 認証方式が規定する場合は、データグラムを適当にカプセル化しなければなりません >>6。
[131] 各 UDP データグラムには、 UDP要求ヘッダーを付します。
UDP要求ヘッダーは次の欄で構成されます。 >>6
[132] UDP 中継サーバーは、 UDP データグラムを中継することにした場合は、 そうします。中継しないまたはできない場合は、単に無視します。 >>6
[133] UDP 中継サーバーが遠隔ホストから返答データグラムを受信したら、 UDP 要求ヘッダーと認証方式依存の方法でカプセル化しなければなりません。 >>6
[134] UDP 中継サーバーは、UDP ASSOCIATE
要求への返答の BND.PORT で示されたポートにデータグラムを送ることになるクライアントの想定
IPアドレスを SOCKS サーバーから得なければなりません。
それ以外の始点 IPアドレスからのデータグラムを無視しなければなりません。
>>6
[135] FRAG 欄は、当該データグラムが素片 (断片)
群の1つを構成するかどうかを表します。
0x00 は単独のデータグラムを表します。
最上位ビットが最後の素片を表します。
下位7ビットが素片の列における位置を表します。
>>6
[136] 受信者は素片について REASSEMBLY QUEUE と
REASSEMBLY TIMER を持ちます。REASSEMBLY TIMER
は5s未満であってはなりません。 REASSEMBLY TIMER
が満期になったり、これまでの最高の FRAG 値よりも小さな
FRAG 値のデータグラムを受信したりしたら、
REASSEMBLY QUEUE を最初期化しなければなりません。 >>6
[137] アプリケーションは、可能な限り素片化 (断片化) を避けるべきです。
素片化を実装する必要はありません。未対応の実装が FRAG
値 0x00 以外のデータグラムを受信したら、
無視しなければなりません。 >>6
[138] SOCKS 対応 UDP の API は、 OS が提供するバッファーの最大サイズよりも次のバイト数だけ小さな値を利用可能なサイズとして報告しなければなりません。 >>6
[161] 下位層プロトコルとして TCP や一部 UDP を使いますが、 その方法は明確ではありません。
[162] 例えば緊急ポインターが指定されている時どう扱うべきなのか、
RST を受信したらどうするべきなのかなど明確な規定はありません。
[85] SOCKS5 では、普通は 1080 番ポートを使います >>6。
[77] TCP と UDP のポート番号 1080 はサービス
socks として IANA登録簿に登録されています。
説明は「Socks」となっています。 >>76
[74] プロキシの指定などで URL を指定する時に、次の URL scheme が用いられます。
[128] SOCKS のサーバーとクライアントの実装として、 Dante があります。
[127] Webブラウザーをはじめ、多くのインターネットアプリケーションのクライアントプログラムやライブラリーが SOCKS クライアント機能を持っています。
[126] socksify (dante) や tsocks のような、 SOCKS を実装していないプログラムの TCP/IP 接続部分を SOCKS 利用に差し替えるプログラムもあります。
"socks4://10.0.0.1:1080 socks5://root:123@10.0.0.2:1080 socks4a://85.224.100.1:9010"
http_get 'http://www.google.com/', socks => 'socks5://localhost:1080', sub {[4] LWP::Protocol::socks - search.cpan.org ( 版) <http://search.cpan.org/~scr/LWP-Protocol-socks-1.1/lib/LWP/Protocol/socks.pm>
プロキシサーバのアドレスを入力します SOCKSプロキシのためのアドレス形式は次のとおりです。
socks://username@socks_server:port/network/netmask,network/netmask...プロキシサーバ設定の例:
socks://socks.ssh.com:1080/203.123.0.0/16,198.74.23.0/24
[2] SOCKS - Wikipedia ( ( 版)) <http://ja.wikipedia.org/wiki/SOCKS>
[13] SOCKS - Wikipedia, the free encyclopedia ( 版) <https://en.wikipedia.org/wiki/SOCKS>
[11] RFC 3089 - A SOCKS-based IPv6/IPv4 Gateway Mechanism ( 版) <https://tools.ietf.org/html/rfc3089>
[15] IO::Socket::Socks - search.cpan.org ( 版) <http://search.cpan.org/dist/IO-Socket-Socks/lib/IO/Socket/Socks.pm>
[16] 第 15 章 SOCKS の使用 ( 版) <https://docs.oracle.com/cd/E19438-01/819-3160/agsocks.html>
[17] Socks Proxy - Free Socks5 and Socks4 Proxy List ( 版) <http://www.socks-proxy.net/>
[18] >>17 によれば 5 が多いですが、 4 (4 か 4a かは不明。) もまだまだ使われているようです。
Since 7.21.7, this option is superfluous since you can specify a socks5 hostname proxy with -x, --proxy using a socks5h:// protocol prefix.
As part of the GSS-API negotiation a protection mode is negotiated. RFC 1961 says in section 4.3/4.4 it should be protected, but the NEC reference implementation does not. The option --socks5-gssapi-nec allows the unprotected exchange of the protection mode negotiation. (Added in 7.19.4).
[58] 280661 – SOCKS proxy server connection timeout hard-coded ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=280661>
[59] 16103 – SOCKS V5 Implementation ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=16103>
[60] 133939 – [RFE] SOCKS: cannot use kerberos v5 (GSS-API) authentication with ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=133939>
[61] 78176 – PAC: SOCKS return value is not version specific ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=78176>
[62] Configuring a SOCKS proxy server in Chrome - The Chromium Projects ( 版) <https://www.chromium.org/developers/design-documents/network-stack/socks-proxy>
[63] Issue 29914 - chromium - DNS queries not forwarded through SOCKS v5 proxies - An open-source project to help move the web forward. - Google Project Hosting ( 版) <https://code.google.com/p/chromium/issues/detail?id=29914>
[64] Issue 469 - chromium - Support SOCKS proxy - An open-source project to help move the web forward. - Google Project Hosting ( 版) <https://code.google.com/p/chromium/issues/detail?id=469>
303 // Resolving the hostname failed; fail the request rather than automatically
304 // falling back to SOCKS4a (since it can be confusing to see invalid IP
305 // addresses being sent to the SOCKS4 server when it doesn't support 4A.)
210 if (ok) {
211 DCHECK(addresses_.head());
212
213 // If the host is resolved to an IPv6 address, we revert to SOCKS4a
214 // since IPv6 is unsupported by SOCKS4/4a protocol.
215 struct sockaddr *host_info = addresses_.head()->ai_addr;
216 if (host_info->sa_family == AF_INET) {
217 DLOG(INFO) << "Resolved host. Using SOCKS4 to communicate";
218 socks_version_ = kSOCKS4;
219 } else {
220 DLOG(INFO) << "Resolved host but to IPv6. Using SOCKS4a to communicate";
221 socks_version_ = kSOCKS4a;
222 }
223 } else {
224 DLOG(INFO) << "Could not resolve host. Using SOCKS4a to communicate";
225 socks_version_ = kSOCKS4a;
226 }
[57] 122752 – SOCKS: Username/Password Authentication (V5) ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=122752>
[82] Dante - Documentation ( 版) <https://www.inet.no/dante/doc/>
None: No authentication. However, data is encrypted if the Secure Sockets Layer (SSL) option is also selected.
Clear Text User/Password: During Novell IP Gateway user authentication, the user’s password is transmitted across the wire in clear text without encryption. The password is checked against the password stored in NDS, but this is not the same as NDS authentication. However, if SSL is also selected, the password is encrypted before being sent.
NDS User/Password: The user is authenticated using the NDS username and password with a scheme that protects the secrecy of the password. However, data is not encrypted unless the SSL option is also selected. This option works only if the SOCKS 5 client software supports NDS authentication.
SSL: The SSL option requires that an SSL connection between the client and the server be established before the Novell IP Gateway can authenticate a user by using any of the other authentication schemes. Enabling this option also ensures the encryption of all data transmitted between the client and the server.
Key ID: If you select the SSL authentication scheme, you must also select a Key ID from the drop-down list. At least one Key ID must be created for the server in NDS prior to the selection of SSL. Novell Public Key Infrastructure (PKI) Services must be installed on your server.
[183] 284371 – SOCKS4A support () <https://bugzilla.mozilla.org/show_bug.cgi?id=284371>
[184] 134105 – SOCKS5: DNS lookups (host resolving) should occur on proxy, not client side. () <https://bugzilla.mozilla.org/show_bug.cgi?id=134105>
[187] Limit valid range for socksVersion (shs96c著, ) <https://github.com/w3c/webdriver/commit/afb549ef09f36053f027cc53b2528f14c3aee908>
[188] Socks Proxy requires Socks Version (shs96c著, ) <https://github.com/w3c/webdriver/commit/01d01ab530d7070372af9ec4fd486c0f5b478543>
[189] SOCKS Proxies in Internet Explorer – IEInternals () <https://blogs.msdn.microsoft.com/ieinternals/2010/10/08/socks-proxies-in-internet-explorer/>