2020年にDSRロードバランス環境を作る方法
TCPの時代もそうだったんですが、QUICにおいても、Linux等でソフトウェアロードバランサをipvsadmとDSR (direct server return, a.k.a. direct routing) を実現することは有効な手段です。 なんだけど、ipvsadm界隈はHA前提の込み入った設定か古いドキュメントしか見つからなかったので、最低限の検証環境のセットアップ方法を、ここにまとめる次第です。 ロードバランサ: echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward sudo ifconfig eth0:0 $VIP netmask 255.255.255.255 broadcast $VIP up sudo route add -host $VIP dev eth0:0 sudo ipvsadm -A -t $VIP:443 -s rr
HTTP のプライオリティが大きく変わろうとしている話（その他 IETF 105 雑感）
先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
Kazuho's Weblog: 次世代プロトコル（QUIC etc.）のセキュリティとプライバシー @ #builderscon
９月６日より開催中の builderscon 2018 において、登壇の機会をいただき、インターネットのトランスポート層プロトコルについてセキュリティやプライバシーに関わる設計がどのように進めてられているか、TLS と QUIC を中心に発表しました。 QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。 聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。 PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記
TLS の SNI 暗号化に関する Internet Draft を共同提出しました
Eric Rescorla (RTFM), Nick Sullivan (Cloudflare), Christopher Wood (Apple) の各氏とともに、SNI を暗号化する TLS 拡張を提案する Internet Draft を提出しました。 Encrypted Server Name Indication for TLS 1.3 アナウンスのメールにあるとおり、すでに NSS / Firefox と picotls / H2O で実装作業が開始されており、今月開催される IETF 102 で相互運用試験を行うとともに、標準化にむけた議論を深める予定です。 スノーデン事件以降、広範囲におよぶトラフィックモニタリングによるプライバシー侵害の懸念が明らかになるとともに、できるだけ多くのインターネット上の通信プロトコルを暗号化することが求められるようになってきました (参考: R
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
先週スウェーデンのKistaで開催された第５回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通
IETF報告会で「TLS 1.3とその周辺の標準化動向」について発表してきた
先週金曜日に開催されたIETF報告会にて、「TLS 1.3とその周辺の標準化動向」について発表する機会をいただきました。その際のスライドが下のものになります。 TLS 1.3や関連する提案の技術的特徴とともに、スノーデン事件以来のテーマである通信内容のプライバシー保護とオシフィケーション（硬化）対策がどのように進んでいるか、ご理解いただける一助になれば幸いです。 なお、本スライドは会社のテンプレートを使用していますが、会社としての見解を表明するものではありません。 Most schools also offer drama studies, music and physical education but these are usually not examined or marked. Home economics is sometimes taught to female studen
Kazuho's Weblog: 海賊版サイトのブロッキングについてアンケートをとってみたら興味深い結果が出た
政府がISPに対し対し海賊版サイトのブロッキングを要請し、議論になっています。あなたは以下のどの対策が正しいと思いますか？ — Kazuho Oku (@kazuho) April 25, 2018 832票もの回答をいただきました。ありがとうございます。結果をみて、いくつか感想を述べさせていただきたいと思います。 ▪️海賊版サイトに対し、なんらかの新たな対策が必要かどうかについて 83%の方々が、なんらかの新しい対策を取ることに積極的賛成、あるいは消極的賛成という立場を取られていることがわかりました。一方で、17%の方々が、少なくとも現時点では新たな対策は不要であり、出版社等の権利者は現行法に基づき、刑事告発、民事訴訟、DMCA Takedownなどの手法を用いて戦うべきだと考えていらっしゃることもわかりました。 ▪️ブロッキングという手法について 意見が綺麗に割れました。 42%の方々
CI 用 Docker イメージ作成におけるベストプラクティス
H2O の CI では長らく、秘伝のタレ的な .travis.yml を使い続けてきたのですが、なにぶん依存関係が多いもので、だいぶメンテナンスが辛い感じになってきていました。また、CI テストで発生したエラーの調査の度に、時間のかかる CI を回さなければならないことが、開発者のストレスとなっていました。 そこで一念発起して、Docker イメージを使った CI に切り替えることにしました（実行環境としては引き続き Travis を使います）。 その際に、要件として以下のようなことを考えました。 CI以外に、コミット前のテストにも使えるようなイメージにすること コマンド一発でビルドとテストが動作すること 無駄な処理をしないこと その結果、以下のような実装になりました。 テストに必要なソフトウェア群をインストールしたイメージを Docker Hub にアップロードしておく テストには、1.
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
Fastly に入社しました
Summary in English: Joined Fastly, will continue my work on H2O there as an open-source developer. 2017年1月1日付で、Fastly 社へ転職したので報告いたします。 過去５年間、DeNA では R&D 的な立場から、様々な基盤的ソフトウェア（オープンソースになったものもありますし、クローズドなものもあります）の開発に携わってきました。 最近２年間は、同社のゲーム用サーバに端を発するオープンソースの HTTP/2 サーバ「H2O」の開発に従事してきましたが、その実装品質が高く評価され、世界有数のコンテンツ配信ネットワーク（CDN）である Fastly で採用された他、大規模なウェブサービス事業者で採用にむけた動きが進むなどの成果が出つつあります。 また、H2O における実装経験をもとに、H
H2O HTTP2 server 2.0 released!
We are happy to announce the release of H2O version 2.0. It is a major update from 1.7 series, including many improvements and bug fixes. The most prominent changes are:support for Brotli compression directives for file-level resource mapping addition of the status handler reverse proxying using HTTPS Full list of changes can be found here. Please refer to the reference documentation to find out h
H2O HTTP/2 server goes 2.0 adding support for Brotli
Today, I am happy to announce the release of H2O version 2.0.0-beta1, the first release of the 2.0 series. In the release, we have added support for Brotli in two ways. For those who do not know, Brotli is a new compression method developed by Google. It is said to compress files ~20% smaller than gzip - means less bandwidth consumed and faster rendering on the client side. Mozilla has already add
File-level mapping introduced in H2O version 2.0
As the developer of H2O, the lack of ability to define a mapping for a specific path (not a directory) has been one of the complaints I hear the most. Finally, we have a fix for the issue, and that is why the next release will be given the number 2.0. Starting from H2O version 2.0.0beta-1, it is possible to write a configuration like the following. The example maps all requests to a FastCGI server
Name Constraints を使った独自CAの運用手順
ウェブブラウザが新機能をHTTPSでしか有効にしないことが多くなってきたので、開発環境でもHTTPSを使いたい。でも、開発環境用にサーバ証明書を買うのは手間。Let's Encryptも運用がめんどくさいとか、社内からしかアクセスできないサーバへの証明書発行が難しいとかいろいろあるし…ってそこでName Constraintsを使った独自CAですよ奥さん。 Name Constraints が何であるかについては、以前オレオレ認証局の適切な運用とName Constraintsに書いたとおり。 本稿では、Name Constraintsを使うCAの運用手順を説明する。 1. CA鍵と証明書の作成 1.1. CAの秘密鍵を作成 % openssl genrsa -out ca.key 2048 1.2. openssl.cnfにCA証明書に設定する属性を指定するセクションを追記 [priva
Using H2O with Let's Encrypt
Let's Encrypt is a new certificate authority that is going to issue certificates for free using automated validation process. They have announced that they will enter public beta on Dec. 3rd 2015. This blogpost explains how to setup a H2O using the automated process. Step 1. Install the client % git clone https://github.com/letsencrypt/letsencrypt.git Step 2. Obtain the certificate If you already
Neverbleed - RSAの秘密鍵演算を別プロセスに分離する話
機能毎にプロセスを分割し、それらを別個の権限のもとで実行することで、脆弱性があった場合の影響を抑え込むというのは、一定以上の規模をもつプログラムでは、しばしば見られるデザインパターンです。 qmailは、そのような設計がなされたメール配送デーモンとして名高いですし、OpenSSHもまた、認証プロセスと通信プロセスを分離することで、外部との通信を担当するコードにバグがあったとしても、ルート権限が奪われないように設計されています（参照: Privilege Separated OpenSSH）。 一方で、OpenSSLにはそのような権限分離は実装されていません。Heartbleedの際にサーバの秘密鍵が漏洩したのも、秘密鍵の取り扱いと、その他の通信の取り扱いを同一のメモリ空間の中で行っていたからだと考えることができます。 ないのなら、自分で作ればいいじゃない…ということで作りました。それが、N
前方秘匿性 (forward secrecy) をもつウェブサイトの正しい設定方法
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
Writing signal-aware waitpid in Perl
As I have talked in YAPC::Asia couple of years ago, the wait functions (e.g. wait, waitpid) of Perl do not return EINTR when receiving a signal. This is a problem if you would want to wait for child processes until receiving a signal. Proc::Wait3 can be a solution, however the module may be hard to install as it is an XS module. It should also be noted that the module provides replacement for wait
H2OとPHPを組み合わせるの、超簡単です（もしくはmod_rewriteが不要な理由）
FastCGI対応機能がH2Oにマージされたことを受けて、uzullaさんが「H2OでPHP（がちょっとだけ動くまで）」という記事を書いてくださっています。 ありがたやありがたや。 その中で、 http://hoge/entry/1 みたいなのをphpにマップする方法はまだよくわかってません。その内しらべます github.comを読む限り FastCGI (or PHP) applications should be as easily configurable as it is for the Apache HTTP serverということで、やったぜ！ってなるんですけど、nginxはもとより、Apacheにおいても現状ルーターをつかっているようなアプリだとhtaccessをいちいちかかないといけないので、Apacheみたいなスタイルが楽なのか？というとちょっと疑問があります。 （たと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Velocity in Amsterdam 2016 で HTTP/2 とその先にある最適化について話してきた