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

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



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

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

海賊版サイトのブロッキングについてアンケートをとってみたら興味深い結果が出た

政府がISPに対し対し海賊版サイトのブロッキングを要請し、議論になっています。あなたは以下のどの対策が正しいと思いますか？

— Kazuho Oku (@kazuho) April 25, 2018

832票もの回答をいただきました。ありがとうございます。結果をみて、いくつか感想を述べさせていただきたいと思います。

▪️海賊版サイトに対し、なんらかの新たな対策が必要かどうかについて

83%の方々が、なんらかの新しい対策を取ることに積極的賛成、あるいは消極的賛成という立場を取られていることがわかりました。一方で、17%の方々が、少なくとも現時点では新たな対策は不要であり、出版社等の権利者は現行法に基づき、刑事告発、民事訴訟、DMCA Takedownなどの手法を用いて戦うべきだと考えていらっしゃることもわかりました。

▪️ブロッキングという手法について

意見が綺麗に割れました。

42%の方々が、緊急の、あるいは法整備に基づいたブロッキングが適当だとされました。一方、58%の方々が、ブロッキング以外の手法を用いた対策を整備すべき、あるいは整備は不要であると回答されました。
このことからは、「通信の秘密」が単なる法律の条文ではなく、守るべき価値のあるものだと考えていらっしゃる方々が相当数いらっしゃることも読み取れるのかと思います。

▪️ISPが政府の要請に従うべきかについて

5%の方々が、「ISP各社は政府の要請に従ってブロッキングすべき」と答えられました。私のフォロワーには（ブロッキングに従事することに法的リスクがあったり、通信の秘密を重要視したりしがちな）情報通信産業の関係者が多いことを考えると、緊急のブロッキングを求める声は実際にはもっと大きいと考えられます。


皆さんは、この結果を見て、どのように考えられますか？

▪️その他

ツイッターのアンケート機能の、各選択肢が25字制限というのは辛かった。「その他、わからない」という選択肢を足せなかったも悲しかった。

▪️免責事項

私はCDN企業に勤める従業員です（ただし、著作権を侵害するコンテンツの配布を禁止している企業であるため、海賊版サイトとの利害関係はない）。また、IETFにおいて、通信の傍受（と傍受によって可能になるブロッキング）が困難あるいは不可能になるようなプロトコル設計に従事しています。通信の秘密の保護はIETFのプロトコル設計の要件のひとつ（RFC 7258）なのですが、その価値について、他の方々がどのように考えているか、お伺いすることができて、うれしく思っています。

Fastlyのプログラマから見たCDN

4月13日に開催されたCDN Study (Akamai/Fastly)で使用したスライドをアップロードしました。Fastlyでミドルウェアを書いているプログラマから見た、CDNの面白さやFastlyの特徴について伝わればいいなと思います。



当日は、リクルートさんに会場をご提供いただき、多くの方々、またAkamaiの方々ともと触れ合うことができる、とても貴重な機会となりました。この場を借りて、皆さんに御礼申し上げる次第です。

HTTP/2で 速くなるとき ならないとき

たいへん遅ればせながら、YAPC::Okinawa 2018 ONNNASONで使用したスライドを、こちらにて公開する次第です。

ベンチマークの難しさとチューニングの奥深さ、楽しさを共有できた結果がベストトーク賞につながったのかなと考えています。ありがとうございました＆今後ともよろしくお願いいたします。

HTTP/2で 速くなるとき ならないとき from Kazuho Oku

CI 用 Docker イメージ作成におけるベストプラクティス

H2O の CI では長らく、秘伝のタレ的な .travis.yml を使い続けてきたのですが、なにぶん依存関係が多いもので、だいぶメンテナンスが辛い感じになってきていました。また、CI テストで発生したエラーの調査の度に、時間のかかる CI を回さなければならないことが、開発者のストレスとなっていました。

