情報処理安全確保支援士 2011年 秋期 午後1 問03

解答の論理構成

1. 【問題文】では、T社のルールとして「各従業員のインターネットサイトへのアクセス状況を記録するために、アクセスログを取得すること及びインターネットサイトに向けて送信された内容をログとして取得すること」を要求しています。
2. 一方、下線①の前段に「インターネットサイトへの HTTPS 通信によるアクセスを原則として禁止している」とあります。HTTPS は通信内容を暗号化するため、プロキシはパケットを解析できず、(1) どの URL にアクセスしたか、(2) POST/PUT で何を送信したか、といった詳細を平文で取得できません。
3. つまり、HTTPS を許可すると「アクセス状況」「送信内容」をルールどおりに取得・保存できなくなるので、アクセス制御の根拠が失われます。
4. したがって、設問（1）の理由は「ログを平文で記録できないから」となります。

誤りやすいポイント

• 「セキュリティを高めるために暗号化通信を禁止している」と勘違いしやすいですが、目的は暗号化そのものではなく“ログ取得・内容把握”です。
• 「ウイルスチェックができないから」と答えてしまうケースがありますが、問題文は送信内容とアクセス状況の記録を強調しており、ウイルスチェックは副次的機能です。
• HTTPS でもUプロキシ経由ならヘッダだけは見えるのでは、と思いがちですが、TLS 1.2 以前でもURLパスやPOSTデータは暗号化されるため取得不能です。

FAQ

解答の論理構成

1. 【問題文】では、U プロキシ経由の HTTPS 通信について
   「“Uプロキシを利用したHTTPS通信では、暗号化された通信路をブラウザとWebサーバ間で確立する。”」
   と記載されており、U プロキシは暗号化されたペイロードを復号できません。
2. 図2(2)「アクセスログ取得機能」は
   「“HTTP リクエストごとに…リクエストライン（HTTP メソッド、URL、HTTP プロトコルのバージョン）”」
   を取得するとあります。リクエストラインは TLS で暗号化されるため、U プロキシは取得できず、利用目的を達成できません。
3. 図2(3)「送信内容取得機能」は
   「“送信内容を取得する。”」
   とありますが、POST／PUT のボディは暗号化されているため取得不能です。
4. 図2(5)「ウイルスチェック機能」は
   「“送受信データ内のウイルスをチェックする。”」
   とあります。データ本体が暗号化されているので検査できません。
5. 図2(1)「利用者認証機能」は Proxy-Authorization ヘッダを HTTP CONNECT 要求に付与する方式であり、TLS セッション確立前に行われるため問題なく機能します。
6. 図2(4)「フィルタリング機能」は HTTPS に対して「“ホワイトリスト方式で…ホストの FQDN に基づいたアクセス規制”」と明記されており、CONNECT 要求に含まれる FQDN だけで判定できるので達成可能です。
7. 以上より、HTTPS 通信によって利用目的を達成できなくなるのは (2)、(3)、(5) です。

誤りやすいポイント

• 「アクセスログ取得機能は IP アドレスだけでも成立する」と誤解しやすいですが、図2には URL まで取得すると明示されており、TLS で見えなくなります。
• フィルタリング機能も HTTPS では無力と思い込みがちですが、ホワイトリスト方式で FQDN を参照するため CONNECT 要求だけで判定できます。
• 利用者認証ヘッダが暗号化後に送られると勘違いし、(1) を選択してしまうケースがあります。実際には TLS 握手前なので平文です。

FAQ

解答の論理構成

1. ブラウザが https:// で始まる URL を入力すると、暗号化通信（TLS/SSL）を開始するためにプロキシとの間でトンネルを確立する必要があります。
   引用：
   • 「Uプロキシを利用したHTTPS通信では、暗号化された通信路をブラウザとWebサーバ間で確立する。」
2. HTTP/1.1 仕様では、このトンネル確立要求を行うメソッドとして “CONNECT” が定義されています。リクエストラインは
   CONNECT 送信先ホスト:ポート HTTP/1.1
   という形式になります。
