はじめに
本ドキュメントの目的
本書はSSL bumpingの基本から実装例、企業向けソリューションの紹介、運用上の注意点までを分かりやすくまとめた入門書です。暗号化された通信を安全に検査する仕組みを理解し、導入判断や運用設計に役立てられることを目的とします。
簡単な説明
SSL bumpingは、SSL/TLSで暗号化された通信を一度復号して中身を検査し、検査後に再暗号化して送信する技術です。例えば、ウェブのマルウェア検出や社内ポリシー違反のチェックに使います。一般的な実装例としてSquidプロキシやF5 BIG-IPのような製品があります。
対象読者
ネットワークやセキュリティの基本知識を持つエンジニアや運用担当者、導入を検討する管理者向けです。専門家でなくても理解できるよう、専門用語は最小限にして具体例で補足します。
本書の構成
全6章で構成します。概要、仕組み、Squidでの実装、F5 BIG-IPの例、そして注意点と課題を順に解説します。
SSL Bumpingの概要
何をする技術か
SSL Bumping（別名: SSL interception）は、プロキシやファイアウォールが暗号化された通信を一旦復号して中身を検査し、検査後に再び暗号化して送信する技術です。たとえば、職場のPCがウェブサイトへアクセスするとき、仲介する機器がその通信を読み取り可能な形にして安全性を確認します。
主な目的と具体例
- マルウェア検出：添付ファイルや不正なスクリプトを見つけるために復号して確認します。例：メール添付の悪意あるファイルを検出します。
- 情報漏えい対策：機密情報が外部に流れないようにチェックします。例：顧客番号や個人情報の送信を検知します。
- コンテンツ制御やトラブルシューティング：学校や企業で不適切サイトのブロックや通信問題の原因調査に使います。
ごく簡単な流れ（例）
- クライアントがサイトへ接続を試みる。
- プロキシがクライアントに対して“そのサイトの代わり”として証明書を提示し、通信を復号する。
- プロキシは実際のサーバーと別途安全な接続を確立し、内容を検査した後に再暗号化して双方に渡します。
注意すべき点（概略）
- 利用者のプライバシーや法的な問題が生じる可能性があります。運用には明確な方針と通知が必要です。
- クライアント側でプロキシの証明書を信頼させる設定が必要で、証明書を端末に配布する管理作業が発生します。
- 一部のアプリは証明書ピンニングなどで動作せず、業務上の例外対応が必要になることがあります。
以上がSSL Bumpingの概要です。次章で仕組みの詳細に入ります。
SSL Bumpingの仕組みと技術的詳細
全体の流れ
SSL Bumpingは中間装置がユーザーと外部サーバーの間に入り、通信を一旦受け取って処理します。具体的には「傍受→復号→検査→再暗号化」の順で進みます。例えば社員のブラウザから送られたHTTPS通信をプロキシが受け、内容を確認してから送信します。
CA証明書の役割
プロキシは自前のCA証明書で偽のサーバ証明書を発行し、ブラウザにそれを提示します。端末にそのCAを信頼させておけば、ブラウザは警告を出さずに接続します。端末側でCAを配布・信頼設定する点が重要です。
復号化と検査の方法
復号後はマルウェア検出やデータ漏えい防止（DLP）などのルールで検査します。検査にはシグネチャ照合や振る舞い解析を用いることが多く、必要に応じて通信を遮断します。
再暗号化と転送
検査後は再度暗号化して本来のサーバに接続します。外部からは通常のHTTPS接続に見えるため、通信の透明性を保てます。
技術的留意点
・端末側のCA管理が必須
・一部アプリは証明書検証を厳格に行い、中間での復号を拒む場合があります
・秘密鍵管理とログの扱いに注意が必要です。
Squidでのssl bumpingの実装方法
準備（CAの作成）
まず、検査用の自己署名CAを作成します。例:
openssl req -new -x509 -days 3650 -nodes -out /etc/squid/ssl_cert/myCA.crt -keyout /etc/squid/ssl_cert/myCA.key -subj “/CN=LocalSquidCA”
cat /etc/squid/ssl_cert/myCA.crt /etc/squid/ssl_cert/myCA.key > /etc/squid/ssl_cert/myCA.pem
次にブラウザやクライアントにCAを信頼させます。
squid.confの主要設定
https_port 3129 intercept ssl-bump cert=/etc/squid/ssl_cert/myCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
sslcrtd_children 5 startup=1 idle=1
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
cache_mem 256 MB
動的証明書の準備とパーミッション
ssl_crtd用のDBを作成:
/usr/lib/squid/ssl_crtd -c -s /var/lib/ssl_db
所有者をsquidに変更し、ディレクトリの権限を適切に設定します。例: chown -R squid:squid /var/lib/ssl_db
テスト方法
1) ブラウザでCAを信頼させる。2) プロキシ経由でHTTPSサイトへアクセス。3) access.logとcache.logでssl_bumpの処理を確認します。
よくあるトラブルと対処
- 証明書生成失敗: /var/lib/ssl_dbの権限を確認
- ポートやフォワード設定: iptablesやルーティングで3129が傍受されているか確認
- ブラウザが警告を出す: CAが信頼されていない可能性
設定変更後はSquidを再起動して動作確認してください。
F5 BIG-IP SSL Orchestratorの例
概要
F5 BIG-IP SSL Orchestratorは企業向けのSSL可視化ソリューションです。暗号化トラフィックを復号してセキュリティ機器へ渡し、必要に応じて再暗号化して送信します。高負荷環境でも性能を保てる設計です。
主な機能
- 高速な暗号化/復号処理（ハードウェア支援や最適化設定）
- 動的なサービスチェーン（IPSやDLPなどを連結）
- ポリシーベースのトラフィック制御（ユーザーやアプリで振り分け）
- 複数トポロジー対応（インライン、タッピング、ミラーポート）
- 可用性と冗長化（クラスタリングで継続稼働）
簡単な導入手順（例）
- トポロジーを選ぶ（ネットワークに合わせてインラインかタップを選択）
- サービスチェーンを定義する（順序や対象を設定）
- 証明書と鍵を準備する（F5の管理CAや既存の証明書を利用）
- ポリシーを作りトラフィックを振り分ける
- ログとモニタリングを有効にして動作を確認する
運用上のポイント
- 証明書管理を自動化すると運用負荷が下がります。例：定期更新や失効処理の自動化。
- セキュリティ機器の負荷を見てサービスチェーンを再編成すると効果的です。
注意点
- 復号処理はプライバシーや法令に関わります。対象範囲を明確にしてください。
- 一部アプリや証明書ピンニングがあると可視化できない場合があります。必要に応じて例外を設定してください。
SSL Bumpingの注意点と課題
プライバシーと法的配慮
SSL Bumpingは利用者の暗号化通信を復号化します。たとえば、個人のオンライン銀行や医療情報も検査対象になり得ます。運用前に社内規定や法令を確認し、利用者への説明や同意を得ることが重要です。
設定と運用の難易度
適切な動作には証明書の管理やプロキシ設定の理解が必要です。誤設定は接続失敗や脆弱性を招きます。運用チームは試験環境で十分に検証し、段階的に適用してください。
セキュリティリスク
中間者としての役割を果たすため、秘密鍵の保護が最優先です。鍵が漏れると大きな被害になります。加えて、最新の暗号化方式やプロトコル変更に追随する必要があります。
パフォーマンスとスケーラビリティ
復号化処理は負荷が高く、遅延や帯域の問題につながります。ハードウェアアクセラレーションやロード分散、キャッシュの活用で対処してください。
運用上の対策例
- 検査対象を限定（社内外の優先度で振り分け）
- 利用者への透明性（通知・同意）
- 鍵管理の厳格化と監査ログの保存
- 定期的な脆弱性チェックとソフトウェア更新
ただし、暗号化トラフィック増加への対応は不可避であり、総合的な設計と継続的運用が求められます。
