SOCKS
SOCKSは、クライアント・サーバー間で転送されるネットワークパケットをプロキシサーバー経由で交換するためにインターネット上で利用されるプロトコルである。SOCKS5は、追加で認証の機能を提供するため、認証されたユーザーのみ接続を許可するように設定できる。実用的には、SOCKSサーバーはTCP接続を任意のIPアドレスにプロキシしたり、UDPパケットを転送する手段を提供する。
SOCKSはOSI参照モデルの第5層のセッション層（プレゼンテーション層とトランスポート層の中間）で実行される。そのため、SOCKSサーバーは、クライアントからのTCPポート1080の接続を受け入れる必要がある。
SOCKSは当初、MIPS Computer Systemsのシステム管理者であるDavid Koblasによって開発された。Koblasは、MIPS Computer Systemsが1992年にSilicon Graphicsによって吸収合併された後に、その年のUsenix Security SymposiumでSOCKSの研究論文を公開した。これによりSOCKSはパブリックに利用できるようになった。SOCKSは、NECのYing-Da Leeによってバージョン4に拡張された。
SOCKS関連のアーキテクチャやクライアントはPermeo Technologiesが所有している。なお、Permeo Technologiesは、NECからスピンオフしたBlue Coat Systemsによって吸収合併された。
SOCKS5プロトコルは、もともとはファイアウォールの一部として、他のセキュリティ製品とともに管理を容易にするために作られたセキュリティプロトコルだった。1996年にIETFによって承認された。SOCKS5は、アジア外の技術を販売している企業Aventail Corporationの協力のもとに開発された。
"SOCKS" は、のファイアウォールにおけるデファクトスタンダードとなっている。
"SOCKS"は迂回のためのツールとしても使用されることがある。たとえば、政府、職場、学校、特定の国限定のウェブサービスなどで、インターネットのコンテンツへのアクセスフィルタやブロッキングが行われている場合に、それらを回避することができる。
OpenSSHなどのSSHスイートの一部では、動的なポートフォワーディングをサポートしており、これにより、ユーザーはローカルなSOCKS proxyを作成することができる。この機能のおかげで、リモートポートやサーバーがあらかじめ作成されていなくても、ユーザーはSOCKS proxyを自由に利用できる。
Tor onion proxyソフトウェアは、クライアントに対して、SOCKSインターフェイスを提供している。
クラッキングされたコンピュータには、ボットネットの制御を隠したり、クレジットカード詐欺の目的のために、SOCKS proxyソフトウェアが設定されることがある。
SOCKSは、ネットワーク・ファイアウォール越えやアクセス制御等を目的として、クライアントサーバ型のプロトコルが、透過的に使用できるよう設計されたプロキシ（proxy）のプロトコル、及びシステム（の一つ）である。"SOCKetS" の略。
いわゆるTCP/IPの4層モデル（インターネット・プロトコル・スイートのDARPAモデル）の観点からは、Internet Protocol（IP）の上の、TCPやUDP（ただしUDPに関しては有用性が限られる）のようなトランスポート層における通信の手続きを中継・代理するメカニズムとなっている。SOCKSサーバ自身とクライアント間の通信はストリーム指向であり、一般にはLAN内からTCPで接続する。
プロトコル上は多段にもできるが、原理の説明には1段階で十分なので、以下はそのような前提とする。またファイアウォールを設けないシステムでもユースケースは考えられるが、以下ではファイアウォールの存在を前提とする。
似たような目的のための他のプロキシ類と同様、SOCKSサーバはその目的から、内外のネットワークの両方が見えるファイアウォール自身、あるいはDMZ内に置く。そうでない場合は、SOCKSサーバのみは外部との通信を可能にする、あるいは、内部からSOCKサーバにだけは通信を可能にする、といったような設定が必要となる。
そして、内側から外部に通信する必要があるノードは、代わりにSOCKSサーバに接続し、SOCKSサーバがプロキシとして代わりに外部と通信する。SOCKSプロキシは、例えば、クライアントが外部サーバにアクセスする資格を制御するなどといった、認証や認可を掛けることもできる。SOCKSはまた正反対にも使用することができる。つまり、ファイアウォールの外側の許可された外部クライアントのみが、物理的にはファイアウォールの内側にある、公開のサービスを提供するサーバのみに接続できるようにする、といった用途のための設定もできる。
標準の SOCKS 4 接続では、以下のような通信が行われる。
SOCKS クライアントからサーバ:SOCKS サーバからクライアント:例:
これは、66.102.7.99:80にユーザ「Fred」を接続する SOCKS 4 のリクエストである。そして、サーバは、"OK"の返事をする。この時点以降、 SOCKS クライアントから SOCKS サーバまで送る全てのデータは66.102.7.99に向けて中継される。そして、 SOCKS サーバから SOCKS クライアントに送る場合も同様である。
コマンドフィールドは、 "connect" で 0x01 、あるいは、 "bind" で 0x02 になることができる。 "bind" は動作中の FTP のようなプロトコルのために入ってくる接続を許可する。
SOCKS 4a は、 SOCKS 4 プロトコルのシンプルな拡張機能であり、宛先ホストのドメイン名を解決できないクライアントがドメイン名を指定することを可能にする。
クライアントは宛先アドレスの最初の3バイトを NULL に、そして最後のバイトを0でない値に設定すべきである(これは、ｘ を非零の値として、 IP アドレス 0.0.0.x に対応する。この値は宛先アドレスとして使用してはならない。したがって、この値は、もしクライアントがドメイン名を解決できるならば、決して設定するべきではない。)。
ユーザ ID を終了する NULL バイトの次に、クライアントは宛先ドメイン名を送らなければならない、そして、それを別の NULL バイトで終了させなければならない。これは "connect" と "bind" の両方のリクエストに使われる。
SOCKS クライアントからサーバ:SOCKS サーバからクライアント:4A プロトコルを使用するサーバはリクエストパケット内の宛先アドレスをチェックしなければならない。宛先アドレスが、 x を非零の値としてアドレス 0.0.0.x を表現するならば、サーバはクライアントがパケット内に送付するドメイン名を読み込まなければならない。サーバはドメイン名を解決すべきであり、そしてそれが可能であるならば、宛先ホストへの接続を確立しなくてはならない。
より多くの認証の選択を提供する SOCKS 4 プロトコルの拡張である SOCKS 5 プロトコルは RFC 1928 内で定義されている。最初のハンドシェイクは下記の事項から成り立つ。サポートされた認証方法は次の通りに番号を割り付けている：クライアントからの最初の挨拶：サーバの選択が伝えられる：次の認証は認証方法によって異なり、 RFC 1929 で記述されている。
クライアントの認証要求：
認証のためのサーバの応答:クライアントの接続要求：サーバの応答：SOCKSによって外部ネットワークに接続する、全てのネットワーク・ソフトウェアの適合を可能にする "socksify" というクライアント用のプログラムがある。