[22] SOCKS は、 TCP アプリケーションのためのトンネル化プロトコルです。 防火壁等を越えて HTTP その他のアプリケーション層プロトコルで通信するために使います。

[54] SOCKS は TCP の上位層、アプリケーション層プロトコルの下位層として動作します。

仕様書

版

[67] SOCKS には 4、4A、5 の3つの版があります。

[68] 最初に普及したのが 4 で、それにドメイン名対応を追加したのが 4A です。

[69] IETF で改めて作られたのが 5 です。

[70] サーバーは 4/4A と 5 のいずれであるかを受信内容 (先頭1バイト) から区別できます。 4 と 4A のいずれであるかも実用上は区別できます。つまりサーバーはすべての版を同時に実装可能です。

[71] クライアントは 4、4A、5 のいずれを使うべきか事前の知識なく決めることができません。 この意味で版間の互換性がありません。

[72] IETF ではよくあることですが、 IETF の専門家好みのスタイルにプロトコルが改造された結果互換性が無くなり、 旧版から新版への移行が進まず、かといって新版が無視されるわけでもなく、 新旧両版が十数年以上も併用され続けています。

[163] クライアントは利用者にどの版を使うか指定させる必要があります。 SOCKS に対応したライブラリーの類は、3つの版のいずれかを指定する方法を提供しているのが普通です。 Firefox の設定画面では 4 と 5 のいずれかを指定できます。 PAC (>>73) は、 4 と 5 のいずれかを指定できます。

[164] Firefox の設定画面では、 5 を選んだ場合のみ、更に名前解決して IPアドレスを使うか、ドメイン名をそのまま使うか指定できます。 PAC で SOCKS5 と指定した時は、ドメイン名をそのまま使うようです。

[165] Chrome は 4 が選ばれた場合に 4 と 4A のどちらを使うかを次のように決めています >>66。

  1. [166] 名前解決に成功したら、
    1. [167] 結果がIPv4アドレスなら、 4 を使います。
    2. [168] 結果がIPv6アドレスなら、 4A を使います。
  2. [169] 名前解決に失敗したら、 4A を使います。

[173] が実際ためしてみると名前解決に成功して IPv4アドレスを得た場合以外名前解決失敗でネットワークエラーになっているように見えます。

[170] Firefox は名前解決に成功して IPv4アドレスを得たら 4 を使い、それ以外ではネットワークエラーとするようにみえます。

[174] Chrome も Firefox も名前解決結果が IPv4アドレス 0.0.0.0/8 だったら、名前解決に失敗したとしてネットワークエラーにするようです。 これを SOCKS4 で送信することはありませんから、 4A とサーバーに誤認されることはありません。

[185] Windows の Chrome で 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 エラーとなります (名前解決できない時と同じエラーです)。
[140] SOCKS プロトコルの版の比較
v
版
ipv4
IPv4
ipv6
IPv6
domain
ドメイン名
auth
認証方式
tcp
TCP
udp
UDP
v
4
ipv4
○
ipv6
×
domain
×
auth
名前
tcp
○
udp
×
v
4A
ipv4
○
ipv6
×
domain
○
auth
名前
tcp
○
udp
×
v
5
ipv4
○
ipv6
○
domain
○
auth
認証なし、GSSAPI、名前と合言葉
tcp
○
udp
○

端点

