Let's EncryptがはまったGolangの落とし穴 - ぼちぼち日記
0. 短いまとめ 300万以上の証明書の失効を迫られたLet's Encryptのインシデントは「Golangでよくある間違い」と書かれているようなバグが原因でした。 1. はじめに、 Let's Encryptは、無料でサーバ証明書を自動化して発行するサービスを行う非営利団体として2014年に設立されました。 2015年にサービス開始されると証明書の発行数はぐんぐん伸び、先月末のプレスリリースでは累計10億枚のサーバ証明書を発行したことがアナウンスされました「Let's Encrypt Has Issued a Billion Certificates」。CTLogの調査から、2020年2月末の時点では有効な全証明書の38.4%がLet's Encryptの証明書であるとみられています「Certificate Validity Dates」。 無料の証明書を提供してもらえるのは非常に嬉し
ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS, Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
HTTP/2時代のバックエンド通信検討メモ - ぼちぼち日記
1. はじめに、 今朝、こんな返事を元に kazuho さんとIPsec/TLS等バックエンド通信について議論する機会を得ました。 せっかくだから現時点での自分の考えを整理してメモとして残しておきます。 普段ちゃんとしたストーリをもったエントリーしか書いていないのですが、今回は時間がないのでちゃんとした論理的文章になっていないメモ程度のものです、あしからず。 以下、フロント側に HTTP/2 を導入した場合のバックエンド通信をどう考えるかのメモです。 2. 性能的観点 フロントにHTTP/2を導入したということは、ブラウザのHTTP HoLブロック解消が目的の一つだと思う。HTTP/2の多重化通信によってクライアントからこれまで以上の同時リクエストをさばかないといけない（だいたい初期値は同時100接続ぐらいに制限されていると思う）。 他方バックエンド側通信は、クライアント側がブラウザではな
OpenSSLの脆弱性(CVE-2015-1793)によるAltチェーン証明書偽造の仕組み - ぼちぼち日記
TL;DR やっぱり書いていたら長文になってしまいました。あまりちゃんと推敲する気力がないので、変な文章になっているかもしれません。ご了承いただける方のみお読みください。 1. はじめに 昨晩未明にOpenSSL-1.0.2d, 1.0.1pがリリースされました。事前に予告されていた通り深刻度高の脆弱性CVE-2015-1793が修正されています。Advisoryを見ると、この脆弱性がiojs/Nodeに影響があるということが判明したので直ちにiojs/Nodeのアップデートを行い、今朝未明に無事脆弱性対応版をリリースしました。 今回が初めてではありませんが、深夜に日欧米のエンジニアがgithub上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア
華麗なる因数分解:FREAK攻撃の仕組み - ぼちぼち日記
1. はじめに ちょうど今朝 OpenSSLをはじめとした様々なTLS実装の脆弱性の詳細が公表されました。 この InriaとMSRのグループは以前からTLSのセキュリティに関して非常にアクティブに調査・検証をしているグループで、今回も驚きの内容でした。 このグループは、TLSのハンドシェイク時の状態遷移を厳密にチェックするツールを開発し、様々なTLS実装の脆弱性を発見・報告を行っていたようです。 特にFREAKと呼ばれるOpenSSLの脆弱性(CVE-2015-0204)に関しては、ちょうど修正直後の1月初めに Only allow ephemeral RSA keys in export ciphersuites で見ていましたが、具体的にどのように攻撃するのかさっぱりイメージできず、あのグループだからまた超絶変態な手法だろうが、まぁそれほど深刻じゃないだろうと見込んでいました。 今回
Node-v0.10.34がはまったクロスルート証明書とOpenSSLの落とし穴 - ぼちぼち日記
既に12月22日ですが、このエントリーは、Node.js Advent Calendar 2014の13日目のエントリーです。 いや私が書くの遅れたわけじゃないですけど…(言い訳)、ちょうどタイムリーなネタがあるので、先日リリースされたNode-v0.10.34で発生した（現在も継続している）問題について携わった経緯を自分の目線で書いてみます。 追記：日本時間の12/24にNode-v0.10.35がリリースされました。 http://blog.nodejs.org/2014/12/23/node-v0-10-35-stable/ 本記事の不具合も修正されています。 1. Node-v0.10.34リリース直後にissue発生 先週12/17にNode v0.10.34 (Stable)がリリースされました。10月中旬にPOODLE騒ぎでOpenSSLに対応した Node-v0.10.33
Service WorkerとHTTP/2が切り開く新しいWeb Pushの世界 - ぼちぼち日記
この記事は、HTTP2 Advent Calendar 2014の6日目のエントリーです（2日前にフライイング公開してます）。 1. はじめに、 HTTP/2仕様の標準化作業は、WGラストコールも終わり、今後IESGレビューやIETFラストコール等の大詰めの段階に来ました。来年のRFC化に向けてまだまだ予断を許しませんが、プロトコル設計自体の作業はほぼ完了し、後はすんなり行くことを祈るばかりです。 こんな状況なのに気が早いですが、もう既に標準化後を見据え、HTTP/2の機能を使った新しい仕組みを作る動きが始まっています。 そこで今回はHTTP/2技術の応用として、HTTP/2の「サーバプッシュ機能」と今ホットなブラウザの新技術「Service Worker機能」を組み合わせた次世代のプッシュ機能「Web Push/Push API」について書いてみたいと思います。 ただ、個人的に色々タスク
Node.js-v0.10.28でDate.now()が爆速になった - ぼちぼち日記
1. Node-v0.10.28とNode-v0.11.13のリリース 先週末、安定版のNode-v0.10.28と開発版のNode-v0.11.13がリリースされました。*1 次の0.11.14が0.11系の最後となる予定とアナウンス。そう、次々はいよいよNode-v0.12です。 安定版の0.10系は、基本バグフィックスなどが中心のリリースですが、今回 deps: make v8 use CLOCK_REALTIME_COARSE のような修正が入りました。Node-v0.10のV8でLinux向けにNode固有の性能向上パッチが適応されたようです。 CLOCK_REALTIME_COARSEとはどのようなものでしょうか？ RedHatのドキュメント「15.2.1. CLOCK_MONOTONIC_COARSE と CLOCK_REALTIME_COARSE」では、 カーネルへのコンテ
Node.js-v0.10リリースアナウンスの簡単な解説と感想など - ぼちぼち日記
1. はじめに、 昨年6月末に node-v0.8がリリースされて8か月半ほど経って node-v0.10 がリリースされました。私もいくつかパッチがこのリリースに採用されていまして、ちょっと感慨深いです。 当初1月末のリリース予定でしたが、やっぱり今日まで延びました。安定版リリース直前のゴタゴタはもうNodeの風物詩なんですね。 今回、Node-v0.10のリリースにあたり、 isaacs から次のリリース文 http://blog.nodejs.org/2013/03/11/node-v0-10-0-stable/ がポストされています。英語かつ長文なので内容をちゃんと読み切れな方もいらっしゃるかと思いますので、リリース文の項目にあわせて私の視点で簡単な解説と感想などを書いてみます。（ちゃんとリリース文を理解された方はわざわざお読みにならなくても大丈夫です。） 尚、このリリースはこれ以
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
FacebookがSPDYを始めました！ - ぼちぼち日記
1. SPDYが熱いです！ ちょうど先週末CROSS2013の 次世代Webセッション(プロトコル編) にパネラーとして参加させていただきました。 次世代Webの鍵となるWebSocket・SPDY・HTTP/2.0について熱い話ができとても満足しています。会場は満員で皆さんがとても興味を持って聞いていただいているのも十分感じることができました。 参加していただいた方、本当にありがとうございました。 2. LINEがSPDYを使っている セッションでは、つい最近 LINE が SPDY を使っているという発表( http://tech.naver.jp/blog/?p=2381 )について紹介し、その有用性についていくつかコメントをしました。 SPDYは、 Google が2011年より2年近くほとんどのGoogleサービスで実運用していますが、Google以外で世界的にメジャーな大規模の
GREEが悩むNode.jsの問題を考えるヒント - ぼちぼち日記
先日 GREEを支える大規模インフラテクノロジー」-GREE Platform Summer Conference 2012 という記事が公開され、GREEのCTOの藤本さんが、 javascriptをサーバーサイドでも使うケースが多くなってきていて、必然的にnode.jsを使うことになるが、大きく３つの問題がある。 ひたすらすごい勢いでバージョンアップしているので安定しない。コストを払ってついていく覚悟を持って取り組んでいる。 メモリリークがあるので、サーバを起動しっぱなしにするとメモリが食いつぶされる。 コードをデプロイしても再起動しないと読み込まれない。 （中略) これで絶対大丈夫という解決策がなくて、node.jsで一番悩んでいる。これでバッチリ解決するというものがあれば、是非教えて欲しい。 といった話が掲載されていました。 GREEさんに限らず一般的に Node に対して同じ問題
Googleが示すJavaScriptを350倍高速化する秘訣 - ぼちぼち日記
1. はじめに、 今年も Google I/O が開催されました。一度も現地に行って参加したことはないのですが、毎年セッションの内容は技術的に高度なものばかりでいつも注目しています。今年の一つ興味深いセッションで、 「Google I/O 2012 - Breaking the JavaScript Speed Limit with V8 (Daniel Clifford)」 スライド ,ビデオ というのがありました。（ビデオ・資料をすぐ公開してもらえるのはホントありがたいです。） ご存じの通り V8 は Chrome に搭載されているばかっ速い JavaScript エンジンで Node.js でも採用されています。このセッションは、 V8 の内部実装の解説を元にどう JavaScript の実行速度がパフォーマンスチューニングができるかという内容で、もうこれは必見で見逃せないものです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
