4/30/2015

VarnishのSSL再考

VarnishでSSL/TLSをサポートするかの検討話

Hacker News

4年前、私はなぜVarnishがSSLをサポートしないのかについて文句を書いたが、次のリリース4.1がその問題を再考する上でのうまい口実になる。

SSL/TLSライブラリ

2011年、私は悪夢だとしてOpenSSLのソースコードを批判した。言いたくはないが、そう言ったでしょ、そう言ったでしょ: "HeartBleed"参照

良いニュースはHeartBleedが人々はFOSSメンテナーもローンやお腹を空かした子供がいるんだと実感したということだろう。

重要な基盤ソフトウェアを睡眠不足や荷重労働で日曜日夜の11〜12時にメンテナンスすることや、来月の支払いを心配しなければならないのをやめさせるために、いろいろな取り組みが始まった。

我々はまだそうではないが、確実に良くなりつつある。

しかし、TLS/SSLの実装は、まだむちゃくちゃに複雑だ。エドワード・スノーデンの内部告発のおかげで、我々は偶発的な事故は起きないと信じる極めて十分な理由がある。

優れたTLS/SSLの実装を探し出す課題は相変わらずで、使いたいと思う実装がまだ見つかっていない。

OpenBSDのLibreSSLは確かに正しい方向性へのステップだが、長い目で見ないと潜在能力があるかどうかわからないだろう -- 彼らは「変人」的傾向がある -- 考えがまとまっていない。

証明書の取り扱い

私はまだそれをする方法が分からない。Varnishのワーカープロセスは、暗号レベルで互いに影響の出ないようにするビットが作られていないし、重要な仕事ができていない。

しかし、新しい抜け穴がある。ある夜、オスロ空港で家に帰る飛行機を待っていた時、何かないかを確かめるため、TLS/SSL全体のハンドシェークプロセスに考えを巡らせた。そして、私は証明書を保持することなくTLS/SSLを終了できることに気付いた。

次の朝、CloudFlareは全く同じことを発表した

これがもしかしたら、もっとも重要な暗号ビットに近づかないようにしながら、Varnishワーカープロセスの中でTLS/SSLを終了する方法かも知れない。

しかし、まだまずい考えだ

これを書いている時、合計3億5000万ダウンロードされたアプリがSSL/TLSの中間者攻撃に脆弱であるというニュースがあった。

コードは難しい、4倍難しいと言わないまでも、暗号コードは2倍以上難しい。そして、世界は暗号学でいい加減な仕事をする別のコードを必要としていない。

私あるいは他の誰かでもVarnishにSSL/TLSを実装したなら、世界に進んでコードを提示するのに少なくとも半年は議論するだろう。

タイムマシンの仕組みを得るまで、半年間は他のVarnishの開発を片付け、その成果はそれだけの価値がある方がいい。もし、それができないなら、「私も!」という理由にはならない全体の攻撃対象やバグの可能性を増大させるだけだ。

私は、Willy TerreauのHAProxyのようなものを考えていたので、私が改善のための重要な好機を見いだすのはなかなか難しい。

結論

VarnishはまだSSL/TLSのサポートを追加しない。

代わりにVarnish 4.1では、HAProxyのようにSSL終端プロキシーから別の細目を通信可能にするWillyのPROXYプロトコルのサポートを加える。

セキュリティの観点から、これはVarnishに統合されるSSL/TLSを持つよりもとても良い解決法でもある。

選択されたSSL/TLSプロキシーが内在するソフトウェアバグの可能性によって、セキュリティ侵害されると、Varnishの利益を全て失わずに別のプロキシーを選択できる。

そのようなアイデアは「ソフトウェアツール原理」と呼ばれ、とても古いアイデアだが、まだベストの一つである。

ポリティカルなあとがき

私は上記が、進行中の「どこでもSSL」という政治情勢を考慮に入れると、とても変わった宣告だということに気づいている。

私は「どこでもSSL」というアイデアについて、多くの理由からあまりワクワクしていない。

