連載第二回、TLS1.3の性能面での改善項目、0-RTT (Early Data) を紹介しようと思う。(0-RTT: Zero Round Trip Time)
これまでのTLS/SSLの性能上の大きな悩みは、冒頭のハンドシェイクによる遅延だ。これまではハンドシェイクは、安全な暗号通信をするためのやむをえないオーバヘッドと思われていた。それが、使用条件はあるものの、通信の冒頭で暗号化されたメッセージを送れる方法が正式に認められたのだから、かなり画期的なことだと思う。特に、少しでも早くデータをサーバに届けたいIoTデバイスにとっては朗報のはずだ。
しかし実は、これを1.3の冒頭に紹介するかどうかについては少々悩ましい。というのは、Early Dataによる暗号化メッセージはセキュリティ的には安全性がやや落ちるからだ。もう少し厳密な言い方をするなら、Early Data では完全前方秘匿性(PFS)が保証されなくなる。それと、サーバにとってはリプレイ攻撃のリスクも伴う。
PFSというのは将来にわたって過去の通信内容の秘匿性が失われないようにする。これまでは通信時の秘匿性だけを考えていたのに対して、メッセージが大規模、長期に蓄積分析されるリスクに対応できるための新しいディメンジョンの秘匿性だ。TLS1.3の検討過程で実現の必要性が熱心に議論され、認識されたいわばTLS1.3の安全性側の目玉の一つだ。そのPFSについて、「だたし、Early Dataでは保証しない」というのだから、いくら性能側から魅力的とはいっても一番はじめにもってくるのは少々はばかられるのだけれど、やっぱりEarly Dataから行こう！
TLS1.3では、1.2までのセッションIDやセッションチケットが整理され、「セッション再開と事前共有鍵」として統合された方法が定義された。セッション再開にしろ事前共有鍵にしろ、セッションを再確立しようとする際は、安全な鍵がきちんと準備された状態になっていることが保証されている。ただし、TLS1.3ではそれをそのまま使用するのでなく、もう１ラウンド(EC)DHEによって鍵合意を行って完全前方秘匿性を確保した鍵によってアプリケーションデータの送受信をするという選択ができるようになっている。Early Dataではそのフェーズより前にアプリケーションデータを送ることになるので、そういう選択肢はなくなってしまう。
Early Dataのニーズは、もともとはWebサーバのようなアプリケーションから出てきた。Webサーバへのアクセスの多くは再接続だから、これを高速化できる処理はサーバ負荷の観点からもブラウザ側からも嬉しい話だ。しかしIoTのデバイスサイドのようなものから見ても、小さなデータを周期的、あるいはイベント発生時にできるだけ速やかにサーバに送りたいというニーズは多い。そいう場合、それを以前に確立したセッションに対するセッション再開として処理できるケースが多いはずだ。一方、そういうデータの多くはPFSまでの秘匿性は必要としないかもしれない。そういう場合、Early Dataを使えばTCPと同じくらいのレベルの短い遅延でデータを送れるようになったのだ。
Early Dataだけでなく、TLS1.3を詳しくみていくと、あちこちで安全性と性能のトレードオフをアプリケーションの要件などから選択できるようになっているのに気がつく。ネットの上のアプリケーション・ドメインの広がり、それに伴うセキュリティ要件、性能要件の多様化に対応しようとするTLS1.3の姿勢の表れなのだろう。TLS1.3を単に1.2までのたくさんの問題点が再整理された安全性の改善されたプロトコルバージョンとみて、最小のインパクトで1.3に移行することも可能ではある。その一方で、こうした新しい仕組みを積極的に利用して、自社製品の強みとして生かしていくこともできるようになっているところが1.3の優れた検討成果だと思う。
走り出した TLS 1.3 第一回はこちらです。
TLS1.3について詳しい情報は弊社問い合わせ窓口info@wolfssl.jp までお問い合わせください。
wolfSSLホーム：www.wolfssl.jp (English：www.wolfssl.com)