９月６日より開催中の builderscon 2018 において、登壇の機会をいただき、インターネットのトランスポート層プロトコルについてセキュリティやプライバシーに関わる設計がどのように進めてられているか、TLS と QUIC を中心に発表しました。
QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。
聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。
PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記事もあわせてご覧いただけます。
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
TLS の SNI 暗号化に関する Internet Draft を共同提出しました
Saturday, September 8, 2018
Tuesday, July 3, 2018
TLS の SNI 暗号化に関する Internet Draft を共同提出しました
Eric Rescorla (RTFM), Nick Sullivan (Cloudflare), Christopher Wood (Apple) の各氏とともに、SNI を暗号化する TLS 拡張を提案する Internet Draft を提出しました。
アナウンスのメールにあるとおり、すでに NSS / Firefox と picotls / H2O で実装作業が開始されており、今月開催される IETF 102 で相互運用試験を行うとともに、標準化にむけた議論を深める予定です。
スノーデン事件以降、広範囲におよぶトラフィックモニタリングによるプライバシー侵害の懸念が明らかになるとともに、できるだけ多くのインターネット上の通信プロトコルを暗号化することが求められるようになってきました (参考: RFC 7258 - Pervasive Monitoring Is an Attack)。
その結果として、ウェブサイトの HTTPS 化が進み、DNS over TLS (RFC 7858)と DNS over HTTPS の標準化により DNS プロトコルの暗号化にも目処が立ち、残る課題は、クライアントがサーバと TLS ハンドシェイクを開始する際に平文で流れるサーバ名注1をどう暗号化するか、という点となっていました。
今回、共同提案した方式は、私が昨年提案した方式を簡略化したもので、ひとことでいうと「木を森の中に隠す」アプローチです。
具体的には、CDN のように、多数のサーバ名を同一の IP アドレスから配信しているという前提注2において、その IP アドレスに属する全てのサーバ名について、同一の ECDH 鍵を DNS を用いて配信し、クライアントはその鍵を利用して TLS ハンドシェイク内のサーバ名を暗号化する、という形になります。
クライアントはサーバのアドレス解決と同時に ECDH 鍵も DNS に問い合わせすることになりますが、HTTP/2 を前提とする DNS over HTTPS では複数の DNS 問い合わせを並列に実行可能なので、接続確立までのレイテンシは従来と変わらないと考えられています。
Firefox が DNS over HTTPS に対応するのに続き、Android が DNS over TLS をサポートするという流れにある今、あとは SNI 暗号化が実装されれば、通信内容を第三者に傍受されたとしても、どのサーバと通信しているのかが漏洩する可能性はとても小さくなります注2。
インターネットを利用する人々のプライバシー保護の観点からは前進である一方、海賊版サイトのブロッキングにおいて、ISP レベルでの対応が難しくなることは事実ですが、こちらについては、立法や司法の判断に基づいて配信を停止するという、ユーザのプライバシーを侵害しない形式での手法を検討していただきたいと考える次第です。
アナウンスのメールにあるとおり、すでに NSS / Firefox と picotls / H2O で実装作業が開始されており、今月開催される IETF 102 で相互運用試験を行うとともに、標準化にむけた議論を深める予定です。
スノーデン事件以降、広範囲におよぶトラフィックモニタリングによるプライバシー侵害の懸念が明らかになるとともに、できるだけ多くのインターネット上の通信プロトコルを暗号化することが求められるようになってきました (参考: RFC 7258 - Pervasive Monitoring Is an Attack)。
その結果として、ウェブサイトの HTTPS 化が進み、DNS over TLS (RFC 7858)と DNS over HTTPS の標準化により DNS プロトコルの暗号化にも目処が立ち、残る課題は、クライアントがサーバと TLS ハンドシェイクを開始する際に平文で流れるサーバ名注1をどう暗号化するか、という点となっていました。
今回、共同提案した方式は、私が昨年提案した方式を簡略化したもので、ひとことでいうと「木を森の中に隠す」アプローチです。
具体的には、CDN のように、多数のサーバ名を同一の IP アドレスから配信しているという前提注2において、その IP アドレスに属する全てのサーバ名について、同一の ECDH 鍵を DNS を用いて配信し、クライアントはその鍵を利用して TLS ハンドシェイク内のサーバ名を暗号化する、という形になります。
クライアントはサーバのアドレス解決と同時に ECDH 鍵も DNS に問い合わせすることになりますが、HTTP/2 を前提とする DNS over HTTPS では複数の DNS 問い合わせを並列に実行可能なので、接続確立までのレイテンシは従来と変わらないと考えられています。
Firefox が DNS over HTTPS に対応するのに続き、Android が DNS over TLS をサポートするという流れにある今、あとは SNI 暗号化が実装されれば、通信内容を第三者に傍受されたとしても、どのサーバと通信しているのかが漏洩する可能性はとても小さくなります注2。
インターネットを利用する人々のプライバシー保護の観点からは前進である一方、海賊版サイトのブロッキングにおいて、ISP レベルでの対応が難しくなることは事実ですが、こちらについては、立法や司法の判断に基づいて配信を停止するという、ユーザのプライバシーを侵害しない形式での手法を検討していただきたいと考える次第です。
注1: TLS では、ひとつの IP アドレスで動作するサーバが、クライアントが指定するサーバ名にあわせて異なるサーバ証明書を配信し、それに基づいて暗号方式を確立します
注2: サーバ名ごとに異なる IP アドレスを使っているケースでは、IP アドレスからどのサーバにアクセスしているか判明するため、サーバ名を暗号化する意味がありません
注2: サーバ名ごとに異なる IP アドレスを使っているケースでは、IP アドレスからどのサーバにアクセスしているか判明するため、サーバ名を暗号化する意味がありません
Thursday, June 14, 2018
Git で全ブランチから検索
ググったけどmacOSでぱっと動くのがなかったのでメモがてら書く。
全ローカルブランチから検索
% git grep keyword $(git branch | colrm 1 2)
リモート含む全ブランチから検索
% git grep keyword $(git branch -a | colrm 1 2)
% git grep keyword $(git branch | colrm 1 2)
リモート含む全ブランチから検索
% git grep keyword $(git branch -a | colrm 1 2)
Tuesday, June 12, 2018
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
先週スウェーデンのKistaで開催された第５回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。
提案者として、その背景にある考え方を整理したいと思います。
▪️提案内容
詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、
これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。
赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通信は暗号化されているが、誰と話しているかはわからない）、青は認証済の暗号化を示しています。従来は５層のレイヤで２重の暗号化をしていたのが、４層のレイヤで１重の暗号化を行うようににかわることがわかります。
なぜ、このような変更を採用することになったのでしょうか。
▪️「レイヤ化」アプローチの限界
伝統的なTLSスタックにおいて、TLS接続はTCP/IP接続の拡張として表現されます。たとえば、JavaのSSLSocketはSocketを拡張したクラスです。
書き込みや読み込み命令はSSLSocketに対して同期命令として発行され、SSLSocketの中で適宜Socket I/Oに変換されます。
この手法の問題は、ソケットの管理が困難になりがちなことです。
たとえば、イベントドリブンなプログラムにおいては、同期I/Oではなく非同期I/Oが求められます。このことは、TLSスタックに非同期I/O用のモードを別途設けるか、あるいは、TLSスタックに対し、アプリケーション側からソケットのようなAPIをもつバッファを提供してやる必要がでてくることを意味します。
また、ヘッドオブラインブロッキングの影響を制御するために、暗号化するブロックサイズを制御し、ブロック単位で送信しようにも、そのような制御を可能にするインターフェイスが存在しないという問題があります注2。
これらの点に鑑み、H2Oでは、レイヤ化ではなく、入力バッファと出力バッファを引数としてハンドシェイクや暗号化関数を呼び出すというコーデックスタイルのAPIをもつ独自のTLSスタック「picotls」を開発し、TLS 1.3むけに採用してきました。
▪️「トランスポート層による暗号化」の必要性
TCP上でTLSを使う上での問題点のひとつが、第三者がいつでも接続をリセットできるという点です。このような攻撃が可能なのは、TCP自体が認証付き暗号によって保護されておらず、リセットを引き起こすようなパケットを誰でも生成できてしまうからです。
このようなトランスポート層への攻撃に対処するため、QUICのこれまでのドラフトでは、QUICの上で動くTLSスタックから鍵を「エクスポート」し、この鍵を使ってパケットを暗号化してきました。
この点を指して、picotlsの共同開発者であるChristian Huitema氏は「TLSの利用形態はレイヤからコンポーネントへ変化している」と指摘してきました。プログラミング上の都合のみならず、プロトコル設計上の都合からも、従来のTLSをレイヤとして利用するアプローチが限界に来ていたことがわかります。
利用形態の変化はともかく、これまでのドラフトのアプローチは以下の各点の問題を抱えるものでした。
これらの問題を解決しようとする動きとしては、先行してIETF 101におけるEric Rescorla氏によるDTLSへの移行提案がありましたが、DTLSのパケットフォーマットがQUICが必要する機能を提供できない点や、再送制御がハンドシェイク前と後と異なってしまう点などが問題視されていました。
それを踏まえ、DTLSという、QUICとは異なるプロトコルを組み合わせるくらいなら、いっそTLSスタックを分割して、QUICのパケットフォーマットをそのまま使おう、というのが、今回の提案の骨子だったわけです。
従来のドラフトと比較した利点としては、
また、この提案が受け入れられた背景として、TLSスタックの従来のAPIに限界があることが共通理解となっていた、という点もあげられるでしょう。
▪️まとめ
QUICではTLSをハンドシェイクと暗号化という２つの機能に分割して使用することになりました。このことは品質向上につながります。
TLSから見ると、TCP上での使用を前提としたTLS 1.3、UDP上での使用を前提に異なるパケットフォーマットを採用したDTLS 1.3に加え、第３のパケットフォーマットをもつプロトコルが誕生することを意味します。
今後策定されるプロトコルにおいて暗号化が必須であることを考えると、TLSのハンドシェイクメッセージを使いつつ、プロトコル毎に異なるパケットフォーマットを定義する流れが一般化するかもしれません。
長期的にみると、TLSの解体と再構成につながるかもしれませんね。
提案者として、その背景にある考え方を整理したいと思います。
▪️提案内容
詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、
- TLSスタックをふたつに分割し
- パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成
- ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う
これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。
図1. 従来方式
図2. 新方式
赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通信は暗号化されているが、誰と話しているかはわからない）、青は認証済の暗号化を示しています。従来は５層のレイヤで２重の暗号化をしていたのが、４層のレイヤで１重の暗号化を行うようににかわることがわかります。
なぜ、このような変更を採用することになったのでしょうか。
▪️「レイヤ化」アプローチの限界
伝統的なTLSスタックにおいて、TLS接続はTCP/IP接続の拡張として表現されます。たとえば、JavaのSSLSocketはSocketを拡張したクラスです。
書き込みや読み込み命令はSSLSocketに対して同期命令として発行され、SSLSocketの中で適宜Socket I/Oに変換されます。
この手法の問題は、ソケットの管理が困難になりがちなことです。
たとえば、イベントドリブンなプログラムにおいては、同期I/Oではなく非同期I/Oが求められます。このことは、TLSスタックに非同期I/O用のモードを別途設けるか、あるいは、TLSスタックに対し、アプリケーション側からソケットのようなAPIをもつバッファを提供してやる必要がでてくることを意味します。
また、ヘッドオブラインブロッキングの影響を制御するために、暗号化するブロックサイズを制御し、ブロック単位で送信しようにも、そのような制御を可能にするインターフェイスが存在しないという問題があります注2。
これらの点に鑑み、H2Oでは、レイヤ化ではなく、入力バッファと出力バッファを引数としてハンドシェイクや暗号化関数を呼び出すというコーデックスタイルのAPIをもつ独自のTLSスタック「picotls」を開発し、TLS 1.3むけに採用してきました。
▪️「トランスポート層による暗号化」の必要性
TCP上でTLSを使う上での問題点のひとつが、第三者がいつでも接続をリセットできるという点です。このような攻撃が可能なのは、TCP自体が認証付き暗号によって保護されておらず、リセットを引き起こすようなパケットを誰でも生成できてしまうからです。
このようなトランスポート層への攻撃に対処するため、QUICのこれまでのドラフトでは、QUICの上で動くTLSスタックから鍵を「エクスポート」し、この鍵を使ってパケットを暗号化してきました。
この点を指して、picotlsの共同開発者であるChristian Huitema氏は「TLSの利用形態はレイヤからコンポーネントへ変化している」と指摘してきました。プログラミング上の都合のみならず、プロトコル設計上の都合からも、従来のTLSをレイヤとして利用するアプローチが限界に来ていたことがわかります。
利用形態の変化はともかく、これまでのドラフトのアプローチは以下の各点の問題を抱えるものでした。
- 暗号化をTLSとQUICという２つのソフトウェアスタックで行うという二重暗号化
- 鍵交換後もハンドシェイク完了まで攻撃に対し脆弱
- 鍵の使用開始タイミングが不明確
これらの問題を解決しようとする動きとしては、先行してIETF 101におけるEric Rescorla氏によるDTLSへの移行提案がありましたが、DTLSのパケットフォーマットがQUICが必要する機能を提供できない点や、再送制御がハンドシェイク前と後と異なってしまう点などが問題視されていました。
それを踏まえ、DTLSという、QUICとは異なるプロトコルを組み合わせるくらいなら、いっそTLSスタックを分割して、QUICのパケットフォーマットをそのまま使おう、というのが、今回の提案の骨子だったわけです。
従来のドラフトと比較した利点としては、
- 二重暗号化がなくなる
- TLS 1.3と同じタイミングで暗号鍵を変更するため、ハンドシェイク中の攻撃耐性が向上する注3
- 鍵管理をTLSスタックに依存できるようになるので、QUICスタックの品質向上に寄与する
- パケットフォーマットは引き続きQUICワーキンググループで設計管理、拡張される
また、この提案が受け入れられた背景として、TLSスタックの従来のAPIに限界があることが共通理解となっていた、という点もあげられるでしょう。
▪️まとめ
QUICではTLSをハンドシェイクと暗号化という２つの機能に分割して使用することになりました。このことは品質向上につながります。
TLSから見ると、TCP上での使用を前提としたTLS 1.3、UDP上での使用を前提に異なるパケットフォーマットを採用したDTLS 1.3に加え、第３のパケットフォーマットをもつプロトコルが誕生することを意味します。
今後策定されるプロトコルにおいて暗号化が必須であることを考えると、TLSのハンドシェイクメッセージを使いつつ、プロトコル毎に異なるパケットフォーマットを定義する流れが一般化するかもしれません。
長期的にみると、TLSの解体と再構成につながるかもしれませんね。
注1: TLSスタックが共通鍵を提供しQUICスタック側で暗号化を行ってもよい
注2: TLSスタックの下にあるソケットAPIはあくまでバイト列をやりとりするためのものであって、レコードの切れ目がどこにあるかを表現する前提になっていない、ということ
注3: 図2において、赤で示される、パケット注入攻撃が可能なタイミングが短くなっていることが確認できます
注2: TLSスタックの下にあるソケットAPIはあくまでバイト列をやりとりするためのものであって、レコードの切れ目がどこにあるかを表現する前提になっていない、ということ
注3: 図2において、赤で示される、パケット注入攻撃が可能なタイミングが短くなっていることが確認できます
Saturday, June 2, 2018
H2O version 2.3.0-beta1 released, improvements presented at Rubykaigi 2018
Today, I am happy to announce the release of H2O version 2.3.0-beta1.
Version 2.3 is going to be the largest release in the history of H2O. Beta-1 already includes more than 50 changes contributed by more than 10 developers.
Improvements include:
The improvements related to mruby and HTTP extensions were covered in today's our talk at RubyKaigi 2018 and the slides are below. Please enjoy!
Version 2.3 is going to be the largest release in the history of H2O. Beta-1 already includes more than 50 changes contributed by more than 10 developers.
Improvements include:
- more powerful mruby handler with Rack and Rack middleware support
- load balancing in the reverse proxy handler (#1277, #1361)
- more flexible configuration through the use of !env and stash directives (#1524, 1739)
- support for new and upcoming HTTP extensions: Server-Timing (#1646, #1717), 103 Early Hints (#1727, #1767), 425 Too Early (#1344)
The improvements related to mruby and HTTP extensions were covered in today's our talk at RubyKaigi 2018 and the slides are below. Please enjoy!
Friday, June 1, 2018
H2O version 2.2.5 released with a vulnerability fix
Today, we have released H2O version 2.2.5.
This is a bug-fix release, including one security-related fix.
The detail of the vulnerability is explained in #1775. Users of H2O are advised to upgrade immediately to version 2.2.5 or to disable access logging.
We would like to thank Marlies Ruck, ForAllSecure for finding the issue.
List of other changes can be found here.
This is a bug-fix release, including one security-related fix.
The detail of the vulnerability is explained in #1775. Users of H2O are advised to upgrade immediately to version 2.2.5 or to disable access logging.
We would like to thank Marlies Ruck, ForAllSecure for finding the issue.
List of other changes can be found here.
Tuesday, May 1, 2018
IETF報告会で「TLS 1.3とその周辺の標準化動向」について発表してきた
先週金曜日に開催されたIETF報告会にて、「TLS 1.3とその周辺の標準化動向」について発表する機会をいただきました。その際のスライドが下のものになります。
TLS 1.3や関連する提案の技術的特徴とともに、スノーデン事件以来のテーマである通信内容のプライバシー保護とオシフィケーション（硬化）対策がどのように進んでいるか、ご理解いただける一助になれば幸いです。
なお、本スライドは会社のテンプレートを使用していますが、会社としての見解を表明するものではありません。
TLS 1.3や関連する提案の技術的特徴とともに、スノーデン事件以来のテーマである通信内容のプライバシー保護とオシフィケーション（硬化）対策がどのように進んでいるか、ご理解いただける一助になれば幸いです。
なお、本スライドは会社のテンプレートを使用していますが、会社としての見解を表明するものではありません。
Thursday, April 26, 2018
海賊版サイトのブロッキングについてアンケートをとってみたら興味深い結果が出た
政府がISPに対し対し海賊版サイトのブロッキングを要請し、議論になっています。あなたは以下のどの対策が正しいと思いますか？
— Kazuho Oku (@kazuho) April 25, 2018
832票もの回答をいただきました。ありがとうございます。結果をみて、いくつか感想を述べさせていただきたいと思います。
▪️海賊版サイトに対し、なんらかの新たな対策が必要かどうかについて
83%の方々が、なんらかの新しい対策を取ることに積極的賛成、あるいは消極的賛成という立場を取られていることがわかりました。一方で、17%の方々が、少なくとも現時点では新たな対策は不要であり、出版社等の権利者は現行法に基づき、刑事告発、民事訴訟、DMCA Takedownなどの手法を用いて戦うべきだと考えていらっしゃることもわかりました。
▪️ブロッキングという手法について
意見が綺麗に割れました。
42%の方々が、緊急の、あるいは法整備に基づいたブロッキングが適当だとされました。一方、58%の方々が、ブロッキング以外の手法を用いた対策を整備すべき、あるいは整備は不要であると回答されました。
このことからは、「通信の秘密」が単なる法律の条文ではなく、守るべき価値のあるものだと考えていらっしゃる方々が相当数いらっしゃることも読み取れるのかと思います。
▪️ISPが政府の要請に従うべきかについて
5%の方々が、「ISP各社は政府の要請に従ってブロッキングすべき」と答えられました。私のフォロワーには（ブロッキングに従事することに法的リスクがあったり、通信の秘密を重要視したりしがちな）情報通信産業の関係者が多いことを考えると、緊急のブロッキングを求める声は実際にはもっと大きいと考えられます。
皆さんは、この結果を見て、どのように考えられますか？
▪️その他
ツイッターのアンケート機能の、各選択肢が25字制限というのは辛かった。「その他、わからない」という選択肢を足せなかったも悲しかった。
▪️免責事項
私はCDN企業に勤める従業員です（ただし、著作権を侵害するコンテンツの配布を禁止している企業であるため、海賊版サイトとの利害関係はない）。また、IETFにおいて、通信の傍受（と傍受によって可能になるブロッキング）が困難あるいは不可能になるようなプロトコル設計に従事しています。通信の秘密の保護はIETFのプロトコル設計の要件のひとつ（RFC 7258）なのですが、その価値について、他の方々がどのように考えているか、お伺いすることができて、うれしく思っています。
Tuesday, April 17, 2018
Fastlyのプログラマから見たCDN
4月13日に開催されたCDN Study (Akamai/Fastly)で使用したスライドをアップロードしました。Fastlyでミドルウェアを書いているプログラマから見た、CDNの面白さやFastlyの特徴について伝わればいいなと思います。
当日は、リクルートさんに会場をご提供いただき、多くの方々、またAkamaiの方々ともと触れ合うことができる、とても貴重な機会となりました。この場を借りて、皆さんに御礼申し上げる次第です。
当日は、リクルートさんに会場をご提供いただき、多くの方々、またAkamaiの方々ともと触れ合うことができる、とても貴重な機会となりました。この場を借りて、皆さんに御礼申し上げる次第です。
HTTP/2で 速くなるとき ならないとき
たいへん遅ればせながら、YAPC::Okinawa 2018 ONNNASONで使用したスライドを、こちらにて公開する次第です。
ベンチマークの難しさとチューニングの奥深さ、楽しさを共有できた結果がベストトーク賞につながったのかなと考えています。ありがとうございました＆今後ともよろしくお願いいたします。
ベンチマークの難しさとチューニングの奥深さ、楽しさを共有できた結果がベストトーク賞につながったのかなと考えています。ありがとうございました＆今後ともよろしくお願いいたします。
Subscribe to:
Posts (Atom)