最も明白な例は、もし、ウェブサイトが自然災害を乗り切ろうとする人々であふれてしまったら、SSL/TLSプロトコルのネゴシエーションで国の民間防衛機関をダウンされたくはない。

次の大きい問題は、プライバシーの権利を持たない人々がいることだ。多くの国々では、これは子供、囚人、株トレーダー、飛行管制官、第一応答者などなどだ。

「どこでもSSL」は、記録や調査の法的要求事項に応じるためにインターネットの接続性をブロックしたり中間者攻撃プロキシーを強要することを公的機関で推し進めるだろう。私の見立てでは間違った方向性向かっている。

しかし、私が「どこでもSSL」に対して持っている大きな問題の一つは、少なくともそれにふさわしいと考える関係者にプライバシーを与えるということだ。

何度も何度も国境を越えた怪しい行動があり、従って法律が無視され、会社がtcpdump、snortあるいは同じようなトラフィックキャプチャプログラムを実行するセキュリティ調査員(あるいは単なる愉快犯)によって危険な状態になっているし、続けられている。

法律や制限に反して我々の意志に反して、ウェブを横断するユーザを追跡するのに使われる特異な「魔法のクッキー」を覚えているだろうか?

まさに平凡なパケットトレースで暴露されてしまう。

「どこでもSSL」で、これらの関係者は、プレーンテキストのHTTP接続よりもSSL接続を調べるには更に多くのスキルを必要とするため、インターネットに繋がる全ての人間のプライバシーを侵害するために更にプラバイシーを得ようする。

最高裁判官ブランダイスは「日光は最も良く殺菌するものである」と書いた。「どこでもSSL」は陰の中に全てのトラフィックを置いてしまう。

ポール・ヘニング, 2015-04-28

4/29/2015

AWS Summits 2015

AWSサミット2015 - ロンドン」セッションの記録と資料。

4/28/2015

Googleの内部関係者、なぜGoogle+が失敗したのか

Slashdotから。

先月、GoogleはGoogle+の戦略変更を発表した。Facebookに対抗することを目的としていたソーシャルネットワークとしてGoogle+を売り込むことに見切りをつけた。その代わり、Google+は二つの単独のアプリ、PhotosとStreamsになる。これは、驚くべきことではない。Google+は、Facebook、TwitterあるいはLinkedInのようなソーシャルネットワークのようには少しもヒットしなかった。GoogleがGoogle+の方向性を変更するという噂がここ数ヶ月渦巻いていた。ビジネス・インサイダーは、人々がオンラインチャットを共有する方法を変えると信じていた内部で何が起こったかについて数人の内部関係者に取材をした。ある内部関係者は、Google+はラリー・ペイジには本当に重要だった - 彼は個人的に会社全体を巻き込みたいと考えていた、と語った。元Google社員は、Google+の最大の問題はFacebookにあまりにも似た事をしようとしたことだと語った。別の元社員は同意し、マーケットに出すのが遅かったし、「競争という観点」が動機だったと語っている。

4/26/2015

OS Xのセキュリティは抜け道あり

Appleは、OS XにはGatekeeperやXProtectのようなセキュリティ機能が搭載されているので、マルウェアに強いと宣伝しているが、Synackの研究者Patrick Wardle氏は、OS Xのセキュリティコンポーネントを迂回する方法をRSAカンファレンスで発表している(PDF)。例えば、Gatekeeperはアプリのデジタル署名の検証を行い、ユーザの設定に基づき、それがApp Storeのみ許可する設定なら、App Storeからダウンロードされたアプリのみが実行され、他はブロックされるような機能である。ところが、「Gatekeeperはアプリ内のエクストラコンテンツを検証しない。そのため、Apple承認のアプリを手に入れ、外部コンテンツをロードすると、ユーザはそれを実行できてしまう。すなわちGetekeeperを迂回できる。アプリケーションパッケージのみを検証しているためだ」とのこと。さらに氏は「Mac上のセキュリティツールを迂回できることは、どんなアタッカーにとっても自明だ」とまで言っている。

