ICT STUDY GUIDEモバイルの用語モバイル2級

TLSとは|HTTPSの仕組みとモバイル2級の要点

TLSが通信で守る3つのこと、TLS 1.3のハンドシェイクの流れ、TLS 1.2から変わった点を表で整理。RFC 8446と2026年7月のRFC 9846の関係、モバイル2級で迷いやすい点と独自の確認問題3問つき。

最終更新
読了目安
約11分
執筆
ICT模試 編集部
まず結論

この記事の要点

  • TLS は、通信相手の認証・通信内容の暗号化・改ざんの検知を行うプロトコルで、HTTPS は HTTP を TLS で保護したものです。
  • TLS 1.3 は RFC 8446(2018年8月)で定められ、2026年7月に同じ TLS 1.3 のまま内容を整理した RFC 9846 に置き換えられました(2026年9月時点)。
  • TLS 1.3 では、通常の接続が1往復で始められ、ServerHello より後のハンドシェイクが暗号化され、前方秘匿性のない鍵交換が廃止されました。
  • TLS 1.0 と 1.1 は RFC 8996(2021年)で廃止が定められ、使うべきでない版とされています。

TLSとは、ひと言でいうと何か?

一言でいうと、TLS(Transport Layer Security)は、アプリケーションの通信を「相手を確かめ、中身を隠し、書き換えを見つけられる」状態にするためのプロトコルです。前身の SSL の名前が残り、「SSL/TLS」とまとめて呼ばれることもあります。

HTTPS は、Web の通信(HTTP)を TLS で保護したものです。ブラウザのアドレス欄が https で始まるとき、ブラウザとサーバの間では TLS による接続が確立しています。メールの送受信やアプリの API 通信など、Web 以外でも広く使われています。

TLSが守るもの(当サイトの整理)
守るもの使う仕組み防ぎたいこと
相手の認証サーバ証明書と、秘密鍵による署名偽のサーバへの接続(なりすまし)
機密性ハンドシェイクで共有した鍵による共通鍵暗号通信の盗聴
完全性認証付き暗号(AEAD)による検証通信途中での書き換え

暗号方式の組み合わせ(公開鍵暗号で鍵を共有し、本文は共通鍵暗号で守る)は共通鍵暗号と公開鍵暗号の違い、証明書の検証は電子証明書とPKIとはで詳しく扱っています。

TLS 1.3のハンドシェイクは、どんな流れか?

ハンドシェイクは、暗号化通信を始める前に、使う方式を決めて鍵を共有し、サーバを確かめる手続きです。TLS 1.3 の通常の接続は、次のように1往復(1-RTT)で終わります。図と手順で、メッセージの向きと役割を整理します。

暗号化と相手の確認:通信を保護することと、接続相手を確かめることを分けた比喩です
通信を保護することと、接続相手を確かめることを分けた比喩です。HTTPSであることだけで、サイトの内容や運営者の取引まで安全と保証されるわけではありません。
TLS 1.3 の通常のハンドシェイク(1-RTT)
  1. 1

    ClientHello

    クライアント → サーバ。対応する暗号方式の一覧と key_share

  2. 2

    ServerHello

    サーバ → クライアント。選んだ方式とサーバ側の鍵共有の値。以降は暗号化

  3. 3

    証明書と署名

    EncryptedExtensions・Certificate・CertificateVerify・Finished(暗号化)

  4. 4

    Finished

    クライアントが証明書と署名を検証してから送る(暗号化)

  5. 5

    アプリケーションのデータ

    HTTP のリクエストなどを暗号化して送受信

1往復で鍵を共有し、ServerHello より後のハンドシェイクは暗号化される。

  1. クライアント → サーバ:ClientHello。対応する暗号方式の一覧と、鍵共有のための値(key_share)を送る。
  2. サーバ → クライアント:ServerHello。選んだ方式と、サーバ側の鍵共有の値を返す。この時点で両者は同じ鍵を計算でき、以降のハンドシェイクは暗号化される。
  3. サーバ → クライアント(暗号化):EncryptedExtensions(追加の設定)、Certificate(サーバ証明書)、CertificateVerify(秘密鍵を持っていることを示す署名)、Finished(ここまでのやり取りの確認)。
  4. クライアント → サーバ(暗号化):証明書と署名を検証してから Finished を送る。
  5. 以降、アプリケーションのデータ(HTTP のリクエストなど)を暗号化して送受信する。