そこで一念発起して、Docker イメージを使った CI に切り替えることにしました（実行環境としては引き続き Travis を使います）。

その際に、要件として以下のようなことを考えました。

• CI以外に、コミット前のテストにも使えるようなイメージにすること
• コマンド一発でビルドとテストが動作すること
• 無駄な処理をしないこと

その結果、以下のような実装になりました。

• テストに必要なソフトウェア群をインストールしたイメージを Docker Hub にアップロードしておく
• テストには、1. テスト用コンテナにコードのあるディレクトリをマウントし、2. アウトオブトリービルド^注1とテストを実行するスクリプトを書く
• CI環境では、そのスクリプトを実行する
• 開発者がローカルでそのスクリプトを実行してテストしてもよい

Dockerfile および CI 実行用のスクリプトは、H2O のレポジトリにある以下のファイルです。

• misc/docker-ci/Dockerfile
• misc/docker-ci/check.mk

結果、Docker 導入前に90行あった .travis.yml は23行にまで短くなり、また、CI に必要な時間も2割ほど減少しました（CI を実行するたびに、必要なソフトウェアをビルドする手間が不要になったため）。

また、開発者が各個人の環境において make -f misc/docker-ci/check.mk と make を実行するだけで、いつでも（コミット前でも）CI 環境と同様のテストが実行できるようになりました。テストが失敗したら、コンテナを立ち上げっぱなしにして、ローカルでコード修正＆特定のテスト再実行を繰り返すことも可能なので、バグ修正が捗ります。

まとめ：CI 用の Docker イメージを作るのではなく、テスト用の CI イメージを作り、それを CI に展開すべき

言わずもがなかもしれませんが、備忘録としてまとめておきます。


注1: ソースディレクトリ以外の場所に生成物を配置するビルド手法のこと。アウトオブトリービルドができない場合はaufsを使っても良いのかもしれない

git blameでプルリクエストの番号を表示する

GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。

というわけで書いたのが git-blame-pr.pl。

以下のような感じで表示されるので、調査がはかどります。

$ git-blame-pr.pl lib/core/request.c
(中略)
PR #446   
PR #606   h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status)
PR #606   {
PR #606       if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308))
PR #606           method = h2o_iovec_init(H2O_STRLIT("GET"));
PR #606       return method;
PR #606   }
PR #606   
PR #1436  static void do_push_path(void *_req, const char *path, size_t path_len, int is_critical)
PR #1436  {
PR #1436      h2o_req_t *req = _req;
PR #1436  
PR #1436      if (req->conn->callbacks->push_path != NULL)
PR #1436          req->conn->callbacks->push_path(req, path, path_len, is_critical);
PR #1436  }
PR #1436  
PR #1169  h2o_iovec_t h2o_push_path_in_link_header(h2o_req_t *req, const char *value, size_t value_len)
PR #446   {
PR #1169      h2o_iovec_t ret = h2o_iovec_init(value, value_len);
PR #446   
PR #1436      h2o_extract_push_path_from_link_header(&req->pool, value, value_len, req->path_normalized, req->input.scheme,
PR #1436                                             req->input.authority, req->res_is_delegated ? req->scheme : NULL,
PR #1436                                             req->res_is_delegated ? &req->authority : NULL, do_push_path, req, &ret);
PR #446   
PR #1169      return ret;
PR #446   }

H2O version 2.2.4 released, incl. vulnerability fixes

Today, we have released H2O version 2.2.4.

This is a bug-fix release. Some of the fixes are security-related.

The details of the vulnerabilities being fixed can be found in the links below. Users are encouraged to upgrade to 2.2.4 if they are affected or unsure.

• fix crash when logging TLS 1.3 properties (CVE-2017-10872) (reported by MITSUNARI Shigeo)
• fix crash when handling malformed HTTP/2 request (CVE-2017-10908) (reported by Eiichi Tsukata)

We would like to thank the people for reporting the issues.