3. https://○○.co.jp/index.html の既定ポートは “443” なので、ホスト名とポート番号を組にして ○○.co.jp:443 と指定します。
4. 以上より、最初に送られるリクエストラインは
   「CONNECT ○○.co.jp:443 HTTP/1.1」
   に一致するため、解答群では “ア” が正しいと判断できます。

誤りやすいポイント

• 「GET ○○.co.jp:443/index.html HTTP/1.1」を選ぶミス
  HTTPS では最初に GET は送られず、トンネル確立後に暗号化された GET が流れる点を見落としがちです。
• ポート番号の省略
  CONNECT ではポート番号指定が必須です。○○.co.jp だけでは不完全となります。
• “SSL” という非標準メソッドの選択
  HTTP メッセージのメソッドに “SSL” は存在しません。

FAQ

解答の論理構成

1. 問題文の引用
   「S部長：HTTPS通信でWebサーバのサーバ証明書の正当性を確認しないまま、ブラウザがアクセスを継続すると、偽サイトに誘導された場合でなくても、a攻撃を受けて、通信を盗聴される可能性がある…」
2. “通信を盗聴される”という結果をもたらす代表的な攻撃
   ・暗号化通信を第三者が途中で解読・改ざんする典型的な手口は“Man-in-the-Middle”であり、日本語では「中間者攻撃」または単に「中間者」と呼ばれます。
3. 証明書の検証が行われない場合の脅威
   ・ブラウザが提示されたサーバ証明書を検証しない → 攻撃者が途中で偽装した証明書を提示しても接続が成立 → 攻撃者が暗号化通信を復号・再暗号化できる状態になる。
4. よって a に入る語は「中間者」と導けます。

誤りやすいポイント

• 「盗聴」というキーワードからパケットキャプチャのみを連想し、「盗聴攻撃」と答えてしまう。
• HTTPS ＝安全と早合点し、証明書検証の欠如がどのような脅威を招くかを見落とす。
• 「中間者攻撃」「MITM」など複数の表現が頭に浮かび、設問が求める“漢字二文字”の「中間者」を選び損ねる。

FAQ

解答の論理構成

1. 【問題文】には「a攻撃を受けて、通信を盗聴される可能性がある」とあり、ここで言う “a攻撃” は暗号化通信の盗聴・改ざんを狙う “中間者攻撃” である。
2. 中間者攻撃では攻撃者が本物のサーバと利用者の間に割り込み、偽のサーバ証明書を提示して通信内容を傍受する。
3. これを防ぐには、ブラウザがサーバ証明書を検証し、 ・「サーバ証明書のコモンネーム (CN) がアクセス先ホスト名と一致する」
   ・「サーバ証明書がブラウザの信頼済み認証局によって発行されている」
   ことを確認する必要がある。
4. 上記2点を満たさない証明書は攻撃者が用意した可能性が高いため、接続を遮断することで中間者攻撃を防止できる。
5. したがって解答は
   ①「サーバ証明書のコモンネームとアクセス先のホスト名が一致すること」
   ②「サーバ証明書がブラウザで信頼する認証局から発行されていること」
   となる。

誤りやすいポイント

• CRL や OCSP など失効確認を優先して記述してしまう。もちろん重要だが、設問は “a攻撃” 対策として「ブラウザが確認すべき内容」を問うているため、まず CN の一致と信頼できる発行元の確認が本筋である。
• “証明書の有効期限内であること” を挙げるミス。期限切れ証明書は接続拒否要因にはなるが、中間者攻撃そのものを直接防ぐ項目ではない。
• 「フィンガープリントを比較する」と記述する誤答。フィンガープリントは証明書偽造検出に役立つが、ブラウザが自動的に行う通常検証手順としては CN と CA への信頼が基本である。

FAQ

解答の論理構成

1. 本文には、Lプロキシ導入時の課題として
   「②ブラウザは証明書2の検証において、証明書2の正当性を確認できない」
   と明記されています。
   これはブラウザが “証明書2” を発行した認証局（＝Lプロキシ自身）を信頼していないためです。
