走り出した TLS 1.3(5、最終回):TLS 1.3をフルサポートするwolfSSL

さて、連載最後はwolfSSLのサポートするTLS1.3について紹介して締めくくることにしよう。

今まで紹介してきたようにTLS1.3では、プロトコルの内部的には大幅な改定、改善強化となっている。しかし、wolfSSL ライブラリの使用方法という面からは、今までに対して最小の変更で新しいバージョンのプロトコル機能を追加することができるように配慮されている。例えばビルド方法では、

$ ./configure –-enable-tls13

のようにTLS1.3機能追加のためのビルドオプションを一つ指定するだけでアプリケーションから使用することができる。今までと同じように make コマンドを実行すると、一連のコンパイル、リンクによってwolfSSLライブラリと基本的なサンプルプログラムが出来上がる。

ビルドをした同じパソコン上で、二つウィンドウを開いて、簡単にローカルなTLSサーバー、クライアント間通信を試してみよう。TLS1.2との違いがわかるようにWiresharkなどのパケットキャプチャツールでその内容を見ることができる。プロトコルバージョンオプションに “-v 4” とTLS1.3を指定して、

サーバ側ウインドウ:$ ./examples/server/server -v 4

クライアント側ウインドウ:$ ./examples/client/client -v 4

と実行すると、

SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is SECP256R1
I hear you fa shizzle!

のように、TLS1.3のハンドシェイク情報と簡単なサーバクライアント間のアプリケーションメッセージが表示される。Wireshark ならこんな風にローカルホスト同士のハンドシェイクとメッセージのやりとりが表示される。ハンドシェイクでは、最初のClientHello と ServerHello 以降はすべて暗号化されていることがわかるはずだ。ClientHelloのレコード詳細を見てみれば、Cipher Suiteリスト中のTLS1.3独自の暗号スイートやSupportedVersion TLS拡張の内容を見ることもできる。

 

TLS1.3のパケットキャプチャ

 

比較のために、サーバー、クライアントをオプションなしで実行させてみると、このようにデフォルトのTLS1.2でのパケットがキャプチャできる。ハンドシェイクは暗号化されていないので、レコードの種別がきちんと表示されるはずだ。

 

TLS1.2のパケットキャプチャ

 

では、次にアプリケーションから使用する際のAPIについて見てみよう。wolfSSLを使用した典型的なクライアントアプリケーションのコードは概ね次のようになっているはずだ。単純にそれをTLS1.3とするだけであれば、異なるのは最初のプロトコルバージョン指定の部分だけで、その他はまったく変更なく先ほどのような結果を得ることができる。

method = wolfTLSv1_3_client_method(); /* プロトコルバージョン指定 */
ctx = wolfSSL_CTX_new(method); /* コンテクストディスクリプタ確保 */
ssl = wolfSSL_new(ctx); /* セッションディスクリプタ確保 */

/* TCP層の接続処理 */

wolfSSL_connect(ssl); /* TLSセッション確立 */

wolfSSL_write(ssl, buff, size); /* メッセージ送信 */
wolfSSL_read(ssl, buff, size); /* メッセージ受信 */

wolfSSL_free(ssl); /* TLSセッション解放 */
wolfSSL_CTX_free(ctx); /* コンテクスト解放 */

もちろん、TLS1.3で新たに加わった新機能をもっと積極的に利用することも可能だ。この連載の最初でも紹介したような、Early Data (0-RTT)や鍵の明示的更新、また、ハンドシェイク後の認証、セッション再開時DHEなしやセッションチケットを送らないためのオプション指定など各種の新機能に対応したAPIが追加されている。

wolfSSLのTLS1.3機能は昨年夏のIETFによるRFC8446の正式サブミッションとほぼ同時に正式サポートを開始している。無償のGPLv2版はこちらからダウンロードできるので、ぜひ実機で評価してみて欲しい。また、商用版でのTLS1.3についてはinfo@wolfssl.jpまでお知らせください。

連載のご購読ありがとうございました。

wolfSSL Japan 技術サポートチーム

 連載「走り出したTLS 1.3」
 第一回
 第二回 0-RTTでいきなり暗号化メッセージ
 第三回 一律3割引き !?
 第四回 セキュリティプロトコルの技術と経験を結集
 第五回 TLS 1.3をフルサポートするwolfSSL (最終回、本ページ)

走り出した TLS 1.3(4):セキュリティプロトコルの技術と経験を結集