[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 プロトコル上のパケット単位は「メッセージmessage」 と呼ばれています。クライアントからサーバーへの指示のメッセージのことを要求request、 サーバーからクライアントへの返答のメッセージのことを返信replyといいます。

[150] ただし SOCKS としての初期化が終わった後はアプリケーション層のデータをそのまま送受信するモードになりますから、 SOCKS プロトコルのメッセージとはなりません。

[19] SOCKS 4 には CONNECT と BIND の2つの操作operationがあります >>9。

[139] SOCKS 5 には CONNECT と BIND と UDP ASSOCIATE の3つの命令commandがあります。

[151] SOCKS 4 では操作と認証を同じメッセージでまとめて行います。 CONNECT の場合、一往復で SOCKS としての必要手続きは完了します。

[152] SOCKS 5 では版と認証方式の折衝、認証、命令の3段階があり、 最低 (認証なし) でも二往復しないといけません。

[160] SOCKS 4 も SOCKS 5 も、時代背景や標準化団体が IETF であることから、仕様書の規定はあまり明瞭ではなく、通信相手が仕様に反する場合の扱いも定かではありません。

SOCKS 4 / 4A

[21] 要求には次の欄があります。

VN
最初のバイトはプロトコルの版番号で、 4 とするべきです >>9。
CD
第2バイトは命令符号command codeで、 CONNECT では 1 とするべきで、 BIND では 2 としなければなりません >>9。
DSTPORT
その次の2バイト >>9 はポート番号です。
DSTIP
その次の4バイト >>9 はIPアドレスです。
USERID
その次の任意の長さのバイト列は userid とします >>9。
NULL
最後の1バイトは 0 とします >>9。
ドメイン名
SOCKS 4A では、更に任意の長さのドメイン名を含められる場合があります >>14。
NULL
ドメイン名がある場合、その次の1バイトは 0 とします >>14。
width
32
  1. 8 VN
  2. 8 CD
  3. 16 DSTPORT
  4. 32 DSTIP
  5. 56... USERID
  6. 8 NULL
  7. 56... ドメイン名
  8. 8 NULL

[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。

[51] 明記されていませんが、ドメイン名は . で区切られたラベルの列と思われます。 時代的に ASCII のみのドメイン名が期待されていると思われますが、 非ASCII文字をどう扱うべきなのかは定かではありません。[52] 0.0.0.* の * は 0 以外のどの値にしても良いようですが、 その選択に意味はなさそうです。

[172] Chrome も Firefox も認証には対応しておらず、 userid は常に空とするようです。

[37] 返答パケットには次の欄があります >>9。

VN
最初の1バイトは、返答符号の版とします。 0 とするべきです >>9。
CD
次の1バイトは、結果符号とします >>9。
DSTPORT
その次の2バイト >>9 はポート番号です。
DSTIP
その次の4バイト >>9 はIPアドレスです。
width
32
  1. 8 VN
  2. 8 CD
  3. 16 DSTPORT
  4. 32 DSTIP

[26] 結果符号は、次のいずれかです >>9。

[48] 明記されていませんが、ネットワークバイト順と思われます。

[53] VN や CD が未知の値や想定外の文脈だった時にどう扱うべきかは定かではありません。

CONNECT 操作

[20] クライアントは、他のホストに接続したい時、 SOCKS サーバーに接続して、 CONNECT 要求を送信します >>9。

[31] DSTIP は終点の IPアドレス (またはドメイン名の指定があることを表す値 >>14)、 DSTPORT は終点のポート番号とします >>9。

[23] サーバーは、 CONNECT 要求を受信したら、 受け付けるかどうかを次の情報の一部または全部を使って検査します >>9。

  • 始点 IPアドレス
  • 終点 IPアドレス
  • 終点ポート番号
  • userid
  • RFC 1413 IDENT により得られる情報

[24] サーバーは、要求を受け付ける場合には、 指定された終点のホストとポートに接続します >>9。

[25] サーバーは、接続が確立されたら、 または拒絶する時や操作が失敗した時は、 返答パケットを送信します >>9。

[38] 返答パケットの DSTIP と DSTPORT は、無視します >>9。

[39] サーバーが何を設定するべきなのかは明らかではありません。

[27] サーバーは失敗または拒絶を通知したら、直ちに接続を閉じます >>9。

[45] 一定時間 (例えば2分) 経過後接続が確立できていなければ、 断念してクライアントとの接続も閉じます >>9。

[46] その場合も返答パケットは送信するべきと思われますが、不明瞭です。

[171] Chrome も Firefox も、正しい結果 90 の返答でなければ、 TCP 接続を閉じてネットワークエラーとするようです。

[176] Chrome も Firefox も、要求への返答全体を受信するまで、 その内容の評価を行わないようです。

[177] Chrome も Firefox も、仕様通り返答中の IPアドレスとポート番号を無視するようです。

[175] 要求後 Chrome は 30s、 Firefox は 90s、 返答がなければタイムアウトとするようです。

[28] 要求を受け入れた場合は、以後送受信を中継します >>9。

BIND 操作

[29] クライアントは、他のホストからの接続を受け付けたい時、 SOCKS サーバーに接続して BIND 要求を送信します >>9。

[30] 任意のホストに対するアプリケーションサービスの提供を想定しているのではなく、 CONNECT で主たる接続を確立済みの同じアプリケーションでサーバーからクライアントへと補助的な接続を確立する (のを待ち受ける) ためのもののようです。

[33] DSTIP はアプリケーションサーバーの IPアドレス (またはドメイン名の指定があることを表す値 >>14)、 DSTPORT は主たる接続のポート番号とします >>9。

[34] つまり CONNECT 要求で指定した終点です。

[35] サーバーは、クライアントの情報により、 受け付けるかどうか決定します >>9。

[36] サーバーは、受け付ける場合も受け付けない場合も、 返答パケットを送信します >>9。

[40] 受け入れる場合 (CD = 90) は、 サーバーは接続を待ち受けることとし、そのIPアドレスとポート番号を返答パケットの DSTIP と DSTPORT にそれぞれ設定します >>9。

[41] DSTIP が 0 (INADDR_ANY) の場合、クライアントは、SOCKS サーバーの IPアドレスとみなすべきです >>9。

[42] それ以外の場合は DSTIP と DSTPORT は無視されます >>9。

[43] サーバーが待ち受けるアドレスに接続があると、 次のようにします。

  1. 接続元のホストと BIND 要求の DSTIP が一致すれば、
    1. 返答パケットをクライアントに送信します。 CD は 90 とします。
    2. 以後両接続間の送受信を中継します。
  2. それ以外なら、
    1. 返答パケットをクライアントに送信します。 CD は 91 とします。
    2. 両接続とも、切断します。

[44] 一定時間 (例えば2分) 経過後接続が確立できていなければ、 断念してクライアントとの接続も閉じます >>9。

[47] その場合も返答パケットは送信するべきかもしれませんが、不明瞭です。

SOCKS 5

認証方式

[153] SOCKS 5 では最初にクライアントとサーバーの間で認証方式を折衝し、 それに応じて認証します。

[154] 更に認証後のメッセージその他の送受信におけるデータのカプセル化の方法は認証方式によって規定できます。 例えば認証方式によっては暗号化や署名の方法と構文を規定できます。

[99] 方式識別子 (METHOD) には次の値があります。

METHOD 意味
0x00認証不要 >>6
0x01GSSAPI >>6
0x02USERNAME/PASSWORD >>6
0x03Challenge-Handshake Authentication Protocol >>75
0x05Challenge-Response Authentication Method >>75
0x06SSL >>75
0x07NDS Authentication >>75
0x08Multi-Authentication Framework >>75
0x80-0xFE私的な方式に予約 >>6
0xFF認められる方式なし >>6

[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プロキシを使うものでしょうから、 認証は不要なのだと思われます。認証に対応するよう要望が出されてもいますが、 長年未対応のままで、それほど需要は大きくないようです。

つまり RFC の規定は実態に合っていません。
  • [8] RFC 1929 - Username/Password Authentication for SOCKS V5 ( 版) https://tools.ietf.org/html/rfc1929
  • [10] RFC 1961 - GSS-API Authentication Method for SOCKS Version 5 ( 版) https://tools.ietf.org/html/rfc1961
  • [12] draft-ietf-aft-socks-chap-01 - Challenge-Handshake Authentication Protocol for SOCKS V5 ( 版) https://tools.ietf.org/html/draft-ietf-aft-socks-chap-01
  • [79] draft-ietf-aft-socks-cram-00 - Challenge-Response Authentication Method for SOCKS V5 ( 版) https://tools.ietf.org/html/draft-ietf-aft-socks-cram-00
  • [80] draft-ietf-aft-socks-ssl-00 - Secure Sockets Layer for SOCKS Version 5 ( 版) https://tools.ietf.org/html/draft-ietf-aft-socks-ssl-00
  • [81] draft-ietf-aft-socks-maf-01 - Multi-Authentication Framework Method for SOCKS V5 ( 版) https://tools.ietf.org/html/draft-ietf-aft-socks-maf-01

アドレス型

[107] ATYP 欄は、 DST.ADDR 欄や BND.ADDR 欄のアドレスの種別を表すものです >>6。

[108] 次の値があります。

value
値
length
アドレス欄の長さ
desc
アドレス欄の値
value
0x01 >>6
desc
IPv4アドレス
length
4バイト
value
0x03 >>6
desc
バイト数 (1バイト) と、そのバイト数の FQDN
value
0x04 >>6
desc
IPv6アドレス
length
16バイト

[159] FQDN は、時代的に IDN が考慮されておらず、どう扱われるのかは定かではありません。 また末尾の点の扱いも明確ではありません。更に FQDN と規定されてはいますが、 実際にはサーバーの名前解決の実装に依存する可能性もあります。

プロトコル

[88] TCP による接続は、クライアントから次のようにします。

  1. [89] TCP で SOCKS サーバーに接続します >>6。
  2. [84] 版識別子・方式選択メッセージversion identifier/method selection messageを送信します >>6。
    VER
    1バイト。 5。 >>6
    NMETHODS
    1バイト。 METHODS に含まれる方式識別子オクテットの数。 >>6
    METHODS
    1-255バイト。 >>6 クライアントが受け入れる認証方式のリストを表す方式識別子オクテットの列。

[94] サーバーは、これを受けて、

  1. [96] 受信した METHODS からいずれか1つを選びます >>6。 適切なものがなければ >>6、 0xFF とします。
  2. [95] 次のような METHOD 選択メッセージMETHOD selection messageを送信します >>6。
    VER
    1バイト。 >>6 5。
    METHOD
    1バイト。 >>6 選択した方式識別子。

[97] そしてクライアントは、

  1. [98] METHOD が 0xFF なら、接続を閉じなければなりません >>6。 ここで停止します。

[100] その後、クライアントとサーバーの間で方式依存の折衝を行います >>6。

[157] 認証方式が 0x00 の場合は、何もしないと思われます。

[179] Chrome も Firefox も、最初に受信した2バイトが 0x0500 でなければ TCP 接続を閉じます。(2バイトを受信するまで待ちます。)

[104] それが済んだら、クライアントは、

  1. [105] 要求を作成します。
    VER
    1バイト。 5。 >>6
    CMD
    1バイト。 CONNECT = 1, BIND = 2, UDP ASSOCIATE = 3 のいずれか。 >>6
    RSV
    1バイト。 0x00。 >>6
    ATYP
    1バイト。 DST.ADDR のアドレス型。 >>6
    DST.ADDR
    ATYP 依存の長さ。望む終点アドレス。 >>6
    DST.PORT
    2バイト。望む終点ポート。ネットワークバイト順。 >>6
  2. [86] (一貫性の検査や機密性のため) 折衝方式依存のカプセル化が規定されているなら、 カプセル化しなければなりません >>6。
  3. [106] 要求を送信します。

[87] それに対してサーバーは、普通は始点と終点のアドレスを評価して、 適切な接続を確立して要求の種類に応じたメッセージを返すか、 または拒絶します >>6。

[109] サーバーは、次のように返答replyします。

  1. [110] 次のような返答メッセージを作成します >>6。
    VER
    1バイト。 5。 >>6
    REP
    1バイト。返答。 >>6
    RSV
    1バイト。 0x00 でなければなりません。 >>6
    ATYP
    1バイト。 BND.ADDR のアドレス型。 >>6
    BND.ADDR
    サーバーが束縛したアドレス。 >>6
    BND.PORT
    2バイト。サーバーが束縛したポート。ネットワークバイト順。 >>6
  2. [111] (一貫性の検査や機密性のため) 折衝方式依存のカプセル化が規定されているなら、 カプセル化します >>6。
  3. [112] 返答を送信します。

[113] REP 欄には、次の値を使います >>6。

  • 0x00 - 成功
  • 0x01 - 一般的な SOCKS サーバーの失敗
  • 0x02 - 規則集合により接続が認められていない
  • 0x03 - ネットワーク到達不能
  • 0x04 - ホスト到達不能
  • 0x05 - 接続が拒絶された
  • 0x06 - TTL 満期
  • 0x07 - 命令に対応していない
  • 0x08 - アドレス型に対応していない
  • 0x09-0xFF - 未割当

[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 request headerを付します。 UDP要求ヘッダーは次の欄で構成されます。 >>6

RSV
2バイト。 0x0000。 >>6
FRAG
1バイト。現在素片番号。 >>6
ATVP
1バイト。 DST.ADDR のアドレス型。 >>6
DST.ADDR
可変長。望む終点アドレス。 >>6
DST.PORT
2バイト。望む終点ポート。 >>6
DATA
可変長。利用者データ。 >>6

[145] 「ヘッダー」とは言っていますが、 DATA 欄が含まれるのですから、 その前までがヘッダー、全体としてはメッセージと呼ぶべきものでしょう。

[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

  • ATYP が 0x01 なら、 10 + 認証方式依存の長さ >>6
  • ATYP が 0x03 なら、 262 + 認証方式依存の長さ >>6
  • ATYP が 0x04 なら、 22 + 認証方式依存の長さ >>7

下位層プロトコル

[161] 下位層プロトコルとして TCP や一部 UDP を使いますが、 その方法は明確ではありません。

[162] 例えば緊急ポインターが指定されている時どう扱うべきなのか、 RST を受信したらどうするべきなのかなど明確な規定はありません。

緊急データは無視するべきなのか、それとも透過的に扱いアプリケーションに委ねるべきなのか、など。

ポート番号

[85] SOCKS5 では、普通は 1080 番ポートを使います >>6。

[77] TCP と UDP のポート番号 1080 はサービス socks として IANA登録簿に登録されています。 説明は「Socks」となっています。 >>76

[78] 明らかに SOCKS のことを指しているのでしょうが、 IANA登録簿には明記されていません。

URL scheme

[74] プロキシの指定などで URL を指定する時に、次の URL scheme が用いられます。

PAC

[73] PAC では次の値が SOCKSプロキシを表すために使われています。

[182] SOCKS は、 SOCKS4 を表します >>61。

実装

[128] SOCKS のサーバーとクライアントの実装として、 Dante があります。

[127] Webブラウザーをはじめ、多くのインターネットアプリケーションのクライアントプログラムやライブラリーが SOCKS クライアント機能を持っています。

[126] socksify (dante) や tsocks のような、 SOCKS を実装していないプログラムの TCP/IP 接続部分を SOCKS 利用に差し替えるプログラムもあります。

[1] AnyEvent::HTTP::Socks - search.cpan.org ( 版) http://search.cpan.org/~oleg/AnyEvent-HTTP-Socks-0.04/lib/AnyEvent/HTTP/Socks.pm
  "socks4://10.0.0.1:1080  socks5://root:123@10.0.0.2:1080  socks4a://85.224.100.1:9010"
[3] AnyEvent::HTTP::Socks - search.cpan.org ( 版) http://search.cpan.org/~oleg/AnyEvent-HTTP-Socks-0.04/lib/AnyEvent/HTTP/Socks.pm
  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

[5] SSH: プロキシ設定の定義 ( 版) http://www.ssh.com/manuals/client-user/43J/firewall.html

プロキシサーバのアドレスを入力します 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 かは不明。) もまだまだ使われているようです。

[55] cURL - How To Use ( 版) http://curl.haxx.se/docs/manpage.html

Since 7.21.7, this option is superfluous since you can specify a socks5 hostname proxy with -x, --proxy using a socks5h:// protocol prefix.

[56] cURL - How To Use ( 版) http://curl.haxx.se/docs/manpage.html

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

[65] [chrome] Contents of /trunk/src/net/socket/socks_client_socket.cc ( 版) http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socks_client_socket.cc

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.)

[66] net/socket/socks_client_socket.cc - Issue 113811: Adding socks4 support for chromium. tested for windows and linux.... - Code Review ( 版) https://codereview.chromium.org/113811/diff/11012/net/socket/socks_client_socket.cc

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/

[83] ( 版) http://www.novell.com/documentation/nbm39/administration/data/b7qgmq8.html

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/