はじめに
ITの勉強において、やっぱり全範囲を網羅的に勉強しようと思ってもなかなか、先輩・上司に追いつき追い抜くことって時間がかかるものです。そのせいでモチベーション下がったり……
だったら、１つのことに１点集中して『これに関しては同レベルor自分の方が上だ！』と思える領域を少しずつ作っていきましょう！それを続けていけば、どんどんどんどん勝てる領域が多くなり、気づいたら自分が行きたい未来に辿りつきます！
じゃあ今日は、「TLS1.3」について教えてください。みんなはこれを説明できる？？なので、今日はこれを教えてください！
了解じゃ！一言で言うと
『TLS1.3インターネット通信をより安全かつ効率的にするために改良されたプロトコル』じゃ！では、ネスペ合格レベルを目指す方は以下で詳しく見ていくぞ！
基本知識
TLS 1.3は、TLS 1.2の脆弱性を克服し、より強固なセキュリティと効率的な接続を提供するために設計されました。TLS 1.2以前のバージョンでは、いくつかの問題（脆弱な暗号スイート、前方秘匿性の欠如、接続遅延など）が指摘されており、TLS 1.3ではそれらが解消されています。
そもそも、TLSって何だったっけ…?
TLS(Transport Layer Security)っていうのは、暗号化・認証・整合性の機能によりインターネット上の通信を安全にしてくれるプロトコルじゃ！
で、1.2と1.3があって、今学んでいる1.3が改良版というわけじゃ！
TLS 1.3の主な特徴
じゃあ、1.2と1.3で具体的に何が変わったのかを教えてください！
了解じゃ！以下に、TLS 1.3の重要な特徴と、それらがTLS 1.2とどう違うかを具体的に説明していくぞ！
1. ハンドシェイクの効率化
TLSハンドシェイクは、クライアントとサーバーが安全に通信を開始するために行う最初のプロセスです。TLS 1.2では、このハンドシェイクに2往復（4つのメッセージ）が必要でしたが、TLS 1.3では1往復（2つのメッセージ）に短縮されました。
- TLS 1.2の場合
- ClientHello：クライアントがTLSのバージョン、サポートする暗号スイート（対応可能な暗号化アルゴリズムのリスト）、乱数値（ランダムなデータ）などをサーバーに送ります。
- ServerHello：サーバーがTLSバージョン、選択した暗号スイート、サーバー証明書、乱数値、そしてオプションでDH（Diffie-Hellman）などの公開鍵情報をクライアントに送ります。
- ClientKeyExchange：クライアントが、プリマスターシークレット（鍵素材）をサーバーに送ります。これにより、サーバーとクライアントは対称鍵を生成します。
- ChangeCipherSpec & Finished：クライアントとサーバーが対称鍵を確立し、暗号化通信を開始します。この際、最終的な「ハンドシェイクが完了した」という確認メッセージを送信し合います。
- TLS 1.3の場合:
- ClientHello：クライアントがTLS 1.3のバージョン、サポートする暗号スイート、乱数値に加えて、DH鍵交換の情報も最初のメッセージに含めて送ります。これにより、クライアントが最初のメッセージで鍵交換の準備を済ませます。
- ServerHello & Finished：サーバーがClientHelloを受け取った後、選択した暗号スイート、サーバー証明書、サーバー側のDH鍵交換情報を送り返し、すぐに暗号化された通信を開始できる状態にします。
- Finished（クライアントからサーバーへ）
- クライアントは最終的な確認として、暗号化された状態で「通信準備完了」のメッセージをサーバーに送り、通信が暗号化されます。
2. 前方秘匿性の確保
前方秘匿性（PFS: Perfect Forward SecrecyまたはPS）とは、過去のセッションの秘密鍵が漏洩しても、それによって過去の通信内容が解読されないというセキュリティ特性のことです。
- TLS 1.2の場合：RSA鍵交換が可能でしたが、RSAは前方秘匿性を提供しませんでした。攻撃者がRSA秘密鍵を取得すれば、過去の通信が全て解読されるリスクがありました。
- TLS 1.3の場合：RSAによる鍵交換は廃止され、すべての通信で前方秘匿性の持ったDH（Diffie-Hellman）やECDHE（楕円曲線：Ephemeral Diffie-Hellman）が使用されるようになっています。これにより、すべてのセッションで前方秘匿性が確保されます。
まぁ要するに、前方秘匿性を確保したいなら、DH,ECDHEをつかうよって覚えておけばいいんですね！
その解釈でOKじゃ！
3. 暗号スイートの簡略化と強化
- TLS 1.2の場合：暗号スイート（暗号アルゴリズム、ハッシュ関数、鍵交換方式）を個別に選択できましたが、設定が複雑で、古い暗号化アルゴリズム（例: RC4、SHA-1）が依然として使われていました。これらの古いアルゴリズムには脆弱性がありました。
- TLS 1.3の場合：これらの脆弱なアルゴリズムは廃止され、暗号スイートは強力なAEAD方式に統一されています。代表的な暗号アルゴリズムはAES-GCMやChaCha20-Poly1305で、いずれも強力で効率的です。
AEAD（Authenticated Encryption with Associated Data）とは暗号化とデータの認証を同時に行う暗号方式のことです。代表的なAEADとしてはAES-GCMやChaCha20-Poly1305などがあります。
4. 暗号化のタイミング
- TLS 1.2の場合: ハンドシェイクがすべて完了してから、データの暗号化が始まります。したがって、ハンドシェイク中のメッセージは暗号化されていません。
- TLS 1.3の場合: 鍵交換が完了した時点（つまり、ServerHello後）で暗号化が開始されます。これにより、ハンドシェイク中のメッセージも暗号化され、セキュリティがさらに強化されています。
5. 0-RTT（Zero Round Trip Time Resumption）
0-RTTとは、TLS1.3の新機能（1.2にはない）で過去に接続したことがあるクライアントが、以前のセッションの情報を使って、再接続時に0ラウンドトリップで通信を開始できるという仕組みです。これにより、接続が非常に高速になります。
ただし、0-RTTにはリスクもあり、過去の通信内容を攻撃者がリプレイ（再送信）して不正な操作を試みることができるリプレイ攻撃の脅威があるため、慎重に利用する必要があります。
6. 従来のTLSとの互換性
TLS 1.3は、TLS 1.2以前のバージョンとは後方互換性がありますが、一部の古い暗号アルゴリズムやプロトコル（例: RSA鍵交換、固定Diffie-Hellman）は廃止されているため、TLS 1.3のみをサポートするシステムでは、それらを利用することはできません。
TLS 1.2とTLS 1.3の比較まとめ
あのー、長々と説明され過ぎて、最初のやつとか忘れちゃいましたよー。
そうじゃな。では、ここでまとめておこうかのぉ
| 項目 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| ハンドシェイクのラウンドトリップ | 2往復 | 1往復 |
| サポートする鍵交換方式 | RSA, DH, ECDH, ECDHE | ECDHE, DHEのみ（RSA廃止） |
| 前方秘匿性（PFS） | RSA鍵交換ではPFSなし | すべての鍵交換方式でPFSを実現 |
| 暗号スイート | 複雑な構造でRC4やSHA-1などもサポート | AES-GCM, ChaCha20-Poly1305（強力で簡略化） |
| 暗号化の開始タイミング | ハンドシェイク終了後に暗号化開始 | ServerHello後すぐに暗号化開始 |
| 0-RTT再接続 | なし | サポートあり（0往復） |
| 脆弱なアルゴリズム | RC4、SHA-1などサポート | 廃止 |
| 後方互換性 | – | 1.2との互換性は完全ではない |
まぁ要するに、重要な点としては
- ハンドシェイクのラウンドトリップが1回に減少し、接続がより高速に。
- 前方秘匿性（PFS）が標準化され、過去の通信が安全に保たれる。
- 強力な暗号アルゴリズム（AES-GCM, ChaCha20-Poly1305）への移行と、古い脆弱なアルゴリズムの廃止。
- 0-RTT再接続により、再接続が高速化。ただしリプレイ攻撃のリスクがあるため注意が必要。
- 鍵交換後すぐに暗号化が開始され、ハンドシェイク自体も暗号化される。
って感じですかね。
合格じゃ！
まとめ
要するに…
TLS 1.3は、インターネット上での通信を安全にするためのプロトコルTLS（Transport Layer Security）の改良版であり、以前のバージョンであるTLS 1.2と比べていくつかの重要な改善が行われています。TLSは、インターネット上の通信を暗号化し、データの整合性を保証し、相手の認証を行う役割を担っており、Web通信（HTTPS）をはじめ、VPN、メール、FTPなど、さまざまなプロトコルに組み込まれています。
TLS 1.3の最大の特徴の一つは、ハンドシェイクプロセスが簡素化された点です。TLS 1.2では、通信を確立するために2往復のメッセージ交換が必要でしたが、TLS 1.3ではこれが1ラウンドトリップ（1-RTT）で完了するようになりました。この簡略化は、クライアントが最初に送る「ClientHello」メッセージに、暗号スイートの提案や乱数値だけでなく、Diffie-Hellman（DH）鍵交換の情報も含めて送信することで実現されました。これにより、サーバーが「ServerHello」を返した時点で、鍵交換に必要な情報がすでに揃っており、すぐに暗号化が開始できるようになります。
暗号化のタイミングもTLS 1.2とTLS 1.3で異なります。TLS 1.2では、ハンドシェイクが完全に終了し、すべての認証や鍵交換が完了してから通信が暗号化されました。しかし、TLS 1.3では、サーバーが「ServerHello」を送信した直後から暗号化が始まります。この段階で、すでにサーバーとクライアントの間で共通の鍵が生成されているため、サーバーが続けて送るメッセージ、たとえばサーバー証明書なども暗号化されます。これにより、セキュリティの強化が図られています。
前方秘匿性もTLS 1.3の重要な改善点です。TLS 1.2では、RSAを使った鍵交換が主流でしたが、RSAは前方秘匿性を提供しません。前方秘匿性とは、将来的にサーバーの秘密鍵が漏洩しても、過去の通信内容が解読されないというセキュリティ特性です。TLS 1.3では、Diffie-HellmanやElliptic-Curve Diffie-Hellman（ECDHE）といった鍵交換方式を使用することで、この前方秘匿性を確保しています。これにより、通信の安全性が大幅に向上しています。
また、TLS 1.3では、使用される暗号スイートにも改善が見られます。TLS 1.2では多くの暗号アルゴリズムが選択肢として残っており、中にはすでに脆弱性が指摘されているものもありました。例えば、RC4やSHA-1のような古いアルゴリズムです。しかし、TLS 1.3ではこれらの弱点が排除され、AES-GCMやChaCha20-Poly1305といった、より強力でセキュアなAEAD（Authenticated Encryption with Associated Data）方式に統一されています。AEAD方式は、データの暗号化と整合性確認（認証）を同時に行う技術であり、データが改ざんされていないことを保証しつつ、秘匿性も提供します。
さらに、TLS 1.3の新機能として「0-RTT」という仕組みがあります。これは、以前に確立したセッション情報を再利用することで、再接続時にラウンドトリップタイム（RTT）をゼロにする、つまり即座にデータを送信できる機能です。通常、初回接続には鍵交換のために複数回のメッセージ往復が必要ですが、0-RTTを利用することでこれを省略し、再接続時の待ち時間を大幅に削減できます。ただし、0-RTTにはリスクもあり、リプレイ攻撃の危険性があります。リプレイ攻撃とは、攻撃者が過去の通信内容を再送することで、意図しない操作を繰り返させる手法です。TLS 1.3では、0-RTTを使用する場合にそのリスクを軽減するための対策も導入されていますが、完全に排除することは難しいため、慎重に使用する必要があります。
このように、TLS 1.3はTLS 1.2に比べてセキュリティが大幅に強化され、通信の効率性も向上しています。ハンドシェイクが簡素化され、前方秘匿性が確保され、より安全な暗号アルゴリズムが標準化されたことで、TLS 1.3はインターネット上のさまざまな通信プロトコルにおいて、よりセキュアな通信を提供するプロトコルとして広く採用されています。
おわりに
本日は『TLS1.3』について知見を深まりました！
やはり、知識をつけることは大切じゃからのぉ。知識があれば大抵のことはできる。逆に知識がなければ、できるもんもできない。これが世の理じゃよ。
でも、焦らず、１つずつ・１っ歩ずつ進んでいくことが大切じゃ！これからも一緒に頑張っていこう！
今日のSeeYouソングは「High Hopes – Panic! At the Disco」です。挑戦する人間の背中を押してくれる曲です。では、どうぞ！
