Squid の SSL Bump が実際に動作しているかどうかを確認する方法
(カスタム CA がインストールされていないクリーンな Windows クライアントを例に説明します)
Chrome/Edge でこのエラーが表示されるのはなぜですか？
net::ERR_CERT_AUTHORITY_INVALID
このエラーは、以下の状況でのみ発生します。
ブラウザが再署名された HTTPS 証明書を受け取ったものの、それを発行した CA を信頼していない場合。
⚠️ 重要事項 (非常に重要)
SSL Bump が有効になっていない場合、
このエラーは発生しません。
理由は簡単です。
SSL Bump が有効になっていない場合
→ ブラウザは元のウェブサイト (Google/Microsoft など) からの公式証明書のみを参照します。
→ 緑色の南京錠アイコンのみが表示されます。
→ ERR_CERT_AUTHORITY_INVALID は表示されません。
� したがって、このエラー自体が、
SSL Bump が実際に HTTPS を実装していることの直接的な証拠となります。
真の「確固たる証拠」はどこにあるのでしょうか？
気づいていないかもしれませんが、以下の行は「階層構造」の紛れもない証拠です。
Via: ICAP/1.0 YourServerName (C-ICAP/0.5.12 srv_content_filtering service), 1.1 No1.f88tw (squid/6.12)
なぜこの行はHTTPSにおいてそれほど重要なのでしょうか？
通常のHTTPSの動作では、以下のようになります。
CONNECTトンネルが確立された後、
SquidはHTTPヘッダーを認識できません。
c-icapは呼び出されません。
つまり、以下のようになります。
SSLバンプは発生しません。
→ HTTPSはプロキシにとって暗号化されたブラックボックスです。
� しかし、今何が見えますか？
HTTPSレスポンスヘッダーは
「ICAPサービス経由」と直接指定し、
Squidとc-icapのバージョンと役割を示します。
これはアーキテクチャ上、次のことを意味します。
� SquidがSSLバンプを完了しました。
→ HTTPSを復号します。
→ コンテンツをc-icapに送信します。
→ 再暗号化してクライアントに送り返します。
curl.exe https://www.baidu.com --proxy http://192.168.0.88:3128 -k -v
http://mypaper.m.pchome.com.tw/f88tw/post/1370820447
