【Squid講座 第4回】暗号化の壁を越えろ！HTTPS通信の制御と禁断の「SSLバンピング」完全構築ガイド

「暗号化」は、セキュリティ管理者にとっての「目隠し」だ。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回までに、IP制限やユーザー認証を使って、Squidの守りを固めてきました。

しかし、現代のインターネットには、これら従来のプロキシ技術を無力化してしまう「巨大な壁」が存在します。
それが「HTTPS（SSL/TLS暗号化通信）」です。

この「暗号化の壁」を突破し、HTTPS通信の中身を検閲するための技術が「SSLバンピング（SSLインターセプト）」です。
これは技術的には「中間者攻撃」と同じ手法を用いる、まさに禁断の技術です。

今回は、HTTPS通信の仕組みから、SquidでSSLバンピング環境を構築する手順、そして避けては通れない「証明書エラー」との戦いについて完全解説します。

---

第1章：HTTPS通信と「CONNECTメソッド」の限界

まずは、通常のプロキシがHTTPS通信をどのように扱っているかを知る必要があります。

1. プロキシは「土管」になる

HTTP（平文）の場合、プロキシは「GET /index.html」のようなリクエスト内容を読み取り、代わりに取得します。
しかしHTTPSの場合、ブラウザはプロキシに対して「CONNECT www.google.com:443」という特殊なリクエストを送ります。

これは「Googleの443番ポートまで、暗号化されたトンネルを掘ってくれ。中身には関知するな」という命令です。

2. 見えるもの、見えないもの

この「CONNECTメソッド」による通信において、Squidが把握できる情報は極めて限定的です。

情報	Squidから見える？	解説
接続先ドメイン	見える (◯)	「www.google.com」に行きたい、ということは分かる（SNI情報などから）。
接続先ポート	見える (◯)	通常は443。
URLパス	見えない (✕)	「/search?q=アダルト」などの具体的なパスやクエリは見えない。
通信の中身	見えない (✕)	画像、テキスト、パスワードなどは全て暗号化されている。

つまり、通常のSquid設定では、「ドメイン単位のブロック（Yahooはダメ）」はできても、「URL単位のブロック（Yahooの特定の記事だけダメ）」や「ウイルス検知」は不可能なのです。

---

第2章：禁断の技術「SSLバンピング」の仕組み

この限界を突破するのが「SSLバンピング（SSL Bumping / SSL Interception）」です。
仕組みは少々荒っぽいですが、以下のようになります。

1. なりすまし： クライアントが「Google」に接続しようとすると、Squidが通信を横取り（Intercept）します。
2. 偽造証明書： Squidはその場で「Google」を名乗る偽のSSL証明書を動的に生成し、クライアントに渡します。
3. 暗号解除： クライアントは「Google（実はSquid）」と暗号化通信を確立します。Squidはここで一度データを復号（平文に戻す）します。
4. 再暗号化： Squidは中身をチェック（検閲）した後、正規のGoogleサーバーへ、改めて暗号化通信を行います。

つまり、Squidが「中間者（Man-in-the-Middle）」となって、暗号化パイプを一度切断し、中身を覗き見るわけです。
これにより、HTTPSであってもURLフィルタリングやキーワードブロックが可能になります。

---

第3章：【実践】自己署名CA証明書の作成

それでは、実際に環境を構築していきましょう。
まずは、Squidが偽造証明書を発行するための元となる「認証局（CA）」を、Squidサーバー内に作ります。

1. OpenSSLで鍵と証明書を作る

作業用ディレクトリを作成し、移動します。

sudo mkdir /etc/squid/ssl_cert
cd /etc/squid/ssl_cert

OpenSSLコマンドで、秘密鍵（myCA.pem）を作成します。

sudo openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 -extensions v3_ca -keyout myCA.pem -out myCA.pem

コマンドを実行すると、国コードや組織名を聞かれます。
適当で構いませんが、Common Name (CN) だけは重要です。ブラウザの証明書情報に表示される名前になるので、"My Company Proxy CA" など分かりやすい名前をつけましょう。

