😎

TLS 1.3 を「電話のたとえ話」にして、オレオレ詐欺を撃退してみた

に公開
Security
TLS
tech

はじめに

以前書いた『OAuth 2.0 / OIDCを理解するために、自分でGoで実装してみた』の中で、OAuthはTLSにセキュリティを委ねていると触れました。ただ、その前提であるTLS自体を私自身もっと理解する必要があると感じたため、今回はTLSを「電話のたとえ話」に置き換えて整理してみました。

ウェブ通信を守るTLS（Transport Layer Security）のハンドシェイク手順は一見難解ですが、電話での会話になぞらえると直感的に理解できます。TLSは通信内容を暗号化して盗聴を防ぎ、改ざんを検知し、相手の正体を確認する仕組みを提供しています。ここでは、TLSハンドシェイクを電話のやりとりに置き換えて説明し、さらにTLSがどのように様々な詐欺的手口から通信を守るかを見ていきます。

図：TCPハンドシェイク（左）とTLSハンドシェイク（右）の流れ。TLSでは追加のメッセージ交換（ClientHelloやServerHelloなど）によって暗号方式の合意・証明書検証・鍵交換が行われ、通信が保護される。この図のように、TLSハンドシェイクはTCP接続確立後に開始され、セキュアな通信路を準備します。

1. TCPの3ウェイ・ハンドシェイク（電話がつながる）

まずは電話をかけ、通話がつながるまでのやりとりをTCPコネクション確立になぞらえます。TCPの3ウェイ・ハンドシェイクは以下のように行われます。

  • あなた：「もしもし？」（SYN パケット送信）
  • 相手：「もしもし、こちら銀行です」（SYN+ACK 応答）
  • あなた：「はい、聞こえます」（ACK 応答）

→ これで電話回線が開通しました。ただし、この時点では相手が本物の銀行担当者かどうかは確認できていません。接続は確立しましたが、通信相手の認証（身元確認）はまだ行われていないのです。

2. TLSのハンドシェイク（安全な会話の準備）

TCPで通話（通信回線）がつながった後、続いてTLSハンドシェイクを行い、安全に話せる状態を整えます。電話の世界では、第三者に盗み聞きされないように合言葉（暗号）を決めて話すイメージです。TLSハンドシェイクの主な手順は以下の通りです（cloudflare.com）。

(1) 暗号方式の提案と決定:

  • あなた：「これから合言葉を決めて安全に話しませんか？方法は A、B、C があります」
    （ClientHello：クライアントが対応可能なTLSバージョンや暗号スイートを提案）

  • 相手：「じゃあ B 方式でいきましょう。私は◯◯銀行の田中です。社員番号は1234です。本部に確認してもらって構いません。それと、合言葉帳の◯ページを一緒に使いましょう」
    （ServerHello：サーバーが暗号方式Bを選択し、名簿上の登録番号や公開鍵にあたる情報を提示）

  • あなた：「では本部に確認しますね……はい、1234番の田中さんが確かに在籍していると確認できました」
    （証明書検証：CAによる署名の確認）

  • 相手：「この方式で進めるための追加条件もありますので伝えておきます」
    （EncryptedExtensions：追加の拡張情報）

  • 相手：「改めて、公式名簿に登録されている私の情報をお伝えします」
    （Certificate：サーバー証明書の提示）

  • 相手：「さらに、この名簿の情報が私自身のものであることを、私の声紋で確認してください」
    （CertificateVerify：秘密鍵で署名し、公開鍵＝声紋検証で確認）

  • あなた：「声紋を確認しました。確かに本人です」
    （クライアントが証明書に含まれる公開鍵で署名を検証し、正当性を確認）

  • 相手：「これまで使った合言葉が全部ちゃんと揃っていることを確認しました」
    （Finished：サーバー側が通信の整合性を検証）

  • あなた：「こちらも合言葉にズレがないことを確認しました」
    （Finished：クライアント側が通信の整合性を検証）

※「社員番号」や「公式名簿の情報」はサーバー証明書に相当し、「合言葉帳のページ指定」は公開鍵にあたります。クライアント（あなた）は社員番号を本部（CA）に照会し、正しく発行されたものであることを確認した上で、相手が本物の銀行サーバーであると検証します。Finishedメッセージで双方がこれまでのやりとりに食い違いがないことを最終確認し、安全な暗号化通信が開始されます。

