Thursday, June 14, 2018

Git で全ブランチから検索

ググったけどmacOSでぱっと動くのがなかったのでメモがてら書く。

全ローカルブランチから検索
% git grep keyword $(git branch | colrm 1 2)

リモート含む全ブランチから検索
% git grep keyword $(git branch -a | colrm 1 2)

Tuesday, June 12, 2018

QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉

先週スウェーデンのKistaで開催された第5回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。

提案者として、その背景にある考え方を整理したいと思います。

▪️提案内容

詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、
  • TLSスタックをふたつに分割し
  • パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成
  • ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う
というものです。

これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。

図1. 従来方式

図2. 新方式

赤は難読化(つまり正当なパケットと攻撃との区別がつかない)、黄は未認証の暗号化(通信は暗号化されているが、誰と話しているかはわからない)、青は認証済の暗号化を示しています。従来は5層のレイヤで2重の暗号化をしていたのが、4層のレイヤで1重の暗号化を行うようににかわることがわかります。

なぜ、このような変更を採用することになったのでしょうか。

▪️「レイヤ化」アプローチの限界

伝統的な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という2つのソフトウェアスタックで行うという二重暗号化
  • 鍵交換後もハンドシェイク完了まで攻撃に対し脆弱
  • 鍵の使用開始タイミングが不明確

これらの問題を解決しようとする動きとしては、先行してIETF 101におけるEric Rescorla氏によるDTLSへの移行提案がありましたが、DTLSのパケットフォーマットがQUICが必要する機能を提供できない点や、再送制御がハンドシェイク前と後と異なってしまう点などが問題視されていました。

それを踏まえ、DTLSという、QUICとは異なるプロトコルを組み合わせるくらいなら、いっそTLSスタックを分割して、QUICのパケットフォーマットをそのまま使おう、というのが、今回の提案の骨子だったわけです。

従来のドラフトと比較した利点としては、
  • 二重暗号化がなくなる
  • TLS 1.3と同じタイミングで暗号鍵を変更するため、ハンドシェイク中の攻撃耐性が向上する注3
  • 鍵管理をTLSスタックに依存できるようになるので、QUICスタックの品質向上に寄与する
  • パケットフォーマットは引き続きQUICワーキンググループで設計管理、拡張される
といった点があげられることになります。

また、この提案が受け入れられた背景として、TLSスタックの従来のAPIに限界があることが共通理解となっていた、という点もあげられるでしょう。

▪️まとめ

QUICではTLSをハンドシェイクと暗号化という2つの機能に分割して使用することになりました。このことは品質向上につながります。

TLSから見ると、TCP上での使用を前提としたTLS 1.3、UDP上での使用を前提に異なるパケットフォーマットを採用したDTLS 1.3に加え、第3のパケットフォーマットをもつプロトコルが誕生することを意味します。

今後策定されるプロトコルにおいて暗号化が必須であることを考えると、TLSのハンドシェイクメッセージを使いつつ、プロトコル毎に異なるパケットフォーマットを定義する流れが一般化するかもしれません。

長期的にみると、TLSの解体と再構成につながるかもしれませんね。


注1: TLSスタックが共通鍵を提供しQUICスタック側で暗号化を行ってもよい
注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:
  • 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.

Tuesday, May 1, 2018

IETF報告会で「TLS 1.3とその周辺の標準化動向」について発表してきた

先週金曜日に開催されたIETF報告会にて、「TLS 1.3とその周辺の標準化動向」について発表する機会をいただきました。その際のスライドが下のものになります。



TLS 1.3や関連する提案の技術的特徴とともに、スノーデン事件以来のテーマである通信内容のプライバシー保護とオシフィケーション(硬化)対策がどのように進んでいるか、ご理解いただける一助になれば幸いです。

なお、本スライドは会社のテンプレートを使用していますが、会社としての見解を表明するものではありません。

Thursday, April 26, 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の方々ともと触れ合うことができる、とても貴重な機会となりました。この場を借りて、皆さんに御礼申し上げる次第です。