さてここまでTLS1.3の特徴として、性能やスループットの面からのメリットを中心にお話するというセキュリティ屋の説明らしからぬ順序で進めてきた。そろそろ安全性の面からの話もまとめておこう。

実際のところTLS1.2までの経験で、TLSはセキュリティプロトコルとしてはかなり成熟してきていたといってもいいだろう。しかし、最大の課題は、それまで出てきた数々の問題に対応するためにつぎはぎ的な対応が重なってきてしまっていたことだろう。それまでのTLS拡張によるTLSレコードのつぎはぎだらけの拡張では早晩破綻をきたしてしまうことは目に見えていた。たくさんの暗号スイートの中には、すでに危殆化したものや、危殆化が見えているものも増えてきていた。ブロック暗号とMACによる真正性の保証も限界のように思われた。

そういう中で、TLS1.3では、まず暗号スイートの大胆な整理が行われた。最終的には共通鍵暗号の方式としては認証タグ付き暗号(いわゆるAEAD)のみを採用することになった。具体的には、現時点でみとめられているのはブロック暗号としてAES-GCMとAES-CCM、ストリーム暗号ではChaCha-Polyのみだ。TLS1.2でもっとも広く使われているAES-CBCは廃止された。

TLS1.3の安全性の議論で、それまでのバージョンでは配慮されていなかった完全前方秘匿性への配慮が新たに加わった。これは、それまでには考えられなかったような大規模で長期間にわたるネットワークトラフィックの盗聴、蓄積が行われるケースがあることがわかってきたためだ。そういう攻撃方法によれば、長い期間をかけた暗号解読や、本来十分管理されるべきプライベート鍵の流出などで過去の秘匿情報が解読されてしまうリスクがある。公開鍵方式といえども鍵交換において長期間にわたり同じ鍵を使用することは危険であることがわかってきて、そうしたリスクに対する秘匿性、「完全前方秘匿性(PFS)」の重要性が認識されはじめた。

具体的対策としては、鍵交換における静的RSAを廃止し、ディフィー・ヘルマン(DH) においても一時鍵(Ephemeral Key) のみを使用するDHEのみが認められることになった。逆に、DHEのみになったおかげでハンドシェイクは単純化され、シリーズ前回でも紹介したように、オーバーヘッドが削減されたというメリットも享受できるという副産物もある。

以下は、TLS1.2と1.3における暗号スイートの例だ。1.3の鍵交換ではDH系しか使用されないので、そのフィールドは廃止された。ECDH(楕円曲線暗号によるDH)での曲線種別はTLS拡張で示される。

TLS1.2の暗号スイートの例:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS1.3の暗号スイートの例:TLS_AES_128_GCM_SHA256

また、鍵合意部分がDH系のみに整理されたことにともない、ハンドシェイク先頭の暗号スイートの合意部分を除いてその後のハンドシェイクはすべて暗号化でき、安全性が大幅に向上した。

図:TLS1.3ではハンドシェイクの大部分が暗号化

そのほかにも、TLS拡張の整理や、暗号スイートの意味の整理がされたことなど、ひとまずのTLSの完成形といえるものに仕上がったといえるだろう。

 連載「走り出したTLS 1.3」
 第一回
 第二回 0-RTTでいきなり暗号化メッセージ
 第三回 一律3割引き !?

さらに詳しい情報は info@wolfssl.jp までお問い合わせください。

wolfSSLホーム:www.wolfssl.jp (English:www.wolfssl.com)

走り出した TLS 1.3(3):一律3割引き !?

と言っても価格の話ではありあせん、すみません!連載第三回はTLS1.3 で大幅に改善されたフルハンドシェイクについて紹介しようと思う。サーバー、クライアントが初めてのTLS通信をしようとするときは、通信に使う暗号スイートの合意、お互いの信頼の確認、メッセージ暗号化に実際に使う鍵を合意するなど、安全なメッセージ通信のためにさまざまな情報を交換しあう。それがフルハンドシェイクだ。そのフルハンドシェイクにTLS1.2までは最低でもTCP通信にして2往復の通信が必要だった。それがTLS1.3では1往復ですむようになった。

フルハンドシェイク往復回数の改善

しかし、これで通信時間が半分になるかというと、残念ながら通常のネットワークの状況ではそこまでは速くならない。ネットワーク遅延の状況にもよるが、当社のシミュレーションでは典型的な通信状況で概ね30%程度の改善がみられた。

ネットワーク遅延とハンドシェイク時間

 

