IETF（インターネット技術タスクフォース）が今週、TLS 1.3 ドラフト 28 を提案された標準規格として正式に承認し、この承認によって、TLS 1.3 が TLS（トランスポートレイヤセキュリティ）プロトコルの最新改訂版となりました。TLS ワーキンググループによる改訂から 4 年を経た、今回の承認によって、TLS 1.3 のインターネット標準としての認定までに、少数の実装を残すのみとなりました。

TLS 1.3 には、セキュリティおよび運用の両面の改善を目的とする、TLS 1.2 からのいくつかの大きな変更点があり、以下の点が新たに追加されています。

• 0-RTT（ゼロラウンドトリップタイム再開）
  0-RTT とは、クライアントが暗号化されたアプリケーションデータとセッション再ネゴシエーションメッセージを一緒に送信できるようにすることで、接続の再開を高速化する、新しいネゴシエーションモードです。これは、暗号化されたデータの送信前にクライアントとサーバがすべてのハンドシェイクを完了する必要がある、これまでの TLS ネゴシエーションモードとは異なります。
• すべての静的な RSA および Diffie-Hellman 暗号スイートの削除
  TLS 1.3 では、PFS（Perfect Forward Secrecy）を提供する暗号スイートだけが許可されます。PFS がないと、RSA の秘密鍵やその他の事前共有鍵をサーバから不正取得した攻撃者が、そのサーバとの間で送信されるすべての SSL/TLSトラフィックを解読できてしまいます。PFS があれば、セッションごとに新しい一意の鍵が使用されるため、1 つのセッションが攻撃されても、他のすべてのセッションに影響することはありません。
• 新しいセッションハンドシェイクプロセス
  TLS 1.3 では、セッションハンドシェイクのプロセスが全面的に改訂されて、TLS 1.2 バージョンのネゴシエーションフィールド、ServerHello の後のすべてのメッセージの暗号化、さらには、ChangeCipherSpec などのいくつかのメッセージの完全削除などの多くの点が変更されます。

TLS 1.2 からのこれ以外の主な変更点は、提案された標準の文書の 16 ページに記載されています。

TLS 1.3 での変更点の中でも最も議論が集中している 2 点が、0-RTT と RSA 鍵交換の廃止です。0-RTT によって、多くの場合にレイテンシが大幅に改善されますが、その一方で、セキュリティの低下が懸念されます。端的に言えば、0-RTT メッセージには、リプレイ攻撃と関連性のある脆弱性が存在し、攻撃者が暗号化された接続を捕捉して 0-RTT データをサーバに再送（リプレイ）し、予期しない動作を実行される恐れがあります。幸いにも、最近の Web アプリケーションのほとんどにはリプレイ攻撃に対する耐性があり、ネットワークの一般的な一時停止に対処できるようになっています。とは言え、0-RTT が追加されるということは、TLS 1.3 を実装するすべてのアプリケーションとサービスがリプレイ攻撃の可能性に注意しなければならないことを意味します。

RSA 鍵交換やその他の非 PFS の暗号スイートの削除という変更により、セキュリティやデータ損失防止を SSL/TLS 復号化に依存している多くの企業や団体から、懸念の声が上がっています。金融業界の企業は、この変更によってアウトオブバンドの復号化がほぼ不可能になる点に注目したのです。

個人情報保護の潜在的な問題はともかく、SSL/TLS 復号化は、現代社会でのセキュリティの確保には不可欠です。マルウェアの通信や第 2 段階のペイロードが検知されないようにするため、多くのマルウェアに暗号化が採用されるようになっています。幸運なことに、（ウォッチガードの Firebox アプライアンスなどの）インラインプロキシは、この新しい標準の実装後も、TLS 1.3 トラフィックをまったく問題なく処理できます。インラインプロキシでは、SSL/TLS セッションに対する中間者（MitM）攻撃が実質的に考慮されており、これは、PFC 対応暗号スイートが影響することのないプロセスです。

ウォッチガードは現在、今回承認されたこの標準のサポートが追加されることになる最終リリースの OpenSSL v1.1.1 の公開を視野に入れ、TLS 1.3 のテストを社内で進めています。ウォッチガードのプロキシで TLS 1.3 が正式サポートされるまでの間、TLS 1.3 ネゴシエーションを TLS 1.2 にダウングレードした場合であっても、復号化によるコンテンツ検査は引き続き有効です。– Marc Laliberte