Country Name (2 letter code) [XX]:JP
...
Common Name (eg, your name or your server's hostname) []:My Proxy CA

2. 証明書の変換（クライアント配布用）

作成された myCA.pem はサーバー用です。
これをWindowsなどのクライアントにインポートできる形式（.der）に変換します。

sudo openssl x509 -in myCA.pem -outform DER -out myCA.der

この myCA.der ファイルを、WinSCPなどで手元のPCにダウンロードしておいてください。

3. 権限の設定

Squidがこの鍵を読めるようにします。

sudo chown squid:squid /etc/squid/ssl_cert/myCA.pem
sudo chmod 400 /etc/squid/ssl_cert/myCA.pem

---

第4章：Squidの設定（SSL Bump有効化）

次に、Squidの設定を変更してSSLバンピングを有効にします。
※AlmaLinux 9の標準Squidパッケージは、SSL関連モジュールを含んでいます。

1. SSLデータベースの初期化

Squidが動的に生成した証明書を一時保存するためのデータベースを作成します。

# ディレクトリ作成などはコマンドがやってくれる
sudo /usr/lib64/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 4MB

# 権限修正（重要！）
sudo chown -R squid:squid /var/lib/squid/ssl_db

※コマンドパスは環境によって異なる場合があります。rpm -ql squid | grep certgen で探してください。

2. squid.confの編集

sudo nano /etc/squid/squid.conf を開き、設定を書き換えます。

変更前：

http_port 3128

変更後：

# SSL Bump対応ポート設定
http_port 3128 ssl-bump \
  cert=/etc/squid/ssl_cert/myCA.pem \
  generate-host-certificates=on \
  dynamic_cert_mem_cache_size=4MB

# SSL Bumpのルール定義
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all

3. 再起動

sudo systemctl restart squid

エラーが出なければ成功です。

---

第5章：クライアント側への証明書インストール

この状態でブラウザからHTTPSサイト（Googleなど）にアクセスすると、「この接続は安全ではありません」という真っ赤な警告画面が出るはずです。
これは、ブラウザが「Squidの発行した偽証明書」を信頼していないからです。

先ほどダウンロードした myCA.der を、PCに「信頼されたルート証明機関」として登録します。

Windowsの場合（Chrome / Edge）

1. myCA.der をダブルクリック。
2. 「証明書のインストール」をクリック。
3. 保存場所：「現在のユーザー」または「ローカルコンピュータ」。
4. 証明書ストア：「証明書をすべて次のストアに配置する」を選択し、「参照」ボタンを押す。
5. 「信頼されたルート証明機関」を選択してOK。
6. 「次へ」→「完了」→「正しくインポートされました」。

Firefoxの場合

FirefoxはWindowsの証明書ストアを使わず、独自に管理しているため、別途設定が必要です。

1. 設定 → プライバシーとセキュリティ → 証明書 → 「証明書を表示」。
2. 「認証局」タブの「インポート」をクリック。
3. myCA.der を選択。
4. 「この認証局によるウェブサイトの識別を信頼する」にチェックを入れてOK。

これでブラウザを再起動し、Googleなどにアクセスしてみてください。
警告が出ずに表示され、アドレスバーの鍵マークをクリックして証明書を見ると、発行者が「My Proxy CA」になっているはずです。
これで、あなたのブラウザとGoogleの間の通信は、全てSquidによって一度復号されています。

---

第6章：現代の壁「HSTS」と除外設定（Splice）

「これで全通信が見える！」と喜ぶのは早いです。
最近のWebセキュリティは強力で、単純なバンピングを許さないサイトが増えています。

HSTSとCertificate Pinning

銀行、医療系、そしてGoogleの一部のサービスなどは、「HSTS」や「HPKP（ピンニング）」という技術を使っています。
これはブラウザに対し、「このサイトの証明書は絶対に正規の認証局から発行されたものでなければならない（オレオレ証明書は許さない）」と強制する仕組みです。
これらのサイトにSSLバンピングを行うと、ブラウザ側でブロックされ、ページが表示されなくなります。

回避策：特定サイトのスプライシング（Splice）

エラーになるサイトについては、中身を見るのを諦めて、従来の「土管（トンネル）」モードで通す必要があります。
これをSquidでは「スプライス（Splice）」と呼びます。

squid.confの設定例：

# 除外リスト（バンピングしないドメイン）
acl no_bump_sites ssl::server_name .google.com .bank.co.jp .dropbox.com

# ステップ1（SNI取得）
acl step1 at_step SslBump1
ssl_bump peek step1

# 除外リストにマッチしたら、スプライス（素通り）する
ssl_bump splice no_bump_sites

# それ以外はバンピング（復号）する
ssl_bump bump all

このように、「peek（チラ見）」→「splice（除外判定）」→「bump（残り全復号）」という多段構えにするのが、現代のSSLプロキシの鉄板構成です。

---

第7章：トラブルシューティングと運用リスク

Q1. 一部のアプリ（DropboxやSlackアプリなど）が繋がらない

A. アプリ独自の証明書検証に引っかかっています。
ブラウザ以外のアプリは、OSの証明書ストアを見ないものや、独自に証明書を厳格にチェックするものがあります。
それらの通信先ドメイン（例：.dropbox.com）を特定し、アクセスログを見て splice 設定に追加していく地道な作業が必要です。

Q2. 証明書の期限切れ

今回作成したオレオレ証明書の有効期限は3650日（10年）にしましたが、これが切れると全社員がネットに繋がらなくなります。
更新作業は「新しい証明書の配布（全台再インストール）」になるため、地獄を見ます。
有効期限は長めに設定し、管理台帳に更新時期を記録しておきましょう。

Q3. プライバシーと法的リスク

SSLバンピングを行うと、社員がアクセスしたネットバンキングのパスワードや、個人のSNSのメッセージ内容まで全て管理者が閲覧可能になります。
これは「通信の秘密」の侵害にあたる可能性があります。
導入の際は、必ず就業規則への記載や、社員への周知徹底（「業務上の通信は監視されます」という合意）が必要です。

---

まとめ：強力な力には責任が伴う

お疲れ様でした！
今回は、プロキシ構築における最難関「SSLバンピング」を構築しました。

今回の重要ポイント：

• 通常、プロキシはHTTPSの中身（URLパス等）を見られない。
• SSLバンピングを使えば復号できるが、クライアントへの証明書配布が必須。
• ssl_bump peek と splice を組み合わせて、HSTSエラーを回避する。
• プライバシー侵害のリスクを理解し、運用ルールを定める。

これで、暗号化通信の壁を越え、通信の中身を自在にコントロールできるようになりました。
しかし、通信量が増えてくると、今度は「プロキシサーバーが遅い！」というクレームが来るようになります。

次回、第5回は「爆速化！キャッシュ機能のチューニングとメモリ管理」です。
Squidの本業である「キャッシュ」を最適化し、インターネットアクセスを劇的に高速化するテクニックを伝授します。
お楽しみに！