2. Lプロキシは MITM 型の SSL 可視化機能を持ち、Web サイトの “証明書1” を検証後、同一コモンネームで “証明書2” を動的発行してブラウザへ渡します。
3. ブラウザが “証明書2” を正当と判断する条件は、発行元 CA のルート証明書がブラウザの信頼ストア内に存在することです。
4. そこで K 主任は
   「証明書2の正当性を確認できるようにするためには、事前にブラウザでb必要があります。」
   と回答しており、b に入る行為は、Lプロキシのルート証明書を信頼ストアへ登録することになります。
5. 以上より解答は
   Lプロキシのルート証明書を信頼するルート証明書としてインストールする
   が導かれます。

誤りやすいポイント

• 「証明書1」をブラウザに配布すると勘違いし、Web サーバ側の証明書を登録しようとしてしまう。
• ルート証明書ではなく中間証明書やサーバ証明書を登録してしまい、検証が失敗する。
• ブラウザ設定ではなく OS の証明書ストアに入れれば十分と誤認し、共有端末の複数ブラウザで検証エラーが残る。
• ルート証明書を入れることによるセキュリティリスク（社外持ち出し端末での信頼範囲拡大）を見落とす。

FAQ

解答の論理構成

1. 問題文は、L プロキシが自ら認証局となり「証明書1と同じコモンネームのサーバ証明書（以下、証明書2という）を新たに作成し、ブラウザに送る」と述べています。
2. しかし下線②で「ブラウザは証明書2の検証において、証明書2の正当性を確認できない」と指摘されています。
3. ブラウザがサーバ証明書の正当性を判断する仕組みは“信頼できる認証局の公開鍵証明書（ルート証明書）との署名検証”です。
4. L プロキシが独自に発行した証明書2は、通常のブラウザにプリインストールされている公的認証局のリストには含まれません。つまり署名チェーンの末端にある“信頼の根”をブラウザが持っていないため、検証できません。
5. そこで K 主任が述べる「事前にブラウザでb必要があります」は、L プロキシ自身のルート証明書（自己署名証明書など）を信頼ストアに登録する作業を指します。
6. 以上より、模範解答「証明書2はブラウザが信頼する認証局が発行したものではないから」が導かれます。

誤りやすいポイント

• 「証明書2のコモンネームが一致しているから検証できる」と誤解しやすいが、検証では“発行元（認証局）の信頼性”が最重要です。
• 「L プロキシが証明書1を検証するのでブラウザ側は不要」と混同しやすい。ブラウザは別通信路で証明書2を受け取るため、自身で検証が必須です。
• 「HTTPSは暗号化されているから安全」と考え、認証局チェックを軽視してしまう失点が多いです。

FAQ

解答の論理構成

• 【問題文】は、Lプロキシが「証明書1と同じコモンネームのサーバ証明書（以下、証明書2という）を新たに作成し、ブラウザに送る」と述べています。
• ブラウザ側では「ブラウザは証明書2の検証において、証明書2の正当性を確認できないのではないか」とする一方で、検証そのものは行う前提です。
• ブラウザの HTTPS 通信は、接続先ホスト名と受け取ったサーバ証明書のコモンネームが一致しなければ警告・接続拒否を行います（証明書名義不一致エラー）。
• もし Lプロキシ自身のコモンネーム（例：proxy.t-co.jp）の証明書をそのままブラウザへ渡すと、利用者がアクセスしようとしている「○○.co.jp」とコモンネームが不一致となり、ブラウザが安全な通信と認めません。
• そこで Lプロキシは、Web サーバが提示した「証明書1」のコモンネームをコピーした「証明書2」を生成し、ブラウザに提示することで「アクセス先のホスト名＝証明書のコモンネーム」の一致条件を満たし、HTTPS セッションを正立させます。

誤りやすいポイント

• 「復号目的だから Lプロキシ自身の証明書でよい」と思い込み、ブラウザ側検証の失敗を見落とす。
• コモンネーム以外（有効期限、鍵長など）を理由に挙げてしまい、根本的な“ホスト名一致”要件を外してしまう。
• 「証明書2は自己署名だから無条件に失敗する」と勘違いし、ブラウザに Lプロキシのルート証明書をインポートすれば検証できる点を忘れる。

FAQ