Slashdot

4/23/2015

ディズニー映画、2017年までの公開リスト

ディズニーは、ピクサー、マーベル、ルーカスフィルムを抱える巨大な映画会社になった。CinemaConで2017年までの映画リストが公表された(Geektyrant)。かっこ内が日本公開日。

  • アベンジャーズ/エイジ・オブ・ウルトロン – 5/1/15 (7/4/15)
  • トゥモローランド – 5/22/15 (6/6/15)
  • インサイド・ヘッド – 6/19/15 (7/18/15)
  • アントマン – 7/17/15 (9/19/15)
  • ブリッジ・オブ・スパイズ – 10/16/15
  • ザ・グッド・ ダイナソー – 11/25/15
  • スター・ウォーズ/フォースの覚醒 – 12/18/15 (12/18/15)
  • The Finest Hours – 1/29/16
  • ズートピア – 3/4/16
  • ジャングル・ブック – 4/15/16
  • キャプテン・アメリカ/シビル・ウォー – 5/6/16
  • Alice Through the Looking Glass (鏡の国のアリス) – 5/27/16
  • ファインディング・ドリー – 6/17/16
  • The BFG (オ・ヤサシ巨人BFG) – 7/1/16
  • Pete’s Dragon – 8/12/16
  • ドクター・ストレンジ – 11/4/16
  • Moana – 11/23/16
  • スター・ウォーズ・アンソロジー/ローグ・ワン – 12/16/16
  • Beauty and the Beast (美女と野獣) – 3/17/17
  • Ghost in the Shell (攻殻機動隊) – 4/14/17
  • ガーディアンズ・オブ・ギャラクシー2 – 5/5/17
  • スター・ウォーズ/エピソード8 – 5/26/17
  • トイ・ストーリー4 – 6/16/17
  • パイレーツ・オブ・カリビアン5/Dead Men Tell No Tales – 7/7/17

4/19/2015

Airconsole

ルータやスイッチのコンソールはUSBシリアル内蔵タイプも増えてはいるが、シリアルポートのみ主流である。PCはUSBシリアルアダプタを用意すればいいが、タブレットやスマートフォンに対応しているものは少ない。そういう時のために、Wi-Fi/Bluetoothを使ってコンソールを接続するアダプタ「Airconsole」が面白そうだ。Standard($79)、Pro($110)、XL($139)の3つのタイプがあり、XLはバッテリーサイズが大きくなっている。Android/iOS向けのターミナルアプリを使ってスマートフォンやタブレットで利用できる。また、有線LAN/WiFiのブリッジ機能、DHCPサーバ機能なども用意されている。

NSONE: データ駆動型DNS

NSONEは、場所、接続性、プライオリティ、トラフィック、負荷、費用(データセンター、CDN)、遅延・スループットなどを元に、ユーザからのIPアドレスの問い合わせに答えるデータ駆動型DNSサービスを展開しているようだ。CDN会社のグローバルロードバランサのようなことを一般に適用した感じだろうか。

ipSpace

4/17/2015

Cisco ASR9000のRSP2のディスクの空き容量

Cisco Support Communityに、Cisco ASR9000のRSP2のディスク(ブート用)の空き容量の管理について掲載されていた。ディスク容量は2Gだが、なぜか1.6G/0.4Gの2つにパーティションが切られていて、1.6Gの方しか使えないため(0.4Gが無駄になっている)、空き容量によってはアップグレードができない恐れがある。そのため、次の方法で回避する必要があるとのことだ。

  1. ディスクの再パーティション(これが推奨)
  2. フレキシブル・ディスク・インストール (IOS XR 4.3.4以降から利用可能)
  3. RSP2をリベイク(RSPを1枚づつ交換していく)
  4. Turboboot (これは最後の手段)
  5. RSP-880、RSP-440、RPS-LITEに移行する