ここでのたとえにおいて「社員番号」はサーバーが名乗るID（証明書に記載されたCNやSANのドメイン名など）を表し、
「公式名簿」はCAが署名した正規の証明書そのものを指しています。
本部への確認＝クライアントがCAの公開鍵で署名を検証する動作にあたり、社員番号が本当に正しい人物に属することを保証します。
さらに、ハンドシェイクの過程では毎回新しい乱数や一時鍵が使われるため、合言葉（セッション鍵）は常に更新されます。
その結果、昨日の合言葉（リンゴ）が今日も通用することはなく、リプレイ攻撃の防止にもつながります。

(2) 暗号化した会話の開始:

  • あなた：「ペンパイナッポーアップルペン」（暗号化されたメッセージ送信）
  • 相手：「りんごみかんメロン」（暗号化されたメッセージ応答）

→ 第三者には意味不明なやり取りですが、B方式の合言葉帳（共通の暗号鍵やアルゴリズム）を共有している二人には内容が理解できます。これにより「暗号方式が合意でき、ちゃんと暗号化通信が始まった」と確認できるわけです。実際のTLSでも、この段階でクライアント・サーバー双方がセッション鍵を生成し、以降の通信はその鍵で暗号化されます。そしてハンドシェイクの最後にお互いが“Finished”メッセージを送り合い、ここまでの交信内容に改ざんがないことを確かめてから本格的なデータ通信に入ります。

この電話のたとえで、さっきの図（TCPハンドシェイクとTLSハンドシェイクの流れ）が、より直感的に理解できるはずです。

3. 巧妙な詐欺電話とTLSによる防御

TLSによる暗号化通信は、電話詐欺のように巧妙な攻撃から通信を守っています。電話の世界で起こり得る典型的な詐欺シナリオになぞらえながら、TLSがどのように防御するかを見てみましょう。

オレオレ詐欺①：名簿になりすます

詐欺電話の例:
「オレだよ！ひろしだよ！事故で金が必要なんだ！」と名乗るが、実際にはその名前は家族名簿に存在しない。
つまり 存在しない人物をでっち上げて名乗るパターン です。

TLSの防御:
サーバー証明書がCAによって正しく署名されているかを確認する（証明書検証）。
これにより、公式に登録されていない偽物は弾かれます。

電話のたとえ:

  • 相手：「オレだよ！オレ、ひろしだよ！」
  • あなた：「家族として確認しますね……名簿に“ひろし”という登録はありません！」

→ 名簿照合で「存在しない人物」を名乗る詐欺を撃退できます。
これがTLSにおける 証明書検証（CA署名確認） に対応します。

オレオレ詐欺②：本人になりすます

詐欺電話の例:
「オレだよ！ひろしだよ！」と名乗り、名前は正しいが、実際には他人がなりすましている。
つまり 本物の名前を悪用して本人のフリをするパターン です。

TLSの防御:
サーバーが証明書に含まれる公開鍵とペアの秘密鍵を持っていることを署名で証明する（CertificateVerify）。
秘密鍵は本人しか持っていないため、これを通過できるのは正真正銘の本人だけです。

電話のたとえ:

  • 相手：「オレだよ！ひろしだよ！」
  • あなた：「じゃあ声紋を確認させて」
  • 相手：「……（声が一致しない）」
  • あなた：「やっぱり本人じゃないね」

→ 名前を知っていても、声紋（秘密鍵署名）を通過できなければ本人ではないとバレます。
これがTLSにおける CertificateVerify に対応します。

中間者攻撃（盗聴・改ざん）

詐欺電話の例:
通話の途中に第三者（詐欺犯）が密かに割り込み、会話を盗み聞きしたり内容を書き換えたりする攻撃です。例えばあなたと銀行員の会話に犯人が介入し、「振込先は△△銀行の○○口座です」などと偽の情報を伝えてしまうケースです。話し手と聞き手のあいだに第三者が入って情報をすり替えるため、気づかないと非常に危険です。

TLSの防御:
通信内容はTLSによってすべて暗号化されているため、第三者が盗み聞いても意味のある内容は得られません。また、ハンドシェイクの最後には双方がFinishedメッセージを用いて、それまでの通信が改ざんなく一致しているかを相互に検証します。万一途中のデータが書き換えられていれば検証が失敗し、通信は即座に遮断されます。つまりTLSは機密性（盗聴されないこと）と完全性（改ざんされていないこと）を同時に担保しているのです。