前回つないだサーバに再接続するときは、以前に共有した値を使って最初のメッセージと一緒にデータを送る 0-RTT という方式もあります。速い反面、RFC 8446 は 0-RTT のデータには再送(リプレイ)への保護がないと注意しており、繰り返されても困らない要求に限って使う必要があります。

HTTP/3 で使う QUIC も、TLS 1.3 のハンドシェイクを取り込んで暗号化しています(RFC 9001)。違いはHTTP/2とHTTP/3(QUIC)の違いで整理しています。

TLS 1.3:誰が、どちらへ送るか

クライアント

サーバー

  1. 1. クライアント → サーバー

    ClientHello

    対応方式と鍵共有の値を送る

  2. 2. サーバー → クライアント

    ServerHello

    選んだ方式と鍵共有の値を返す

  3. 3. サーバー → クライアント

    証明書・署名・Finished

    暗号化されたメッセージで相手とやり取りを確認する

  4. 4. クライアント → サーバー

    Finished

    サーバーの証明書と署名を検証して応答する

通常接続の一例。鍵を共有した後、アプリケーションのデータも暗号化して送受信する。

本文とRFC 8446の通常の証明書認証を基にした省略図。再接続・0-RTT・クライアント証明書などは省略。 矢印の長さと段の間隔は、時間・距離を表しません。

暗号化された0-RTTでも、同じ注文が届く可能性は残る

再接続でTLSの早期データを使うと、接続確立を待たずにHTTPの要求を送れる場合があります。暗号化されていても、受信側で同じ要求を繰り返し処理する危険は残ります。RFC 9846の0-RTTの注意と、HTTPでの取り扱いを定めるRFC 8470を分けて読んでください。

たとえば読み取り専用の公開カタログを表示するだけなら、同じ表示要求が届いても注文は増えません。注文を作成する要求は、複製されたときに注文が重複するおそれがあります。操作の安全性が確認できない要求や状態を変更する通常の要求は早期データに載せません。

HTTPの要求同じ要求が繰り返されたとき
読み取り専用の公開カタログ表示を繰り返す。実際に状態を変更しないことを確かめる
注文の確定重複注文などの影響がある。接続確立を待つ
早期データで送信し425が返った再試行は早期データを使わずに行う

425 Too Earlyは、サーバーが再生されるおそれのある要求の処理を見送るときに使うHTTPの状態コードです。TLS接続の速度と、HTTP操作の安全性を同じものとして扱いません。通信方式の整理はHTTP/2とHTTP/3の違いへ。

TLS 1.3で、1.2から何が変わったのか?

RFC 8446 は、TLS 1.2 からの主な違いとして、古い暗号方式の削除、前方秘匿性のない鍵交換の廃止、ServerHello 以降のハンドシェイクの暗号化、0-RTT の追加などを挙げています。試験対策としては、次の表の「変わった向き」を押さえておけば十分です。

TLS 1.2と1.3の比較(RFC 8446 をもとに当サイトが整理)
観点TLS 1.2TLS 1.3
通常の接続にかかる往復2往復1往復(再接続では 0-RTT も可)
鍵交換静的な RSA 鍵交換なども選べたDiffie-Hellman 型のみで、前方秘匿性が必ずある
暗号方式古い方式も選べた認証付き暗号(AEAD)に限定
ハンドシェイクの暗号化証明書などは暗号化されずに送られるServerHello より後は暗号化
削除された機能―圧縮、再ネゴシエーション、DSA など

前方秘匿性とは、サーバの秘密鍵が後から漏れても、過去に記録された通信を復号できない性質です。接続ごとに使い捨ての鍵共有を行うことで実現します。