推奨されている再パーティションは、IOS XR 4.2.0からヒットレスのSMU(CSCub41271)をインストールすることで利用できる(4.2.3からデフォルトで入っている)。ツールをインストールしたら、CSCub41271のドキュメントにあるように、「run repart -d」を実行するだけ。およそ、90分ほどかかるが、disk0→disk1にミラーをし、再パーティション後に戻すということを実行している。再パーティションの結果、1.9G/0.1Gとなるので、300MBほど増量される。

4/16/2015

Google、Microsoftの失速点と成長

Googleが、Microsoftのように失速するのはいつになるのかという話。Microsoftでもそうだったが、ほとんどの成熟したテック企業は成長が止まると、衰退を避けることはできない。その議論には5つのポイントがあるとのこと。

  1. 株式報酬(ストックオプション)が輝きを失う
  2. マイナス成長
    成長が10%を下回ったテック企業は再成長することは稀(Appleは例外)。
  3. イノベーションのためではなく、リスク管理のための雇用
    テック企業が成長すると、イノベーションを停止してしまう(イノベーターを雇用することを渋る)
  4. コアビジネスへの価格と利益の圧力
  5. 政府の行動
    1998年から2001年までMicrosoftが独占禁止法に悩まされ、ライバルが成長したように、Googleにもそれが起きている(EUが独占禁止法違反の対象となった)

Hacker News

4/13/2015

HTTP/2解説 (http2プロトコル)

ダニエル・スタインバーグ氏のHTTP/2解説書の超訳。第6章のhttp2プロトコル。

6. http2プロトコル

歴史や政治的な背景はここまでにする。それでは、プロトコルの仕様に飛び込んでみよう。まず、http2を作成する上でのこまごました考え方を説明する。

6.1. バイナリ

http2はバイナリプロトコルである。

一瞬で十分に理解させよう。前からインターネットプロトコルに関わっている人なら、おそらく、これに対して本能的に強く反応するだろう。反論する根拠として、text/asciiで作られたプロトコルが如何に便利か、そしてあなたが何度もサーバにtelnetして手でリクエストを入力してきたかを詳しく説明するだろう。

http2は簡単にフレーミングできるようバイナリである。実際は一般的なテキストベースのプロトコルやHTTP 1.1で、複雑なものの一つはフレームの始まりと終わりだと理解してほしい。任意で入れられる空白、同じことを書くのに色々な書き方があることから移行することで、実装がよりシンプルになる。

また、HTTP1では紛らわしいほど混在していたフレーミングからプロトコル部分を切り離すことがとても簡単になる。

プロトコルが圧縮機能を持つことや、ほとんどがTLSとなる通信では回線上でテキストが読めなくなるため、テキストの価値を減少する。http2でプロトコルレベルで何が流れているかを把握するには、Wiresharkなどのツールを使うことに慣れる必要がある。

プロトコルのデバッグは、curlのようなツールを使ったり、Wiresharkのhttp2 dissector などでネットワークストリームを解析したりすることが必要になる。

6.2. バイナリフォーマット

http2はバイナリフレームを送信する。送信されるものには異なるフレームタイプがあり、タイプ、長さ、フラグ、ストリーム識別子、フレームペイロードと全て同じ構造を持つ。http2の仕様の中では10のフレームが定義されており、HTTP 1.1の機能でいうところのDATAとHEADERSに相当する2つのフレームがもっとも重要なものとなる。このあと、より詳しくいくつかのフレームを説明する。

6.3. 多重ストリーム

http2で送信される各フレームにあって、前節のバイナリフォーマットで説明したストリーム識別子は、ストリームに関係付けられる。そして、クライアントとサーバ間で交換されるフレームの双方向シーケンスはそれぞれ独立している。

(写真)

一つのhttp2接続は、複数のストリームからエンドポインドのインターリービングフレームでも、複数同時にストリームをオープンできる。ストリームが確立され、一方向で使われる、あるいはクライアントかサーバのどちらで共有され、どちらかのエンドポイントからでもクローズできる。ストリームの中で送られるフレームの順番が重要である。

