H2O version 2.2.6, 2.3.0-beta2 released, includes security fixes

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.

次世代プロトコル（QUIC etc.）のセキュリティとプライバシー @ #builderscon

９月６日より開催中の builderscon 2018 において、登壇の機会をいただき、インターネットのトランスポート層プロトコルについてセキュリティやプライバシーに関わる設計がどのように進めてられているか、TLS と QUIC を中心に発表しました。

QUIC のハンドシェイクプロトコルとパケット番号暗号化、TLS の Encrypted SNI 拡張は、いずれも僕が提案した機能あるいは方式が採用される予定のものなので、背景にある動機や意義を含め、整理して発表する機会をもらえたことをありがたく感じています。

聴講いただいた方々、また、スライドをご覧になる方々と、次世代プロトコルの暗号応用の手法のみならず意義を含め共有し、理解と議論を深めることができれば、これに勝る喜びはありません。



PS. QUIC のハンドシェイクプロトコルと Encrypted SNI 拡張については、以下のブログ記事もあわせてご覧いただけます。

QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
TLS の SNI 暗号化に関する Internet Draft を共同提出しました

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!

How happy they became with H2O/mruby and the future of HTTP from Ichito Nagata

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.

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.

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.

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.

• [core] add crash-handler.wait-pipe-close parameter #1092
• [core] introduce an option to bypass the server header sent from upstream #1226
• [access-log] add %{remote}p for 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-only attribute on link header #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 via request 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.

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.

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 null instead 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.

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 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.

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.

• 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!

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.

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.

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 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:

Developing the fastest HTTP/2 server from Kazuho Oku

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 how to use them.

Have fun!

H2O version 1.7.3 / 2.0.0-beta5 released with a vulnerability fix

We have just released version 1.7.3 and 2.0.0-beta5 of the H2O HTTP/2 server.

The releases include a fix for a security issue (CVE-2016-4817). Existing users are encouraged to update their installations.

The details of the issue can be found here.

We would like to thank Tim Newsham for reporting the issue and Frederik Deweerdt for providing a fix.

H2O HTTP/2 server 1.7.2 / 2.0.0-beta3 released

Today I have released H2O HTTP/2 server version 1.7.2 and 2.0.0-beta3.

The releases include an updated version of LibreSSL that fixes CVE-2016-2107; users of H2O built with the bundled version of LibreSSL are advised to update their installations.

In addition to the fix, 2.0.0-beta3 includes many new features and bug fixes.

Especially, support for reverse-proxying over HTTPS (#875) and the new configuration directives for tweaking environment variables passed to FastCGI (#868) might be helpful to the users who have wanted them.

We plan to release the final version of 2.0 soon, and then proceed to optimizing the server even further. Stay tuned!

H2O version 2.0.0-beta2 released, with a new "status" handler

Today I am happy to announce the release of H2O HTTP/2 server version 2.0.0-beta2.

The release comes with the new status handler that shows the HTTP requests in-flight. Now, you can monitor what's going on inside H2O!

Some notable features are:

• both HTTP/1 and HTTP/2 requests are shown
• HTTP/2 priorities are shown
• the screen can be updated automatically by clicking the Refresh checkbox

Under the hood, the status is served via a JSON API (lib/handler/status.c L169), and rendered by a static HTML document(share/h2o/status/index.html). So it would be easy for anyone to extend the status or retrieve and use the status from another program.

The documentation of the status handler can be found here.

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, with the exception of /robots.txt and /favicon.ico being served statically.

paths:
  /:
    fastcgi.connect:
      port: /tmp/fcgi.sock
      type: unix
  /robots.txt:
    file.file: /path/to/robots.txt
  /favicon.ico:
    file.file: /path/to/favicon.png

Pretty straight forward, isn't it?

For details, please refer to the updated documentation of paths directive, or refer to the discussion in the pull request.

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 added support for Brotli in Firefox 44, and Chrome is gradually turning the knob on as well.

Starting with H2O version 2.0.0-beta1, when the file.send-compressed directive is set to ON, the server sends a file with .br or .gz suffix instead of file being requested should such file exist. For example, if index.html is requested with a Accept-Encoding: br request header, and if a file named index.html.br exists, the server sends the contents of index.hmtl.br as the response with the Content-Encoding: br response header being set. In case the client is capable of decompressing both algorithms both algorithms and if both of .br and .gz files exist, the .br file is selected as the response.

# send pre-compressed files (.br or .gz)
file.send-compressed: ON

The other directive: compress controls on-the-fly compression. When turned on, it compresses the response as it is being sent to the client, using either brotli or gzip depending on the configuration and browser support. This can be used for compressing output from PHP and other dynamically-generated content.

# perform on-the-fly compression (brotli or gzip)
compress: [ brotli, gzip ]

Server administrators may also be interested in fine-tuning the compression quality of the compression methods. The following configuration sets the compression quality of brotli to 4 and gzip to 6, a suggested setting by Understanding Brotli's Potential - The Akamai Blog. The compression speed becomes about half of the default (1 for both gzip and brotli), but the size of the content after compression is expected to become ~15% smaller for both methods.

# perform more effective (but CPU-intensive) compression
compress:
  brotli: 4
  gzip:   6

In my upcoming blogposts I will cover other changes in the 2.0 release of H2O. Stay tuned!

H2O version 1.7.1 released

Today we have shipped version 1.7.1 of the H2O HTTP/2 server.

It includes several bug fixes and stability improvements from 1.7.0. Users of existing versions are recommended to upgrade to 1.7.1.

Please refer to the Changelog of 1.7.1 for details.