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サブドメイン表示の削
RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記
はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ
錆びついた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拡張に使っているのを見つけても驚かないよう気を
新しいTLSの暗号方式ChaCha20-Poly1305 - ぼちぼち日記
Disclaimer 本エントリは、近々IETFで標準化される予定の新しいTLSの暗号方式 ChaCha20-Poly1305 について解説したものです。 本来なら、新しい暗号方式を紹介するいうことは、その暗号の安全性についてもちゃんと解説しないといけないかもしれません。しかし一般的に暗号の安全性評価はとても難しく、専門家でない者が暗号の安全性について軽々しく書くわけにはいかないなとも思いました。いろいろ悩みましたが、結局無用な誤解を避けるため、本エントリーでは ChaCha20-Poly1305 の安全性に関する記載を最小限に留めています。 今回紹介する ChaCha20-Poly1305 は、これまでも様々な暗号研究者の評価を受けている暗号方式ですが、まだNISTの標準や某国の推奨暗号リストに掲載されるといった、いわゆる特定機関のお墨付きをもった暗号方式ではありません。記載内容が中途半
パンドラの箱？TLS鍵交換の落とし穴、KCI攻撃とは何か - ぼちぼち日記
1. 初参加のセキュリティキャンプ 先週ですが、講師としてセキュリティキャンプに初めて参加しました。 担当したのは高レイヤーのセッションで、TLSとHTTP/2の講義を合計6時間、まぁ大変でした。講義の時間配分、分量などの検討が十分でなかったため、本番では事前に準備していた講義内容の一部しかできず、ホント反省しきりです。せめての救いは、今回作った講義資料にたくさんのfavを頂いたことです。ありがとうございました。 講義では、学生の方々が短い時間ながら難しい演習に真面目に取り組んでくれました。質疑なども皆受け答えがしっかりしていて、技術的にもレベルが高い回答も多く、非常に驚きました。これだけ優秀な10代、20代の若者が、全国各地から毎年50人も集まるのを実際に見ると、彼らの将来が楽しみです。これまで10年以上継続してこのような活動を続けきた成果でしょう。私自身、とても良い経験をさせていただき
SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど１年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
Googleの新プロトコルQUICを試す - ぼちぼち日記
1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち（来週？）には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか？ 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte
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以外で世界的にメジャーな大規模の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