多重ストリームというは、たくさんのストリームが同じ接続で混在されパッケージ化していることを意味する。2つ以上の個々のデータ列が一つのストリームとなり、向こう側で再び分割される。ここに2つの列車がある。

(写真)

そして、それらは多重化の慣習で同じ接続の中に詰め込まれる。

(写真)

http2で、数十から百程度の同時ストリームに気付くだろう。そのため、新しいストリームの作成負担は非常に低くなる。

6.4. プライオリティと依存性

各ストリームはプライオリティを持ち、相手先に伝えられ、そのストリームが重要だと見なされる。

プロトコルの中でどのようにプライオリティが働くかの詳細は、数回変更され、まだ議論されている。要するにクライアントがどのストリームがもっとも重要かを指定でき、依存関係のパラメータがあって、一つのストリームは別のストリームに左右される。

プライオリティは実行中に動的に変更でき、ユーザが画像全体のページをスクロールダウンする際に、どのイメージがもっとも重要かを指定することをブラウザが可能になる。あなたがタブを切り替えたら、ストリームの新しいセットが優先付けされ、いきなりはっきり見えるようになる。

6.5. ヘッダ圧縮

HTTPはステートレスなプロトコルである。簡単に言えば、全てのリクエストは、サーバが前のリクエストの情報やメタデータを保持せずに、サーバがリクエストを処理するのに必要となるだけの情報が必要となる。http2はその枠組みを変更していない。それもまた取り入れている。

これはHTTP繰り返しになる。ウェブページにある画像のようにクライアントが同じサーバから多くのリソースを要求する時、全てが全く同一の巨大な連続したリクエストになる。ほとんど同一の連続したリクエストは時には圧縮が強く求められる。

私が以前述べたように、ウェブページ毎のオブジェクト数は増加している上に、クッキーの利用やリクエストのサイズも徐々に増加している。クッキーも全てのリクエストに含まれる必要があり、普通は多くのリクエストで同じである。

HTTP 1.1のリクエストサイズは実際に徐々に大きくなっており、時には初期TCPウィンドウよりも大きくなっている。そのため、リクエストを全て送ってしまう前に、サーバからACKを返す必要があり、それらを送るのにとても遅くなってしまう。圧縮を支持するもう一つの意見である。

6.5.1. 圧縮は扱いにくい題材である

HTTPSとSPDYの圧縮機能は、BREACHCRIME attackで脆弱性があることが見つかった。ストリームの中にテキストを挿入することで、出力がどのように変化するかが分かるので、攻撃者は何が送られたかを解読することができる。

これらの攻撃の一つでも脆弱にならずにプロトコルで動的コンテンツを圧縮するのは、考察と熟慮が要求される。これはHTTPbisチームがやろうとしたことである。

HPACKというHTTP/2のヘッダ圧縮では、http2ヘッダをとりわけ巧妙に作られた圧縮フォーマットで、別のインターネットドラフトで規定され、厳密にやり取りされる。新しい形式(別のカウンタと共に)は、この圧縮をエクスプロイトすることが難しくなるように、特定のヘッダやフレームの任意のパディングを圧縮せずに中間者に尋ねるビットのようなものを調整する。

HPACKの作者の一人であるRoberto Peon氏の言葉を借りると、HPACKは情報をリークする適合実装が難しくなる、とても速く安価でエンコード/デコードできる、受け手が圧縮したコンテキストサイズを制御できる、プロキシー再インデックスを許可する(例えば、プロキシーの中でフロントエンドとバックエンドの間で状態を共有)、そしてハフマンコードで文字列を高速圧縮するよう設計された。

6.6. Rest - 考え方を変更

HTTP 1.1が持つ欠点の一つは、HTTPメッセージがあるサイズのContent-Lengthで送れた時、それを簡単に止めることができないという点である。時々TCP接続が切断するが(常にではないが、ここではなぜかの長ったらしい理由は飛ばすことにする)、再び新しいTCPハンドシェイクをネゴシエートする必要が生じてしまう。

