proxy
透過proxy
NW管理者が強制的にproxyさせる
PCのブラウザ設定は無関係に強制的にproxyする
仕組みとしては、インターネットへの通信経路上に透過プロキシの設定をしたプロキシサーバを配置するのみです。
「インターネットへの通信経路上」といっても、デフォルトルートの経路上に配置してしまうと、smtp や pop, imap 等の他のプロトコルがインターネット通信できなくなってしまいます (http 等の一部のプロトコルのみ、透過型プロキシサーバで取り次がれますので)。
なので、透過型プロキシサーバは、経路の少し横に配置し、ルータやL3スイッチの PBR (ポリシーベースルーティング) 機能により http 通信だけを曲げるのが一般的です。 http通信だけを強制的にproxyさせるということ
また、firewalld のポートフォワード機能により、tcp:80 で来た通信を 8080 等のプロキシ待受ポートに変換させたりします。
MITM攻撃と同じ
この透過型プロキシは、通信ジャックと同じことですので、https 通信についても透過型プロキシ経由にしようとすると、ブラウザに SSL/TLS の警告が表示されてしまいます。
これを避けるためには、プロキシサーバにて動的に各サーバへの証明書を作成 (例えばクライアントが www.yahoo.co.jp へアクセスする際には CN=www.yahoo.co.jp の証明書をその場で作成しクライアントへ提示) することに加え、クライアント側にはそのプロキシサーバのルート証明書のインストール (信頼設定) が必要です。
他の回避策としては PBR で tcp:443 は曲げず、直接インターネットへ通信させる。https でのプロキシログは取れなくなってしまうが、Palo Alto 等の UTM の URL フィルタ機能があれば、https 通信開始時のデジタル証明書の CN (Common Name) を見てログを取得できるため、補完できる。
Encrypted SNIになったらこの方法は使えなさそう
Encrypted SNIではServer Nameヘッダが暗号化され、閲覧サイトの特定がさらに困難になります。 TLS1.3ではサーバ証明書のやり取りも暗号化されますので、証明書のCommon Nameも第三者は見られなくなります。 この記事では実際にWiresharkでパケットキャプチャしてServer Nameが秘匿されていることを見ている 公開proxy（1段のproxy）
透過proxyの利用者がブラウザの設定で指定する版
普通、proxyといったらこれ
匿名proxy（多段のproxy）
欠点：多段なので遅い