[B! security][http2] teppeisのブックマーク

HTTP/2 のコネクション再利用について確認してみる - ブログ・ア・ラ・クレーム

はじめに本記事は http2 Advent Calendar 2015 の 12 日目の記事となります。本記事では HTTP/2 における TCP コネクション再利用とその周辺仕様を確認してみようと思います。コネクション再利用の挙動を理解することは、実際の Web サイトにおける HTTP/2 のデプロイの助けになると思われます。 HTTP/1.1, HTTP/2 での TCP コネクション管理よく訓練された方々には既知のことかとは思いますが、 HTTP/2 において HTTP/1.1 の頃にあった性能向上の為のハックであるドメインシャーディングは好ましくないテクニックになってしまいます。 HTTP/1.1 において今日のブラウザは 1 ドメインあたり概ね 6 TCP コネクションほど張って、並列にリクエストを送るような振る舞いをします。このため Web サイトなどで参照するドメイン

teppeis 2017/05/18

リンク

これからドンドン使われていくSNIについて

SNIとは元々SSL通信は1つのIPアドレスに対して、1つの証明書が前提になっていました。というのもSSLでは暗号化されているため、1つのIPアドレスに対して複数の証明書を持っていた場合、リクエストが来たときにどの証明書を使えばいいか判断できないからです。しかしこれだとどう考えてもつらいことが分かります。昨今の流れとして常時SSL通信が当たり前の世界になりつつあります。すべてのドメインに対して全てのIPアドレスを用意するのは特にIPv4では現実的ではありません。そもそもHTTPではVirtual Hostを使って、1つのIPアドレスで複数のドメインのサイトを扱うことがとても一般的です。そこで有用なのがSNIです。SNIは最初の通信時に今から通信したいサーバーネームをサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。 SNIを使うことでHTTPのVirtual Host

teppeis 2017/05/18

リンク

HTTP/2とTLSの間でapacheがハマった脆弱性(CVE-2016-4979) - ぼちぼち日記

0. 短いまとめ昨晩apache2.4でHTTP/2利用時にTLSクライアント認証をバイパスする脆弱性(CVE-2016-4979)が公表され、対策版がリリースされました。実際に試すと Firefoxで認証バイパスができることが確認できました。 HTTP/2でTLSのクライアント認証を利用するには仕様上大きな制限があり、SPDY時代から長年の課題となっています。この課題を解決するため、Secondary Certificate Authentication in HTTP/2という拡張仕様が現在IETFで議論中です。 1. はじめにちょうど昨晩、apache2.4のhttpdサーバの脆弱性(CVE-2016-4979)が公開され、セキュリティリリースが行われました。 CVE-2016-4979: X509 Client certificate based authenticatio

teppeis 2017/05/18

リンク

TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説) - ぼちぼち日記

1. はじめに、 Googleがハマったシリーズ第3弾。今度は Chrome の脆弱性がテーマです。先日(8月12日頃）突然Google ChromeでSPDYの機能が一旦停止されました。CloudFareの人が気づいてspdy-devへのMLの問い合わせし、すぐGoogleのaglさんからの返事で計画的で一時的なものであることがわかりました。 twitterやfacebookもSPDYが全て使えなくなり非常に驚いたのですが、直後に Chrome の Stable/Beta/Dev チャンネルがアップデートされ、ほどなくして問題なくSPDYが使えるようになりました。この理由は公式には明らかにされていませんが、Chromeのリリースアナウンスにヒントがありました。そこには、 High CVE-2014-3166: Information disclosure in SPDY. Credi