あなたは、むしろ単にメッセージを停止する方を選び、新しく開始する。これは、http2のRST_STREAMフレームで行うことができる。バンド幅が無駄になるのを防ぐのに役立ち、接続を壊す必要性を取り除ける。

6.7. サーバプッシュ

これは「キャッシュプッシュ」として知られる機能である。ここでのアイデアは、もしクライアントがリソースXを要求すると、サーバはクライアントがリソースZを欲していることを知り、その要求が無くてもクライアントに送信する。キャッシュの中にZを置くことでクライアントを助け、要求があった時に、そこにあるようにする。

サーバプッシュは、たとえクライアントがそれを実行しても、クライアントは明示的にサーバを許可しなければならない。特定のリソースを欲していないなら、自らの選択でRST_STREAMでプッシュされたストリームを早急に終了できる。

6.8. フローコントロール

http2の個々のストリームは、相手方がデータ送信を許可するフローウィンドウを自身で広告する。もし、あなたがどのようにSSHが働くかを知っているなら、これはスタイルと精神(style and spirit)でとてもよく似ている。

入方向データに適合するようたくさんの部屋を持つ必要があるため、双方の全てのストリームは相手に伝えなければならない。そして、相手方はウィンドウが拡張されるまで、多量のデータを送ることを許可するしかない。データフレームのみでフロー制御される。

4/11/2015

IPv4アドレス市場の活発化

Dun Researchが、IPv4アドレス市場が活発になってきたが、売買に伴う新たな問題が起きていると指摘している。RIPEの移転表を見ると、去年あたりから急激に伸びていることが分かる(2014年11月には2百万のアドレス移転が行われている)。IPv4アドレスのブローカーV4EscrowのElvis Velea氏に移転市場について聞いたところ、移転価格はアドレス1個$9〜$11とのことだ。そして、移転の活発化は、ブロックの切り売りにつながり、そのためにルーティングのトラブル(ハイジャック)やルーティングテーブルの増大を招く恐れがある。

Hacker News

4/05/2015

20年前、初のIPv6相互接続に成功

v6opsメーリングリストによれば、今から20年前(1995年3月30日)に2つの独立したIPv6実装、sipper.pa-x.dec.com(DEC OSF/1)とottawa.inria.fr(NetBSD)間の接続に成功したそうだ。

4/02/2015

HTTP/2採用の状況と割合

HTTP/2の仕様はIETF draft-17の段階で実装も進んでおり、ダニエル・ステンバーグ氏のブログによれば2月時点でウェブトラフィックの5%以上はHTTP/2だとのことだ。氏が、現在のHTTP/2の実装状況をまとめている。

ブラウザ

  • FirefoxとChromeでサポート
  • Internet Explorerはテクニカルプレビューで利用可能なので、まもなく公式リリース
  • Safariは不明(Yosemite、iOS 8ではSPDYをサポート)

サーバ

  • Apache HTTPdのmod_h2でHTTP/2が利用できるが、まだアルファ状態
  • Nginxは2015年中にHTTP/2をサポートすると表明
  • IISはWindows 10テクニカルプレビューでHTTP/2を誇示
  • H2Oは新参者でパフォーマンスにフォーカスを当てている、既にしばらく前にHTTP/2をサポート
  • nghttp2は、古いサーバのフロントに置くHTTP/2=>HTTP/1.1プロキシーを用意
  • Apache Traffic ServerはHTTP/2をサポート、リリースはまもなく
  • nettyjettyなども既にサポート

プロキシー

サービス

  • Google(Youtubeなども含む)やTwitterはHTTP/2が利用可能
  • すでに多くのサービスがSPDYをサポートしていることから、そんなに間を置かずにHTTP/2にスイッチするものと思われる

CDN

非ブラウザクライアント

Hacker News