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
SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど１年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
SSL/SPDYを攻撃するCRIMEはBEASTの正統な後継者だ
はじめに 以前のエントリでSSLに対する新しい攻撃手法「BEAST」を紹介しましたが、今回はBEASTをさらに発展させた「CRIME」という攻撃について簡単に紹介したいと思います。一次情報源としてこちらのスライド（英語）が閲覧できますので、時間がある方はぜひ目を通してみてください。 CRIMEの意味 CRIMEは "Compression Ratio Info-Leak Made Easy" あるいは "Compression Ratio Info-Leak Mass Exploitation" の頭文字で、SSLやSPDY（あるいはHTTPボディ部のgzip圧縮）で使われる圧縮アルゴリズムに注目した攻撃手法です。あまり知られていませんがSSLには圧縮機能が存在しており、サーバ側・クライアント側双方が圧縮機能をONにしている場合に、データが圧縮されます。 BEASTとの関係 CRIMEはB
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏:Geekなぺーじ
TOP > ブログ > HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏 昨年後半、IETFのhttpbisワーキンググループでHTTP 2.0標準化に向けた動きが開始されました。 そのhttpbisワーキンググループのチェアであるMark Nottingham氏(Akamai)に対するインタビューの機会を頂けました。 Mark Nottingham氏は、HTTP 2.0標準化の舵取りをしている方です。 非常に興味深い最新状況を伺えたので、可能な限り生に近い情報をお届けします(日本語に翻訳する前の英語版はこちら)。 お楽しみ頂ければ幸いです。 Q: HTTP 2.0標準化開始の経緯を教えて下さい HTTP 1.1とHTTP 1.0には、よく知られた制限があります。 特に顕著なのが、ひとつのコネクションでリクエストを出してレス
GmailがハマったSPDYの落とし穴 - ぼちぼち日記
1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY＆WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図１：2012年のハイプサイクル： 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo
SPDY の紹介と nginx で SPDY を使う方法 - HeartRails Tech Blog
HeartRails Tech Blog ハートレイルズのエンジニア、デザイナーによるブログです。 ウェブサービス、スマホアプリ、IoT デバイスの開発に関連する技術的な情報を発信していきます。 みなさん、はじめまして。昨年末に入社しました やまぎし という者でございます。Twitter 等はやっていない、ということにしておいてください。ともかく何卒よろしくお願いいたします。 さて、十数年もの間 1.1 のまま変わらず有り続けていた HTTP の規格ですが、この頃は新たな風が吹いており、HTTP/2.0 の存在が見えてきました。まだワーキンググループが発足したばかりであり、具体的に変わるのは当分先になるであろうとは思いますが、米 Google 社の提唱している SPDY が HTTP/2.0 に取り入れられる形が濃厚であろうと話されています。 SPDY は先述した通り米 Google 社が
SPDYと「やったー、net-http-spdyできたよー」の話 - I am Cruby!
SPDYを知るSPDYという実験的なプロトコルがありまして、 SPDY - The Chromium Projects HTTP2.0はSPDYをベースに作られるかも、みたいな話も風の噂で聞いたりするのでじゃあどんなもんかなあと仕様を読んで見ました。 SPDY Protocol - Draft 2 - The Chromium Projects SPDY Protocol - Draft 3 - The Chromium Projects SPDYv2とSPDYv3というのがあって、基本的にはSPDYv3の方を読んどけばいいのかなあとは思います。 ただSPDYv2もすでにいろんなところで使われていますので、仕様書の「7.Incompatibilities with SPDY draft #2」の部分もチェックしておきましょう。 HTTP Layering over SPDYSPDYというの
Adam Langley「CRIME attackの件」 - 以下斜め読んだ内容
ImperialViolet 2012.9.21のエントリ ImperialViolet - CRIME CRIME attackについて 現時点での対応 fxと若干違う対応してる点 今後のchromeでの対応プラン をchromeチームのエンジニアがざっくり書いてる spdy/4で完全対応なんだろうが、それまでのプランの具体的なところを知れてよかった 以下斜め読んだ内容 前から気になってた問題 spdyではsensitiveなデータをzlib使って圧縮するのが安全かどうか 掘り下げて検証する暇がなかった 自分と同じ心配をしてた研究者が他にもいた。ありがたい FirefoxチームとChromeチームにDuongとRizzoは事前に教えてくれた chromeチームが今回作ったパッチの話 その前にspdyがヘッダを圧縮する仕組みをおさらい zlibのやってることは一言でいうと このリテラルバイ
Adopting SPDY in Line – Part 1: An Overview « NAVER Engineers' Blog
We are constantly striving to improve the user experience of Line. Given the nature of Line as a communication tool, one way to do this is to reduce the time it takes to send and receive messages. Making the connection to our servers more efficient is one way to accomplish this. Until recently, Line had been using HTTP to transmit messages. HTTP, well known for its use in web browsers, has its str
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