規格の番号にも注意が必要です。2026年7月に公表された RFC 9846 は RFC 8446 を置き換えましたが、版の名前は TLS 1.3 のままで、実装の経験から分かった点の明確化などが中心です(2026年9月時点)。4択で「TLS 1.3 の規格」を問われた場合、問題文の時点によって RFC 8446 と書かれていることがあります。

モバイル2級ではどの範囲で、どう問われそうか?

MCPC の公式ページでは、モバイルシステム技術検定2級(100問・100分・4者択一)の出題カテゴリに「情報セキュリティ管理」があり、比率は9%と示されています(2026年9月27日確認)。当サイトでは、公式テキスト『モバイルシステム技術テキスト 第11版』の第11章「情報セキュリティ」がこの範囲に当たると推定しています(公式の発表ではなく、章名からの判断です)。HTTPS はインターネット技術の分野とも重なります。

4択では、次のような観点が考えられます。出題頻度は公表されていないので、特定の型が多いとは言えません。

  • TLS の役割:認証・暗号化・改ざん検知と、TLS が担わない機能(経路の選択など)を見分けさせる。
  • 版の違い:TLS 1.3 で変わった点、廃止された版を問う。
  • ハンドシェイク:証明書が送られる段階や、鍵を共有する方法を問う。
  • HTTPS の意味:鍵マークが保証する範囲を言いすぎた記述を不適切として選ばせる。

試験全体の形式・日程・受検料はモバイルシステム技術検定2級とはにまとめています。情報・サイバーセキュリティ管理士でのネットワーク・Webの論点はネットワーク・Webセキュリティの対策で扱っています。

鍵マークが示す範囲と言いすぎを区別する

通信の保護

  • 接続相手を証明書などで確かめる
  • 通信内容の暗号化・改ざん検知

別に必要な確認

  • 掲載内容が正しいか
  • 店や運営者を信頼できるか

TLSを使うサイトでも、内容や商取引の安全性までは保証しない。

本文の内容を当サイトが図に整理したものです。配置や面積は数量・出題比率を表しません。

どこで取り違えやすいのか?

TLS は「何を守り、何を守らないか」の線引きで迷いやすい用語です。

つまずき別の見直し表
取り違え正しい考え方確認する問い
HTTPS なら安全なサイト守るのは通信の経路。サイトの運営者や内容の安全までは保証しない証明書は何を確かめているか
本文を公開鍵暗号で暗号化する本文は共有した鍵による共通鍵暗号で暗号化する重い処理を大量のデータに使っていないか
TLS 1.3 は2往復通常の接続は1往復。再接続では 0-RTT も使える何回やり取りすれば暗号化が始まるか
0-RTT はいつでも使える再送への保護がないため、使える要求が限られる同じ要求が2回届くと困るか
TLS は端末内のデータも守る守るのは通信中のデータ。保存データは別の暗号化で守るデータは送信中か、保存中か
SSL と TLS 1.0 もまだ使えるTLS 1.0・1.1 は RFC 8996 で廃止。SSL はさらに古い前身その版は現在使ってよいとされているか

確認問題1

TLSの役割を選べるか?

TLS が通信に対して提供する機能の組合せとして、最も適切なものはどれか。

選択肢を準備しています。「正解と解説を見る」は先に開けます。

正解と解説を見る

正解:4。TLS は、証明書と署名による相手の認証、共有した鍵による暗号化、認証付き暗号による改ざんの検知を提供します。

1は経路制御や TCP などが担う機能です。2は業務端末を管理する MDM の機能です。3は送信ドメイン認証(DMARC など)の機能で、メールの中身を暗号化する仕組みではありません。

確認問題2

TLS 1.3の特徴を見分けられるか?

TLS 1.3 に関する記述として、最も適切なものはどれか。

選択肢を準備しています。「正解と解説を見る」は先に開けます。

正解と解説を見る

正解:2。TLS 1.3 では ServerHello の時点で鍵を共有できるため、証明書を含む以降のハンドシェイクが暗号化されます。

