TLSとは、ひと言でいうと何か?
一言でいうと、TLS(Transport Layer Security)は、アプリケーションの通信を「相手を確かめ、中身を隠し、書き換えを見つけられる」状態にするためのプロトコルです。前身の SSL の名前が残り、「SSL/TLS」とまとめて呼ばれることもあります。
HTTPS は、Web の通信(HTTP)を TLS で保護したものです。ブラウザのアドレス欄が https で始まるとき、ブラウザとサーバの間では TLS による接続が確立しています。メールの送受信やアプリの API 通信など、Web 以外でも広く使われています。
| 守るもの | 使う仕組み | 防ぎたいこと |
|---|---|---|
| 相手の認証 | サーバ証明書と、秘密鍵による署名 | 偽のサーバへの接続(なりすまし) |
| 機密性 | ハンドシェイクで共有した鍵による共通鍵暗号 | 通信の盗聴 |
| 完全性 | 認証付き暗号(AEAD)による検証 | 通信途中での書き換え |
暗号方式の組み合わせ(公開鍵暗号で鍵を共有し、本文は共通鍵暗号で守る)は共通鍵暗号と公開鍵暗号の違い、証明書の検証は電子証明書とPKIとはで詳しく扱っています。
TLS 1.3のハンドシェイクは、どんな流れか?
ハンドシェイクは、暗号化通信を始める前に、使う方式を決めて鍵を共有し、サーバを確かめる手続きです。TLS 1.3 の通常の接続は、次のように1往復(1-RTT)で終わります。図と手順で、メッセージの向きと役割を整理します。

- 1
ClientHello
クライアント → サーバ。対応する暗号方式の一覧と key_share
- 2
ServerHello
サーバ → クライアント。選んだ方式とサーバ側の鍵共有の値。以降は暗号化
- 3
証明書と署名
EncryptedExtensions・Certificate・CertificateVerify・Finished(暗号化)
- 4
Finished
クライアントが証明書と署名を検証してから送る(暗号化)
- 5
アプリケーションのデータ
HTTP のリクエストなどを暗号化して送受信
1往復で鍵を共有し、ServerHello より後のハンドシェイクは暗号化される。
- クライアント → サーバ:ClientHello。対応する暗号方式の一覧と、鍵共有のための値(key_share)を送る。
- サーバ → クライアント:ServerHello。選んだ方式と、サーバ側の鍵共有の値を返す。この時点で両者は同じ鍵を計算でき、以降のハンドシェイクは暗号化される。
- サーバ → クライアント(暗号化):EncryptedExtensions(追加の設定)、Certificate(サーバ証明書)、CertificateVerify(秘密鍵を持っていることを示す署名)、Finished(ここまでのやり取りの確認)。
- クライアント → サーバ(暗号化):証明書と署名を検証してから Finished を送る。
- 以降、アプリケーションのデータ(HTTP のリクエストなど)を暗号化して送受信する。
前回つないだサーバに再接続するときは、以前に共有した値を使って最初のメッセージと一緒にデータを送る 0-RTT という方式もあります。速い反面、RFC 8446 は 0-RTT のデータには再送(リプレイ)への保護がないと注意しており、繰り返されても困らない要求に限って使う必要があります。
HTTP/3 で使う QUIC も、TLS 1.3 のハンドシェイクを取り込んで暗号化しています(RFC 9001)。違いはHTTP/2とHTTP/3(QUIC)の違いで整理しています。
クライアント
サーバー
1. クライアント → サーバー
ClientHello
対応方式と鍵共有の値を送る
2. サーバー → クライアント
ServerHello
選んだ方式と鍵共有の値を返す
3. サーバー → クライアント
証明書・署名・Finished
暗号化されたメッセージで相手とやり取りを確認する
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 | TLS 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択と解説を確認できます。