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」。 無料の証明書を提供してもらえるのは非常に嬉し
なぜChromeはURLを殺そうとするのか？ (Chrome Dev Summit 2019) - ぼちぼち日記
今年もChrome開発者の集まりChrome Dev Summit 2019 (CDS) がサンフランシスコで開催されました。 今回、私が Chrome Customer Advisory Board (CAB) に選出していただいたこともあり、CDSに初めて参加しました。 これは、CDS終了後のCAB meetingで頂いたChrome Dinosaurフィギュアです。ちなみにゲームはできません。 タイトルの「なぜChromeはURLを殺そうとするのか？」は、2日目Chrome Leadsのパネルセッションで司会のGooglerが、Chrome UX担当のProduct Managerに対して一番最初に投げかけた問いです。 PMは直ちに「そんなことはしない」と即答しました。しかしChromeは、URLの表示領域からHTTPSの緑色表示の廃止・EV表示場所の移動・wwwサブドメイン表示の削
Google Chrome EV表示の終焉 - ぼちぼち日記
1. Chrome でEV証明書の組織名表示がなくなる ついにGoogleからChromeのURLバーからEV表示を削除する正式なアナウンスが出ました。 Upcoming Change to Chrome's Identity Indicators EV UI Moving to Page Info 現在(2019年8月) StableのChrome76では、以下の様にURLバー左側にEV証明書を利用していることを示す「組織名+国名」表示が付いています。 Chrome76のEV表示 2019年9月10日Stableリリース予定のChrome77からはEV表示がURLバーから削除され、鍵アイコンをクリックして表示されるPage Infoに「組織名＋国名」が表示されるようになります。 Googleのアナウンスでは、 "on certain websites" と書いてあることから一気にではなく
OpenSSLの脆弱性(CVE-2017-3733)に見られる仕様とcastの落とし穴 - ぼちぼち日記
0. 短いまとめ OpenSSL-1.1.0dに脆弱性(CVE-2017-3733)が見つかり、Encrypt-Then-Mac と renegotiation を組み合わせて crashさせることができました。 この脆弱性は、仕様の準拠不足や不適切な変数の cast などが原因でした。 TLS1.3ではこういう落とし穴が少なくなるよう機能の根本的な見直しが行われています。 1. はじめに 先週 OpenSSL-1.1.0d に対してセキュリティアップデートがあり、 Encrypt-Then-Mac renegotiation crash (CVE-2017-3733)という脆弱性(Severity: High)が公開されました。 対象となった 1.1.0 は、昨年2016年8月にリリースされたOpenSSLの新しいリリースブランチです。1.1.0ではAPIの大幅変更もあり、まだあまり普及
錆びついたTLSを滑らかに、GoogleによるGREASE試験 - ぼちぼち日記
0. 短いまとめ 長い間、TLSのクライアント・サーバ間で使用するTLSバージョンを合意する際に、 不完全なサーバ実装によって version intolerance が発生することが問題になっていました。 TLS1.3ではこの version intolerance の影響を最小化するため、新しい version negotiation の仕組みを取り入れました。 Googleは、GREASE(Generate Random Extensions And Sustain Extensibility)という仕様をChromeに実装し、TLSサーバのバグで通らない拡張やフィールド値で問題が発生しないか試験を始めました。 パケットキャプチャが好きな人は、Chromeが 0x[0-f]a0x[0-f]a の見慣れない値をCipherSuiteやTLS拡張に使っているのを見つけても驚かないよう気を
本当は怖いAES-GCMの話 - ぼちぼち日記
Disclaimer 本エントリーは、この夏 blackhat usa 2016で行われる予定の講演「NONCE-DISRESPECTING ADVERSARIES: PRACTICAL FORGERY ATTACKS ON GCM IN TLS」 のネタバレを含んでいます。現地で直接聞く方は読まないよう気をつけて下さい。 0. 短いまとめ 今回は短めにと思ったのですが、やっぱりそれなりの分量でした。なので短いまとめを書いておきます。 4千万以上のサイト対してAES-GCM使ったTLS通信の初期ベクトル(IV)データのサーベイが行われ、7万程のサイトでIVの値が再利用される可能性があることがわかりました。IVが再利用された場合、AES-GCMの安全性は致命的な影響を受けます。IVの再利用が判明した幾つか実装から既に脆弱性のアナウンスが出ています。 IVが再利用された場合、現実的にHTTPS
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
Disclaimer 本エントリは、近々IETFで標準化される予定の新しいTLSの暗号方式 ChaCha20-Poly1305 について解説したものです。 本来なら、新しい暗号方式を紹介するいうことは、その暗号の安全性についてもちゃんと解説しないといけないかもしれません。しかし一般的に暗号の安全性評価はとても難しく、専門家でない者が暗号の安全性について軽々しく書くわけにはいかないなとも思いました。いろいろ悩みましたが、結局無用な誤解を避けるため、本エントリーでは ChaCha20-Poly1305 の安全性に関する記載を最小限に留めています。 今回紹介する ChaCha20-Poly1305 は、これまでも様々な暗号研究者の評価を受けている暗号方式ですが、まだNISTの標準や某国の推奨暗号リストに掲載されるといった、いわゆる特定機関のお墨付きをもった暗号方式ではありません。記載内容が中途半
ハッシュ衝突で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上で互いに連携しながら速やかにセキュリティ対策のリリース作業を行うことは何回やってもなかなかしびれる経験です。時差もありなかなか体力的には辛いものがありますが、世界の超一流のエンジニアと共同でリア
HTTP/2は流行らないけど広く使われるものだと思う。 - ぼちぼち日記
まずは Disclaimer、 「あくまでも個人の感想であり、HTTP/2の効能を保証するものではありませんw」 1. はじめに、 先日、HTTP/2, HPACKのRFC(7540,7541)が無事発行されました。2年余りHTTP/2の標準化活動に参加してきたのですが、もうすっかり昔の事のような感じがします。 今日、Scutumの開発をされている金床さんの「HTTP/2のRFCを読んだ感想」のエントリーが公開され、読ませて頂きました。今回初めてHTTP/2の仕様書を読まれた感想ということで、長くかかわってきた立場から見ると非常に新鮮な内容でした。 実は「HTTP/2が流行らない」という指摘は、１年半ほど前に私も同じことを書いていました。 HTTP/2.0がもたらす�Webサービスの進化(後半） また、偶然なのかわかりませんが、同じ Proxy製品 vanish varnish *1 の開
OpenSSLの脆弱性(CVE-2014-3511)でTLSプロトコルの基礎を学ぶ - ぼちぼち日記
1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、９つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの９つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み（の一部）を知りたい方はお読みください。 2. OpenSSLの脆弱性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