TLS1.3に移行するすべてのTLS通信で冒頭一律30%、セッション時間が30%削減されるとしたら、これは大きな恩恵だ。特にサーバー運用コストには直接跳ね返ってくる。いま、ブラウザのTLS1.3対応が進んでいる中、サーバー側の対応が進むのは時間の問題だろう。それにIoTデバイス系もひっぱられる構図がみえてくる。

では、TLS1.3でなぜフルハンドシェイクがそのように大幅に削減が可能になったのか?それはいくつか要因があるが一番大きいのは、鍵交換の方式がDH(ディフィーヘルマン)系に統一されたことだろう。TLS1.3の議論の中で、前方秘匿性の問題が大きくとりあげられ、静的RSAによる鍵交換のリスクが認識され、今までDHとRSAの二つの方式が選択できたものが( ECを含む)DH、それも一時鍵(Ephemeral)方式だけに統一された。そのためハンドシェイクの冒頭から、DH系を想定した鍵合意のためのプロセスを開始できるようになった。

もう一つは、これまでハンドシェイクの最後のフェーズとしてスイートの切り替えフェーズがあったのだが、これをスキップしていきなりFinishedとしても安全上問題ないということになったことがある。

こうした整理のおかげで、TLS1.3のフルハンドシェイクは大幅に整理改善され、利用者は一律にその恩恵を受けることができるようになったのだ。

 連載「走り出したTLS 1.3」
 第一回
 第二回 0-RTTでいきなり暗号化メッセージ

TLS1.3について詳しい情報は弊社問い合わせ窓口info@wolfssl.jp までお問い合わせください。
wolfSSLホーム:www.wolfssl.jp (English:www.wolfssl.com)

走り出した TLS 1.3(2):0-RTTでいきなり暗号化メッセージ

連載第二回、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ではそれをそのまま使用するのでなく、もう1ラウンド(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)

走り出した TLS 1.3

標準策定フェーズから実用、普及にむけてTLS1.3が本格的に動き出した。サーバ側の対応は先頭を走る主要サイトの準備は着々すすみ、FireFox、Chromeとメジャーなブラウザのサポート開始とともに、ネット上の現実のトラフィックのTLS1.3サポート比率が立ち上がり始めているようだ。詳細に見れば、まだまだ全体からすると一部のトラフィック、それもほとんどはDraft23 (最終版は28) というようなこともあるが、予想通りTLS1.3の立ち上がりは非常に早いようだ。TLS1.2やそれ以前のバージョンのときの新バージョン移行では数年以上を要した。TLS1.3は、これまでのTLSのバージョンアップと異なり、安全性の面だけでなく広い意味での性能に対する改善が随所に対策されていることが大きい。オーバーヘッドの軽減は、コスト負担に悩むサーバ側各社にとって何よりのモチベーションになる。ブラウザユーザにとっても、より快適なブラウズ環境を意味するのだから、新バージョンへの移行スピードが従来より大幅に早いのは当然ともいえる。

では、この新バージョンプロトコルがIoTエッジデバイス側の我々にどのような意味をもってくるのか。新バージョンの特徴を自社製品の競争力の源泉にできないのか?この連載では、そうしたあれこれをTLS1.3の違いから順次解き明かして行こうと思う。

今年に入って急速に立ち上がるTLS1.3対応のトラフィック比率
(wolfssl.jpサイトへのアクセス比率)

 

wolfSSL TLS 1.3正式対応版のダウンロードはこちらから。

 

連載の内容については概ねこちらのセミナーでもお話をさせていただくことになっているので、掲載を待てない、というかたはぜひご参加ください。

wolfSSLセミナー2018秋開催 品川、10月4日(木) 13:30-17:00
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
昨年に続きwolfSSLエンジニアリングマネジャのChris Conlonが来日し、最新TLS 1.3の優位点、TPM2.0ライブラリ、wolfSSH、OpenSSL互換レイヤーなどご紹介します(英語、日本語概訳)。
https://www.wolfssl.jp/wolfblog/2018/09/10/wolfsslseminar/

 

マクニカ社主催セミナーでの講演 新横浜、10月17日(水) 13:30-16:30
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
「AWSクラウドに繋がるエッジ端末 IoT設計支援とセキュリティ対策セミナー」で講演させていただきます。wolfSSLセッション:「 IoTデバイスのセキュリティ、そろそろ真剣に考えませんか?」(日本語)
http://bit.ly/2xOPnHk