1は逆で、TLS 1.3 は静的な RSA 鍵交換を廃止し、前方秘匿性のある鍵共有だけを使います。3も逆で、通常の接続は1往復に短縮されました。4は、RFC 8446 が 0-RTT のデータには再送への保護がないと注意している点に反します。

確認問題3

HTTPSが保証する範囲を判断できるか?

次の記述ア・イの正誤の組合せとして、正しいものはどれか。

ア:HTTPS で接続できていれば、そのサイトの運営者が信頼できる組織であることも保証される。

イ:TLS 1.0 と TLS 1.1 は、RFC 8996 によって廃止が定められ、使うべきでない版とされている。

選択肢を準備しています。「正解と解説を見る」は先に開けます。

正解と解説を見る

正解:3。アは誤りで、HTTPS が示すのは、証明書のドメインの持ち主と暗号化された通信をしていることです。偽サイトでも自分のドメインの証明書を取得して HTTPS にできます。イは RFC 8996 の内容として正しい記述です。

1と2はアを正しいとしている点、4はイまで誤りとしている点で当てはまりません。

ほかのセキュリティ用語も本番の形式で試したい場合は、登録不要のモバイル2級の無料お試し20問で、4択と解説を確認できます。

よくある質問

SSL と TLS は同じものですか?

TLS は SSL を元に作られた後継のプロトコルです。慣習で「SSL 証明書」「SSL/TLS」と呼ばれることがありますが、現在使われているのは TLS 1.2 と TLS 1.3 です。

RFC 8446 と RFC 9846 のどちらを覚えればよいですか?

どちらも TLS 1.3 の規格で、RFC 9846(2026年7月)が RFC 8446(2018年8月)を置き換えました。版の名前は変わっていないので、まず「TLS 1.3 の特徴」を理解し、規格番号は問題文の時点に合わせて読むのが確実です。

公衆 Wi-Fi でも HTTPS のサイトなら安全ですか?

HTTPS の通信内容は Wi-Fi の上でも暗号化されるため、盗聴への強さは上がります。ただし、偽のアクセスポイントから偽サイトへ誘導される危険などは残るため、証明書の警告を無視しない、Wi-Fi 側の暗号化も確認する、といった対策と組み合わせます。

出典・参考

  1. [1]MCPC モバイルシステム技術検定[2級](出題カテゴリと比率、確認 2026-09-27)
  2. [2]RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3(確認 2026-09-27)
  3. [3]RFC 9846 The Transport Layer Security (TLS) Protocol Version 1.3(2026年7月、確認 2026-09-27)
  4. [4]RFC 8996 Deprecating TLS 1.0 and TLS 1.1(確認 2026-09-27)
  5. [5]RFC 9001 Using TLS to Secure QUIC(確認 2026-09-27)
  6. [6]IETF RFC 8470 §4・§5.2:HTTPの早期データと425(2026年11月11日確認)

本番と同じペースで腕試し

記事の次は、本番形式の問題で。

各検定の出題カテゴリをもとに作った独自の無料お試しを、登録不要・カード不要で解けます。本番と同じ出題配分とは限りません。続きの模試と章別ドリルは買い切りで、月額はかかりません。

モバイルシステム技術検定 2級

100問・100分の模試と章別ドリル・¥4,980(税込・買い切り)

モバイル2級の無料お試し20問
料金と収録内容を見る →

当サイトは、MCPC・全日本情報学習振興協会・IPAとは関係のない個人が運営する非公式の学習教材です。掲載している問題はすべて当サイトのオリジナルで、実際の試験問題・過去問題・再現問題ではありません。試験の日程・受検料・出題範囲・合格基準は各試験の公式サイト(モバイル・IoT:https://www.mcpc-jp.org/license/ 、サイバー管理士:https://www.joho-gakushu.or.jp/isme/ 、情報セキュリティマネジメント(SG):https://www.ipa.go.jp/shiken/kubun/sg.html )で必ず確認してください。教材内の正答率や学習の目安は、本番の評価点や公式の合格基準とは異なります。合格を保証するものではありません。技術・制度の記述は「最終確認日」時点のものです。

← 対策記事の一覧へ