H2O version 2.2.6 and 2.3.0-beta2 have been released.
This release addresses a series of DoS attack vectors that have been recently found on a broad range of HTTP/2 stacks.
Specifically, H2O had been deemed vulnerable to the following, and fixed:
* CVE-2019-9512 (Ping Flood)
* CVE-2019-9514 (Reset Flood)
* CVE-2019-9515 (Settings Flood)
Users of previous versions of H2O are advised to update to the recent versions.
For more information, please refer to issue 2090: HTTP/2 DoS attack vulnerabilities CVE-2019-9512 CVE-2019-9514 CVE-2019-9515.
Showing posts with label HTTP. Show all posts
Showing posts with label HTTP. Show all posts
Wednesday, August 14, 2019
Tuesday, July 30, 2019
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 ワーキンググループでは、IETF 105 において、プライオリティをどうするか、議論することになっていました。
HTTP/2 の優先度制御を十分にサポートしていないサーバが多いことは事実です。まともに実装したサーバを動かしている大規模事業者はＦで始まる２社くらいではないでしょうか。一方で、実装しようと思えばできるものを「嫌だから変えたい」と言って変えようとするのは、信頼感のある話ではありません。HTTP/2 の仕様策定に関わった当事者が主張するのであれば、なおさらです。
変えるのであれば、皆が納得できるようなものにすべきです。
という考えを踏まえ、今月初頭、僕は Cloudflare 社の Lucas Pardue 氏とともに、HTTP ヘッダベースの優先度制御手法を提案しました（提案仕様, 発表資料）。具体的には、以下のような特徴をもつ提案です。
HTTP/2 方式の堅持を主張するプレーヤーが減ったことで、焦点は、QUIC と HTTP/3 への影響を最小限に抑えつつ、新しい優先度制御手法に如何に軟着陸するか、という点に移りました。
結果、QUIC と HTTP の両ワーキンググループで HTTP/3 から優先度制御に関する規定を取り除くことが決定しました注2（QUIC WG 議事録, HTTP WG 議事録）。HTTP/2 についても、現行の優先度制御を廃止するか、「優先度制御しない」ことを表明する機能を追加するかが議論され、後者が採択されました。また、新しい優先度制御手法を議論するサイドミーティングも開かれ、我々の提案した手法を中心に議論が行われました。
今後は、HTTP ワーキンググループにおいて組織された、新しい優先度制御手法を議論する小グループにおいて、迅速な合意が得られるかが焦点になります。
その他、僕の仕事に関係しているところでいうと、共著者の一人を務めている Encrypted SNI は徐々に進展し、また、maprg（測定と解析に関するリサーチグループ）では、Fastly で開発を進めている quicly を使った、衛星ネットワークでの QUICの パフォーマンス試験や、エンドポイントが露出するパケットあたり２ビットの情報を使って、プライバシー問題を抑えつつネットワーク事業者が輻輳の分析を行えるようにする手法の検証報告がありました。
感想：つかれた。
注1: 4月に開催された HTTP Workshop でも話があったのですが、僕は欠席したので雰囲気を知りません。
注2: 優先度を伝達するプロトコルと、その関連規定を取り除くのであって、サーバ独自の優先度制御など、プロトコルによらない手段を否定するものではありません。
いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。
HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。
ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキンググループでは、IETF 105 において、プライオリティをどうするか、議論することになっていました。
HTTP/2 の優先度制御を十分にサポートしていないサーバが多いことは事実です。まともに実装したサーバを動かしている大規模事業者はＦで始まる２社くらいではないでしょうか。一方で、実装しようと思えばできるものを「嫌だから変えたい」と言って変えようとするのは、信頼感のある話ではありません。HTTP/2 の仕様策定に関わった当事者が主張するのであれば、なおさらです。
変えるのであれば、皆が納得できるようなものにすべきです。
という考えを踏まえ、今月初頭、僕は Cloudflare 社の Lucas Pardue 氏とともに、HTTP ヘッダベースの優先度制御手法を提案しました（提案仕様, 発表資料）。具体的には、以下のような特徴をもつ提案です。
- HTTP/2 よりも単純な、各リクエストが独立した優先度を保持する方式
- たった８種類の優先度
- サーバとクライアントによる優先度の協調制御
- HTTP ヘッダを利用することで、優先度制御を HTTP のバージョン非依存にするとともに、将来の拡張性を確保
HTTP/2 方式の堅持を主張するプレーヤーが減ったことで、焦点は、QUIC と HTTP/3 への影響を最小限に抑えつつ、新しい優先度制御手法に如何に軟着陸するか、という点に移りました。
結果、QUIC と HTTP の両ワーキンググループで HTTP/3 から優先度制御に関する規定を取り除くことが決定しました注2（QUIC WG 議事録, HTTP WG 議事録）。HTTP/2 についても、現行の優先度制御を廃止するか、「優先度制御しない」ことを表明する機能を追加するかが議論され、後者が採択されました。また、新しい優先度制御手法を議論するサイドミーティングも開かれ、我々の提案した手法を中心に議論が行われました。
今後は、HTTP ワーキンググループにおいて組織された、新しい優先度制御手法を議論する小グループにおいて、迅速な合意が得られるかが焦点になります。
その他、僕の仕事に関係しているところでいうと、共著者の一人を務めている Encrypted SNI は徐々に進展し、また、maprg（測定と解析に関するリサーチグループ）では、Fastly で開発を進めている quicly を使った、衛星ネットワークでの QUICの パフォーマンス試験や、エンドポイントが露出するパケットあたり２ビットの情報を使って、プライバシー問題を抑えつつネットワーク事業者が輻輳の分析を行えるようにする手法の検証報告がありました。
感想：つかれた。
注1: 4月に開催された HTTP Workshop でも話があったのですが、僕は欠席したので雰囲気を知りません。
注2: 優先度を伝達するプロトコルと、その関連規定を取り除くのであって、サーバ独自の優先度制御など、プロトコルによらない手段を否定するものではありません。
Saturday, September 8, 2018
次世代プロトコル（QUIC etc.）のセキュリティとプライバシー @ #builderscon
９月６日より開催中の builderscon 2018 において、登壇の機会をいただき、インターネットのトランスポート層プロトコルについてセキュリティやプライバシーに関わる設計がどのように進めてられているか、TLS と QUIC を中心に発表しました。
QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。
聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。
PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記事もあわせてご覧いただけます。
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
TLS の SNI 暗号化に関する Internet Draft を共同提出しました
QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。
聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。
PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記事もあわせてご覧いただけます。
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
TLS の SNI 暗号化に関する Internet Draft を共同提出しました
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 アドレスからどのサーバにアクセスしているか判明するため、サーバ名を暗号化する意味がありません
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, April 17, 2018
Fastlyのプログラマから見たCDN
4月13日に開催されたCDN Study (Akamai/Fastly)で使用したスライドをアップロードしました。Fastlyでミドルウェアを書いているプログラマから見た、CDNの面白さやFastlyの特徴について伝わればいいなと思います。
当日は、リクルートさんに会場をご提供いただき、多くの方々、またAkamaiの方々ともと触れ合うことができる、とても貴重な機会となりました。この場を借りて、皆さんに御礼申し上げる次第です。
当日は、リクルートさんに会場をご提供いただき、多くの方々、またAkamaiの方々ともと触れ合うことができる、とても貴重な機会となりました。この場を借りて、皆さんに御礼申し上げる次第です。
HTTP/2で 速くなるとき ならないとき
たいへん遅ればせながら、YAPC::Okinawa 2018 ONNNASONで使用したスライドを、こちらにて公開する次第です。
ベンチマークの難しさとチューニングの奥深さ、楽しさを共有できた結果がベストトーク賞につながったのかなと考えています。ありがとうございました＆今後ともよろしくお願いいたします。
ベンチマークの難しさとチューニングの奥深さ、楽しさを共有できた結果がベストトーク賞につながったのかなと考えています。ありがとうございました＆今後ともよろしくお願いいたします。
Friday, December 15, 2017
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.
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)
Thursday, October 19, 2017
H2O version 2.2.3 released, incl. vulnerability fixes
Today, we have released H2O version 2.2.3.
This is a bug-fix release, including two security fixes and 14 bug fixes from 7 people. Please consult the release page for details.
The vulnerabilities being fixed are #1459 (CVE-2017-10868) and #1460 (CVE-2017-10869). Both are vulnerabilities against DoS attacks. It is recommended that the users of H2O update their deployments to the newest release.
We would like to thank the developers for working on the fixes and for users reporting the issues.
This is a bug-fix release, including two security fixes and 14 bug fixes from 7 people. Please consult the release page for details.
The vulnerabilities being fixed are #1459 (CVE-2017-10868) and #1460 (CVE-2017-10869). Both are vulnerabilities against DoS attacks. It is recommended that the users of H2O update their deployments to the newest release.
We would like to thank the developers for working on the fixes and for users reporting the issues.
Wednesday, April 5, 2017
H2O version 2.2.0 released
Today I am happy to announce the release of H2O HTTP/2 server version 2.2.0.
The release includes over ten new features (show below) as well as bug fixes.
Some notable changes are covered in separate blogposts: H2O version 2.2 beta released with TLS 1.3 support and other improvements, JSON logging support is added to H2O HTTP/2 server version 2.2.0-beta3.
Full list of changes can be found here.
The release also comes with the up-to-date version of mruby. Recently, a series of security defects have been reported for the language runtime. Our understanding is that many of the vulnerabilities rely on an attacker writing the script (a model that does not apply to how mruby is used in H2O). However, you can turn off mruby support by providing
The release includes over ten new features (show below) as well as bug fixes.
- [core] add
crash-handler.wait-pipe-closeparameter #1092 - [core] introduce an option to bypass the
serverheader sent from upstream #1226 - [access-log] add
%{remote}pfor logging the remote port #1166 - [access-log] JSON logging #1208
- [access-log] add specifier for logging per-request environment variables #1221
- [access-log] add support for
<,>modifiers for logging either the original or the final response #1238 - [file] add directive for serving gzipped files, decompressing them on-the-fly #1140
- [http2] recognize
x-http2-push-onlyattribute onlinkheader #1169 - [http2] add optional timeout for closing connections upon graceful shutdown #1108
- [proxy] add directives for tweaking headers sent to upstream #1126
- [proxy] add directive for controlling the
viarequest header #1225 - [ssl] add directive for logging session ID #1164
Some notable changes are covered in separate blogposts: H2O version 2.2 beta released with TLS 1.3 support and other improvements, JSON logging support is added to H2O HTTP/2 server version 2.2.0-beta3.
Full list of changes can be found here.
The release also comes with the up-to-date version of mruby. Recently, a series of security defects have been reported for the language runtime. Our understanding is that many of the vulnerabilities rely on an attacker writing the script (a model that does not apply to how mruby is used in H2O). However, you can turn off mruby support by providing
-DWITH_MRUBY=OFF as an argument to CMake, or update mruby to the latest version simply by replacing the contents of deps/mruby with that of github.com/mruby/mruby.
Thursday, March 23, 2017
JSON logging support is added to H2O HTTP/2 server version 2.2.0-beta3
Today I am happy to announce the release of H2O HTTP/2 server, version 2.2.0-beta3.
Among the new features you will be finding in 2.2, in this blogpost I would like to talk about our support for JSON logging.
Traditionally, the log file format of HTTP servers have followed the tradition set by NCSA httpd more than twenty years ago. But the more we try to deal in various ways with the logs, the more it makes sense to use a standardized and extensible format so that we can apply existing tools to the logs being collected. Hence JSON.
Our support for JSON is a smooth evolution from the NCSA- (and Apache-) style logging. Configuration for a JSON logging will look like below.
Specifically, the behavior of the logger is changed to be:
The format may seem a bit verbose, but gives you the power to name the elements of a JSON object as you like, and to choose whatever format you want to use for compound values (e.g. the date, as shown in the example above).
When accessed by a client, a log line like below will be emitted for the above configuration.
If a string literal contains something more than just one format specifier, then the values are concatenated as strings to form a string literal. So
The other thing that is worth noting is that the substituted values will always be escaped as ISO-8859-1. It is the responsibility of the user to convert the string literals found in the log to the correct character encoding. Such conversion cannot be done at HTTP server level since it requires the knowledge of the application being run. I would like to thank @nalsh for suggesting the approach.
Among the new features you will be finding in 2.2, in this blogpost I would like to talk about our support for JSON logging.
Traditionally, the log file format of HTTP servers have followed the tradition set by NCSA httpd more than twenty years ago. But the more we try to deal in various ways with the logs, the more it makes sense to use a standardized and extensible format so that we can apply existing tools to the logs being collected. Hence JSON.
Our support for JSON is a smooth evolution from the NCSA- (and Apache-) style logging. Configuration for a JSON logging will look like below.
access-log:
path: /path/to/access-log.json
format: '{"remote": "%h:%{remote}p", "at": "%{%Y%m%d%H%M%S}t.%{msec_frac}t", "method": "%m", "path": "%U%q", "status": %s, "body-size": %b, "referer": "%{referer}i"}'
escape: json
The template specified by the format attribute uses the exact same specifiers as we use in NCSA-style logging. The only differences are that the non-substituted part of the template is JSON, and that another attributed named escape is set to json. The attribute instructs the logger to emit things in a JSON-compatible manner.Specifically, the behavior of the logger is changed to be:
- strings are escaped in JSON style (i.e.
\u00nn) instead of\xnn - nulls are emitted as
nullinstead of-
The format may seem a bit verbose, but gives you the power to name the elements of a JSON object as you like, and to choose whatever format you want to use for compound values (e.g. the date, as shown in the example above).
When accessed by a client, a log line like below will be emitted for the above configuration.
{"remote": "192.0.2.1:54389", "at": "20170322161623.023495", "method": "GET", "path": "/index.html", "status": 200, "body-size": 239, "referer": null}
One thing you may notice is that the value of the referer element is emitted as null without the surrounding double quotes that existed in the specified format. When escaping in JSON style, h2o removes the surrounding quotes if the sole value of the string literal is a single format specifier (i.e. %...) and if the format specifier evaluates to null. In other words, "%foo" evaluates to either a string literal or null, while %foo evaluates to a number or null.If a string literal contains something more than just one format specifier, then the values are concatenated as strings to form a string literal. So
"abc%foo" will evalutate to "abcnull".The other thing that is worth noting is that the substituted values will always be escaped as ISO-8859-1. It is the responsibility of the user to convert the string literals found in the log to the correct character encoding. Such conversion cannot be done at HTTP server level since it requires the knowledge of the application being run. I would like to thank @nalsh for suggesting the approach.
Tuesday, February 28, 2017
H2O version 2.2 beta released with TLS 1.3 support and other improvements
Today I am happy to announce the release of H2O version 2.2.0-beta1.
The release includes 20 changes made by 10 people. It is great to see that the development effort has become a joint work of such a community.
Below are some of the big changes that went into the beta release.
Case preservation of header names under HTTP/1 #1194
Since the release of H2O, we have always used lowercased header names. This is acceptable from the specifications' standpoint since header names are defined to be case-insensitive. Also, HTTP/2 only allows transmission of the names in lowercase.
However, in practice, there are applications that rely on the case of the header names being preserved by a reverse proxy. And it is technically possible to preserve the case of the characters in HTTP/1.
@deweerdt came up with a pull request that preserves the case of the header names whenever possible. As of this writing, case of the chacacters are preserved between the reverse proxy handler and HTTP/1 clients. Header names transmitted through HTTP/2 will continue to be in lower-case due to how they are encoded in HTTP/2.
Pull requests for preserving the headers communicated through other handlers are welcome.
Directives to modify request headers sent through the reverse proxy handler #1126
@zlm2012 has added configuration directives that can be used to tweak the request headers sent to the application server through the reverse proxy handler.
This has been implemented by refactoring and generalizing the headers handler that has been used to modify the response headers; so now it is possible to modify the request headers in any way that is possible to modify the response headers!
Support for TLS 1.3 draft-18 #1204
Our in-house implementation of TLS 1.3 (named picotls) has landed to master. Picotls provides an efficient (zero-copy) and clean-cut API (designed as a codec rather than an an I/O abstraction) for the upcoming version 1.3 of the TLS protocol.
Thanks to the library, H2O now implements all the features that is necessary to run TLS 1.3 in production and for performance; including support for session resumption, 0-RTT data, OCSP stapling.
Use of picotls is enabled by default; to disable it, set
Bug fixes thanks to code analysis #1174 #1110
@hbowden worked on integrating Coverity to H2O. The static analysis tool has found several issues and they have been fixed.
@jfoote and @deweerdt worked on integrating Google's continuous fuzzing to H2O. As a result of the integration, several issues were found and fixed in H2O.
The release includes 20 changes made by 10 people. It is great to see that the development effort has become a joint work of such a community.
Below are some of the big changes that went into the beta release.
Case preservation of header names under HTTP/1 #1194
Since the release of H2O, we have always used lowercased header names. This is acceptable from the specifications' standpoint since header names are defined to be case-insensitive. Also, HTTP/2 only allows transmission of the names in lowercase.
However, in practice, there are applications that rely on the case of the header names being preserved by a reverse proxy. And it is technically possible to preserve the case of the characters in HTTP/1.
@deweerdt came up with a pull request that preserves the case of the header names whenever possible. As of this writing, case of the chacacters are preserved between the reverse proxy handler and HTTP/1 clients. Header names transmitted through HTTP/2 will continue to be in lower-case due to how they are encoded in HTTP/2.
Pull requests for preserving the headers communicated through other handlers are welcome.
Directives to modify request headers sent through the reverse proxy handler #1126
@zlm2012 has added configuration directives that can be used to tweak the request headers sent to the application server through the reverse proxy handler.
This has been implemented by refactoring and generalizing the headers handler that has been used to modify the response headers; so now it is possible to modify the request headers in any way that is possible to modify the response headers!
Support for TLS 1.3 draft-18 #1204
Our in-house implementation of TLS 1.3 (named picotls) has landed to master. Picotls provides an efficient (zero-copy) and clean-cut API (designed as a codec rather than an an I/O abstraction) for the upcoming version 1.3 of the TLS protocol.
Thanks to the library, H2O now implements all the features that is necessary to run TLS 1.3 in production and for performance; including support for session resumption, 0-RTT data, OCSP stapling.
Use of picotls is enabled by default; to disable it, set
max-version property of the ssl configuration directive to tlsv1.2.Bug fixes thanks to code analysis #1174 #1110
@hbowden worked on integrating Coverity to H2O. The static analysis tool has found several issues and they have been fixed.
@jfoote and @deweerdt worked on integrating Google's continuous fuzzing to H2O. As a result of the integration, several issues were found and fixed in H2O.
Wednesday, January 18, 2017
H2O version 2.1.0 has been released
Hi, I am happy to announce that H2O version 2.1.0 has been released.
This major update has a long list of changes, but the introduction of the following features might be worth mentioning.
Also, there has been a lot of work done in the reverse proxy implementation to improve interoperability.
In the next major release, we plan to add support for TLS 1.3 as well as more knobs for logging. Stay tuned!
This major update has a long list of changes, but the introduction of the following features might be worth mentioning.
- TCP latency optimization (slide deck)
- response throttling
- various mruby scripts for fine-grained access control (please refer to the How-to section of the configuration document)
Also, there has been a lot of work done in the reverse proxy implementation to improve interoperability.
In the next major release, we plan to add support for TLS 1.3 as well as more knobs for logging. Stay tuned!
Monday, December 12, 2016
103 Early Hints に対応した Starlet 0.31 をリリースしました
Perl のウェブアプリケーションサーバである Starlet の新バージョン、0.31をリリースしました。
今回搭載された新機能は 100 番台の中間レスポンスの送信に対応した点です。
たとえば以下のような感じで 103 Early Hints レスポンスを送信することで、アプリケーションでリクエストを処理する前に、HTTP/2 リバースプロキシに関連アセットのプッシュの開始を指示することができます注。
Early Hints は、現在 IETF の HTTP WG で Call for Adoption を迎えている段階ですが、H2O version 2.1-beta のほか、nghttpx、Apache HTTP Server の HTTP/2 実装である mod_h2 の trunk などが既に対応しています。
今回搭載された新機能は 100 番台の中間レスポンスの送信に対応した点です。
たとえば以下のような感じで 103 Early Hints レスポンスを送信することで、アプリケーションでリクエストを処理する前に、HTTP/2 リバースプロキシに関連アセットのプッシュの開始を指示することができます注。
sub {
my $env = shift;
$env["psgix.informational"}->(103, [
'link' => '; rel=preload'
]);
my $resp = ... application logic ...
$resp;
}
Early Hints は、現在 IETF の HTTP WG で Call for Adoption を迎えている段階ですが、H2O version 2.1-beta のほか、nghttpx、Apache HTTP Server の HTTP/2 実装である mod_h2 の trunk などが既に対応しています。
注: HTTP クライアントによっては中間レスポンスの処理にバグを抱えている可能性があるため、Early Hints の使用はリバースプロキシを挟んでいる場合に限ることを現時点ではおすすめします。
Saturday, December 10, 2016
HTTP/2の課題と将来について、YAPC Hokkaidoで話してきた
スライドは以下になります。内容は先月のVelocity in Amsterdamでの発表と、それ以降のアップデートですが、スライドが日本語になっているので、日本人の方にはこちらのほうが良いかと思います。
HTTP/2の課題と将来 from Kazuho Oku
Tuesday, November 8, 2016
Wednesday, September 14, 2016
H2O version 2.0.4 / 2.1.0-beta3 released including a vulnerability fix
Today we have released H2O version 2.0.4 / 2.1.0-beta3, which includes a fix to a vulnerability (CVE-2016-4864).
Users of H2O are advised to update immediately.
For detail, please refer to the issue page at https://github.com/h2o/h2o/issues/1077.
Users of H2O are advised to update immediately.
For detail, please refer to the issue page at https://github.com/h2o/h2o/issues/1077.
Thursday, September 8, 2016
H2O version 2.0.3 / 2.1.0-beta2 released
I am happy to announce the release of H2O HTTP/2 server version 2.0.3 and 2.1.0-beta2.
Version 2.0.3 is a maintenance release fixing issues found since the release of 2.0.2.
Version 2.1.0-beta2 introduces many features in addition to those introduced in 2.1.0-beta1, including mruby-based DSL for access control and DoS mitigation.
Please let us know if you find any issues in the beta release. We plan to release final version of 2.1.0 pretty soon.
Version 2.0.3 is a maintenance release fixing issues found since the release of 2.0.2.
Version 2.1.0-beta2 introduces many features in addition to those introduced in 2.1.0-beta1, including mruby-based DSL for access control and DoS mitigation.
Please let us know if you find any issues in the beta release. We plan to release final version of 2.1.0 pretty soon.
Friday, June 24, 2016
H2O HTTP/2 server 2.0.1 / 2.1.0-beta1 released, with new features and performance optimizations
Today I am happy to announce the release of H2O HTTP/2 server version 2.0.1 and 2.1.0-beta1.
Version 2.0.1 is a bug-fix release of the 2.0 series. Existing users can upgrade to the new version to avoid the issues listed in the changeling.
Version 2.1.0-beta1 is the first beta release of 2.1, with a new throttle-response handler for per-response bandwidth throttling, and an enhancement to the status handler (pull #893). It also includes two new features that improve HTTP/2 performance: TCP latency optimization and support for
With TCP latency optimization, users can expect 1 RTT or more reduction in time-to-render if the main resource (i.e. HTML) is much larger INITCWND (typically ~15KB).
The reduction comes from the fact that with the optimization enabled, H2O tries to keep the amount of HTTP/2 frames kept unsent in the TCP send buffer very small (to just two packets) during the slow-start phase. Since the amount of data unsent is kept small, the server can switch to sending a resource that blocks the rendering path (e.g. CSS) immediately when it receives a request for such resource, instead of pushing the HTML body stored in the TCP send buffer. As CWND grows, the connection handling switches to bandwidth-optimization mode, that pre-fills more data into the send buffer so that the kernel can send additional data immediately after receiving ACKs without user-space intervention.
Support for
Use of informational response lets us use the time slot for pushing asset files. Application servers can now send an informational response with link rel=preload headers to H2O to start pushing the asset files, then perform heavy tasks, and send the final response. Use of 1xx response will not cause interoperability issues, since only the final response is sent to the client connected to H2O.
Details of the two optimizations were covered in my presentation at Tokyo RubyKaigi 11. The slides are shown below:
Version 2.0.1 is a bug-fix release of the 2.0 series. Existing users can upgrade to the new version to avoid the issues listed in the changeling.
Version 2.1.0-beta1 is the first beta release of 2.1, with a new throttle-response handler for per-response bandwidth throttling, and an enhancement to the status handler (pull #893). It also includes two new features that improve HTTP/2 performance: TCP latency optimization and support for
link: rel=preload headers in informational response (pull #916).With TCP latency optimization, users can expect 1 RTT or more reduction in time-to-render if the main resource (i.e. HTML) is much larger INITCWND (typically ~15KB).
The reduction comes from the fact that with the optimization enabled, H2O tries to keep the amount of HTTP/2 frames kept unsent in the TCP send buffer very small (to just two packets) during the slow-start phase. Since the amount of data unsent is kept small, the server can switch to sending a resource that blocks the rendering path (e.g. CSS) immediately when it receives a request for such resource, instead of pushing the HTML body stored in the TCP send buffer. As CWND grows, the connection handling switches to bandwidth-optimization mode, that pre-fills more data into the send buffer so that the kernel can send additional data immediately after receiving ACKs without user-space intervention.
Support for
link: rel=preload headers in informational response helps web developers utilize HTTP/2 push. Use of the link header is becoming the standard way to instruct HTTP/2 servers to start pushing assets. The downside of the approach is that application servers typically cannot send the header until it generates the final response. Generation of the final response often involves time-consuming operations such as access to the database, keeping the HTTP/2 connection idle for that period.Use of informational response lets us use the time slot for pushing asset files. Application servers can now send an informational response with link rel=preload headers to H2O to start pushing the asset files, then perform heavy tasks, and send the final response. Use of 1xx response will not cause interoperability issues, since only the final response is sent to the client connected to H2O.
Details of the two optimizations were covered in my presentation at Tokyo RubyKaigi 11. The slides are shown below:
Subscribe to:
Posts (Atom)