socat SOCKSブリッジ：サイトのTLSホスト名を保つ

1つのSOCKS宛先にループバックTCPリスナーを使い、アプリケーション内でHTTPとTLSの同一性を保ちます。

アプリケーションにSOCKSオプションはありませんが、選んだTCPアドレスへ接続できます。固定ターゲットのアダプターなら、1つの宛先のSOCKS会話を提供できます。別の汎用フォワードプロキシになる必要はありません。

SOCKS4Aを提供するsocatビルドでは、説明的な構成は次のとおりです。

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

SOCKSエンドポイントはローカルポート1080です。アダプターはローカルポート9443で待ち受け、そのエンドポイントにservice.example.net:443を要求します。これらは例示値であり、完全なサービス配備ではありません。

アダプターの固定ターゲットは1つ

受け付けた各TCP接続は同じサービスを要求します。9443に接続するアプリケーションは通常のプロトコルバイトを送り、socatがSOCKS4Aのネゴシエーションを担います。9443へ新しいHTTP CONNECT要求を送っても別の宛先は選ばれず、そのバイトは固定サービスへ送られます。

SOCKS4Aは遠隔解決のためにSOCKSエンドポイントへホスト名を渡します。これはクライアントが選んだアドレスを使うSOCKS4形式とは異なります。選んだ上流は—SOCKS4プロキシ一覧の公開候補も含め—SOCKS4Aのホスト名処理と必要な認証に対応している必要があります。この例はSOCKS5のパスワードログイン手順ではありません。

ローカルで接続し、本当のサービスを見分ける

HTTPS URLをhttps://127.0.0.1:9443/に変えると、クライアントがTLSとHTTPに使えるホスト名が変わります。service.example.netの証明書がループバック用の有効な証明書になるわけではありません。

クライアントが接続経路の分離に対応している場合は、元のURLの同一性を保ちます。Curlはその違いを示せます。

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

ソケットはローカルアダプターへ向かい、TLS検証とHTTPの宛先はservice.example.netのままです。他のアプリケーションには独自の同等な制御が必要で、すべてのクライアントが備えているわけではありません。

ループバック束縛はネットワーク露出を限定しますが、他の適格なローカルプロセスは依然として到達できます。サービスの寿命と利用者を適切に保ってください。ループバックURLによる同一性エラーを抑え込むのではなく、TLS検証を維持します。

関連記事