電話のたとえ:

  • あなた：「ペンパイナッポーアップルペン」（暗号化されたメッセージ送信）

  • 相手：「りんごみかんメロン」（暗号化されたメッセージ応答）
    → 第三者が聞いても意味不明で、盗聴しても内容は分からない。

  • 相手：「最初に“ペンパイナッポー”、次に“アップル”、最後に“ペン”って言いましたよね？」

  • あなた：「はい、私の記録とも一致しています。食い違いはありません」
    → これまでの合言葉の流れを突き合わせ、改ざんされていないことを確認している。

フィッシング詐欺（偽サイトへの誘導）

詐欺電話の例:
「こちら◯◯銀行です。口座の暗証番号を教えてください」と、本物の銀行を装った偽の担当者が電話をかけてくる手口です。巧みに本物らしい名乗りや雰囲気で油断させ、個人情報を聞き出そうとします。しかし電話の相手が本当に銀行かどうかは、電話番号などを確認しないと判断できません。

TLSの防御:
TLSではサーバーが提示する証明書（Certificate）に書かれたドメイン名と、ユーザーがアクセスしたURLのホスト名を必ず照合します。例えば本来アクセスすべき銀行サイトが www.bank.co.jp なのに、証明書に www.fake-bank.com と書かれていれば不一致となり、TLS接続はエラーになります。
この「ドメイン名照合」によって、見た目だけ似せた偽サイト（フィッシングサイト）を判別できます。正規の銀行サイトであれば証明書のドメイン名とURLが一致するため、TLS接続が問題なく確立し「本物の銀行と通信している」ことが保証されます。

電話のたとえ:

  • 相手：「もしもし、こちら◯◯銀行です。ご本人確認のため生年月日を…」
  • あなた：「念のためお電話番号を確認させてください。ええと、この番号は公式サイトに載っている代表電話とは違いますね？」

→ 偽の業者は公式の電話番号とは異なる番号からかけてくるものです。番号を照らし合わせれば「おかしい」とすぐ見抜けます。
同様にTLSでも、証明書に記載されたドメイン名と実際にアクセスしたドメイン名が一致しなければ通信を拒否します。「見た目が本物っぽいかどうか」ではなく、証明書とアクセス先の一致によってフィッシング詐欺を防いでいます。

リプレイ攻撃（録音音声の再生）

詐欺電話の例: 以前に交わした通話を犯人が録音しておき、その音声を後から再生することで再び騙そうとする手口です。たとえば先日相談した銀行員を装い、「先日の件ですが、やはり指定の口座に振り込んでください…」と録音音声で電話をかけ、前回の続きであるかのように装います。過去の正規の会話を再利用することで安心させ、お金を振り込ませようと狙います。

TLSの防御: TLSではリプレイ攻撃への対策として、セッションごとに毎回新しい一時的な鍵（エフェメラル鍵）を生成します。またハンドシェイクで交換するランダム値（Nonce）や、通信メッセージごとに振られるシーケンス番号（通し番号）を利用し、一度使われた通信内容が再度使い回されても通用しない仕組みを備えています。つまり、仮に攻撃者が過去の通信データを盗み出して後で送りつけてきても、鍵が毎回変わるため別セッションでは復元できず整合性チェックに失敗します。さらに同一セッション内でも、再生された古いメッセージはシーケンス番号の不一致によって検出され、受信側で破棄されます。こうした対策により、録音データの使い回しによる欺瞞は防がれるのです。

電話のたとえ:

  • 相手：「『キリン』です」（※昨日の会話を録音して再生している）
  • あなた：（昨日の電話では『キリン』が合言葉だったけど今日の正しい合言葉は『ゾウ』のはず…録音を再生しているのかもしれない）「いえ、合言葉が違いますね。それはおかしいですよ」

→ 昨日決めた合言葉（キリン）は今日には通用しません。このように、過去の会話内容（録音音声）を使い回そうとしても、その時々で変わる合言葉（セッション鍵やワンタイムの値）が一致しなければ不正が発覚します。TLSにおいても、一度限りの鍵やNonce、連番による検証により、リプレイ攻撃を失敗に終わらせます。

ダウングレード攻撃（暗号なし通信への誘導）

詐欺電話の例: 「暗号なんて面倒でしょう？やめて普通の会話にしましょうよ」と相手が巧みに誘導し、合言葉（暗号化）を使わない生の会話に持ち込もうとするケースです。暗号化されていない会話になれば、盗聴や改ざんが容易になるため攻撃者にとって好都合です。セキュリティ意識が低い相手だと騙されてしまうかもしれません。

