SSL/TLSの復号#3 ～パケットからわかるTLS1.2とTLS1.3の違い～
TLSの復号#2で、SYNESISとWindows PCの間でどのような通信がされているかを復号したパケットで確認しました。その際、TLS1.2とTLS1.3では、だいぶ異なった動きをしていましたので、今回は比較した結果とTLSバージョンの違いについて解説します。
なお、今回も前回同様Wireshark Ver.3.6.8で検証を行います。
TLS1.2で通信するためのブラウザ設定
実験環境はTLSの復号#2と同じです。
ただし、TLS1.2で通信をさせるためには、サーバかクライアントのどちらかの設定変更が必要です。今回はクライアント側（ブラウザの設定）を変更しました。
FirefoxでTLSのバージョンを変更する方法は、以下のとおりです。
- Firefox のアドレスバーに"about:config"と入力し、Enterキーを押します。
- 警告画面が出ますので［危険性を承知の上で使用する］をクリックします。
- ［security.tls.version.min］と［security.tls.version.max]の値を"3"に設定します。
パラメータは、検索ボックスを使用するとすぐに見つけられて便利です。
値の変更はダブルクリックで編集可能です。
値の示すバージョンは、以下の通りです。
| 値 | バージョン |
|---|---|
| 0 | SSL3.0 |
| 1 | TLS1.0 |
| 2 | TLS1.1 |
| 3 | TLS1.2 |
| 4 | TLS1.3 |
最近のFirefoxですと、security.tls.version.minが3（TLS1.2）、security.tls.version.maxが4（TLS1.3）になっています。この設定は、一般的にセキュリティ上推奨とされるバージョンです。
今回は、実験で一時的に変更しますが、恒久的な変更はシステム管理者などと相談の上変更を行うようにしてください。セキュリティレベルが下がる原因となります。（私も実験後は元の設定に戻しました。）
TLS1.2 vs TLS1.3
TLS1.2での結果は以下の通りです。
復号前のTLS通信の状況-TLS1.2
復号後のTLS通信の状況-TLS1.2
一目見ただけでもTLSの復号#2と比較して、HTTP2の通信が始まるまでの過程が多いことがわかります。
もう少しわかりやすくするため表形式にしてみました。
TLS1.3のネゴシエーション
| # | Dirction | Info | Encript |
|---|---|---|---|
| 4 | Client → Server | Client Hello | - |
| 6 | Client ← Server | Server Hello, Change Cipher Spec, (Encrypted Extensions) | Y |
| 7 | Client ← Server | (Certificate), (Certificate Verify), (Finished) | Y |
| 9 | Client → Server | Change Cipher Spec, (Finished) | Y |
TLS1.3の場合は、ネゴシエーションの回数が減り、かつ途中からデータの暗号化が始まっています。（）内が暗号化されているデータです。
TLS1.2のネゴシエーション
| # | Dirction | Info | Encript |
|---|---|---|---|
| 4 | Client → Server | Client Hello | - |
| 6 | Client ← Server | Server Hello, Certificate | - |
| 7 | Client ← Server | Server Key Exchange, Server Hello Done | - |
| 9 | Client → Server | Client Key Exchange, Change Cipher Spec, Finished | - |
| 11 | Client ← Server | New Session Ticket, Change Cipher Spec, Finished | - |
TLS1.2の場合は、ネゴシエーションパケットの暗号化は行われていません。
IETFでの策定までの道のり
パケットを見たところで、次にIETFでの策定までの道のりを確認してみます。RFCの検討段階からの履歴は、IFTF Datatrackerから確認できます。
このサイトは、IFTFの文書やワーキンググループの議事録、プレゼンテーションなどのデータベースとなっています。
RFC8446の発行までの履歴は、The Transport Layer Security (TLS) Protocol Version 1.3 RFC8446を見ます。
2014年から仕様策定が開始され、ドラフトバージョンがdraft28までリリースされ、2018年8月に正式にRFC発行されています。策定までに４年間かかったということですね。
TLS1.3とそれ以前のバージョンの違い
TLS1.3がいかに熟慮されたプロトコルであることは、 IETF-TLS1.3ブログ記事からもわかります。
コンテンツの一部で改善点についての記述がありましたのでを要約して紹介します。
興味があれば、原文で読んでみてはいかがでしょうか。公開したときの熱意が伝わってきます。
TLS1.3の主な改善点
セキュリティ - TLS 1.2で見つかった脆弱性は、TLS 1.3では対処され、脆弱性のないアルゴリズムのみがサポートされています。
パフォーマンス - TLS 1.3はハンドシェイクからのラウンドトリップ全体を削減します。一般的なケースでは、新規の接続は、クライアントとサーバ間の1回の往復で完了します。
プライバシー - ネゴシエーションのハンドシェイクを暗号化して盗聴者から保護することにより、データ交換のプライバシーを強化しています。また、デフォルトで前方秘匿性を有効にしています。
やはり、生のパケットを見ながら仕様を確認することがプロトコル理解への第一歩ですね。
TLS1.3の名称
このようにTLS1.3とこれまでのバージョンでは仕様が大きく異なり互換性もないため、仕様検討段階から、"1.3"というバージョンを変更すべき、との意見がありました。
IETF97では、「TLS1.3」、「TLS2.0」、「TLS2」、「TLS4」の候補からハミングによる採決が行われました。会場では「TLS1.3」支持が多かったようです。その後MLなどのやり取りを経て、正式に「TLS1.3」としてリリースされました。
あとがき
TLSの記事は思ったより書くことが多くなり、3回に分けての解説となりました。その間Wireshark Ver4.0がリリースされましたが、同じバージョンのほうがよいと考えバージョンアップを控えていました。一通り検証は終わりましたので、早速Ver4.0を試してみたいと思います。
TLS1.3の名称は、IETF97でハミング採決が行われました。そういえば今まさにロンドンでは、IETF115が開催中です。今回はどんなことが採決されるのでしょうか。
そしてIETF116は横浜開催ですね。今から楽しみです。