TLSの防御: 最新のTLS 1.3では、安全でない暗号方式や古いバージョンのTLSを最初から許可しない設計になっており、暗号化しない通信モードそのものが選択肢に存在しません。仮に攻撃者がハンドシェイクの途中で弱い暗号や旧式のプロトコルに降格させようと細工しても、TLS1.3にはその企みを検知して接続を切断する仕組みがあります。実際、TLS1.3のサーバーは古いTLSバージョンへの交渉を強いられた際、ハンドシェイクメッセージ内に特定の識別子（ダウングレード発生フラグ）を書き込み、クライアント側がそれを見つけたら通信を拒否するという対策が標準で組み込まれています。これにより攻撃者は安全でない通信への誘導を行えません。

電話のたとえ:

  • 相手：「合言葉なんて使わずに、最初から普通に話しましょうよ」
  • あなた：「いいえ、セキュリティのため合言葉は必須です。合言葉なしで話すことはできませんよ」

→ 暗号化しない会話に持ち込もうと誘導されても、そもそも「合言葉なし」で話すこと自体がルール違反で許されないのです。結果として会話のセキュリティが損なわれることはなく、盗聴や改ざんの機会も与えません。TLS1.3では初めから安全でない方式を排除し、ダウングレード攻撃を原理的に封じ込めているのです。

詐欺電話とTLS防御の対比まとめ

最後に、上記の電話詐欺シナリオとTLSによる防御策の対応を表にまとめます。

詐欺電話の手口（攻撃手法） TLSが提供する防御策 電話でのたとえ（対処法）
オレオレ詐欺①（名簿になりすます） サーバ証明書＋CA署名による身元確認 「名前を名乗らせて本部の名簿で照合する」
オレオレ詐欺②（本人になりすます） CertificateVerifyで秘密鍵所持を確認 「声紋を確認して本人かどうか検証する」
盗聴・改ざん（中間者攻撃） 通信の暗号化＋Finished検証による改ざん検知 「合言葉帳で暗号化」＋「合言葉の整合性を互いに確認」
フィッシング（偽サイト誘導） 証明書のドメイン名照合による真正性確認 「発信元の番号を公式な電話番号と照合して確認」
リプレイ攻撃（録音の再生） エフェメラル鍵＋Nonce＋シーケンス番号による再利用防止 「日替わりの合言葉を確認し、録音音声を無効化」
ダウングレード攻撃（暗号省略誘導） 安全でない暗号方式・古いTLSバージョンの排除（降格検知） 「合言葉なしの提案を拒否し、安全性を維持」

まとめ

ここまで、TLS 1.3 のハンドシェイクを電話の会話になぞらえて説明し、オレオレ詐欺をはじめとする典型的な通信攻撃とTLSの防御策を照らし合わせて見てきました。

TCPの3ウェイハンドシェイクは「もしもし」で回線がつながるだけであり、相手が本物かどうかの保証はありません。その上にTLSのハンドシェイクが乗ることで、暗号方式の合意、証明書による名簿照合、秘密鍵署名による本人確認、Finishedによる改ざん検知といったステップを経て、初めて「安心して会話できる状態」が整います。

さらにTLS 1.3 では、毎回新しい乱数や一時鍵（KeyShare）を使うことでセッションごとに合言葉（セッション鍵）が更新され、リプレイ攻撃も防げる仕組みになっています。つまり TLS は、盗聴・改ざん・なりすまし・録音再利用・ダウングレード誘導といった様々な詐欺的攻撃に対して、多層的な防御を提供しているのです。

TLS があることで、インターネット通信はまるで「信頼できる相手と秘密の合言葉で会話する電話」のように守られています。相手が本物であることを確認し、内容が盗聴や改ざんされないことを保証する TLS は、現代における最強のオレオレ詐欺撃退マニュアルといっても過言ではありません。

TLS の仕組みを理解することは、単に通信の安全性を知るだけでなく、なぜ証明書の検証や最新バージョンの利用が重要なのかを腹落ちさせる助けになります。今回のたとえ話を通じて、TLS 1.3 がいかにして安全性と信頼性を確保しているか、その全体像が直感的に掴めたと思います。

これからHTTPSや認証の仕組みに触れる際には、「オレオレ詐欺を撃退する電話のやりとり」を思い出してもらえれば、TLS の動きがぐっと理解しやすくなるでしょう。

Discussion