タグ

ブックマーク / jovi0608.hatenablog.com (15)

  • FLoCとはなにか - ぼちぼち日記

    1. はじめに GoogleChrome/89よりトライアルを開始しているFLoC (Federated Learning of Cohorts)技術に対して、現在多くの批判が集まっています。 批判の内容は様々な観点からのものが多いですが、以前より Privacy Sandbox に対して否定的な見解を示してきたEFFの批判「Google Is Testing Its Controversial New Ad Targeting Tech in Millions of Browsers. Here’s What We Know.」が一番まとまっているものだと思います。 これまで Privacy Sandbox 技術に関わってきた身としては、各種提案の中でFLoCは特にユーザへの注意が最も必要なものだと思っていました。しかし、これまでのド直球なGoogleの進め方によって、FLoCのトラ

    FLoCとはなにか - ぼちぼち日記
    rryu
    rryu 2021/05/07
    「Cohort Id 内に含まれるドメインを洗い出し」の部分が謎すぎる。それができるならハッシュ化している意味が無いような。
  • 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」。 無料の証明書を提供してもらえるのは非常に嬉し

    Let's EncryptがはまったGolangの落とし穴 - ぼちぼち日記
    rryu
    rryu 2020/03/09
    ループ変数の参照を使うと結局全部同じ値になってしまうやつとは…
  • なぜ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サブドメイン表示の削

    なぜChromeはURLを殺そうとするのか? (Chrome Dev Summit 2019) - ぼちぼち日記
    rryu
    rryu 2019/11/19
    サイトの識別を容易にしようとしたIDNやEV SSLの組織名表示がことごとく裏目に出てしまったことの対応は分かるが、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" と書いてあることから一気にではなく

    Google Chrome EV表示の終焉 - ぼちぼち日記
    rryu
    rryu 2019/08/12
    まあ緑になる理由は書いてないし表示されているものが法人名だというラベルもないから普通の人は訝しむくらいしかできないし。緑でさえあれば安全という神話も法人名が全然ユニークではないことで終わってしまった。
  • Node.jsにおけるプロトタイプ汚染攻撃とは何か - ぼちぼち日記

    1. はじめに 最近わけあってNodeのセキュリティ調査をしているのですが、今年の5月に開催された North Sec 2018 でセキュリティ研究者の Olivier Arteau 氏による 「Prototype pollution attacks in NodeJS applications」という面白い発表を見つけました。 この発表の論文や発表資料、デモ動画などもgithubで公開されていますし、ちょうどタイミングよくセッション動画も最近公開されました。 github.com Olivier Arteau -- Prototype pollution attacks in NodeJS applications この発表で解説されているのは、悪意のある攻撃者が、JavaScript言語固有のプロトタイプチェーンの挙動を利用して、Webサーバを攻撃する方法です。 発表者は、npmからダ

    Node.jsにおけるプロトタイプ汚染攻撃とは何か - ぼちぼち日記
    rryu
    rryu 2018/10/31
    __proto__が仕様化されていたとは。Objectには特殊な意味を持つプロパティはないという状況が変わってしまったのか。
  • RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記

    はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ

    RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記
  • 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の大幅変更もあり、まだあまり普及

    OpenSSLの脆弱性(CVE-2017-3733)に見られる仕様とcastの落とし穴 - ぼちぼち日記
    rryu
    rryu 2017/02/20
    アサートに引っかかって落ちるとは。
  • HTTP/2とTLSの間でapacheがハマった脆弱性(CVE-2016-4979) - ぼちぼち日記

    0. 短いまとめ 昨晩apache2.4でHTTP/2利用時にTLSクライアント認証をバイパスする脆弱性(CVE-2016-4979)が公表され、対策版がリリースされました。 実際に試すと Firefoxで認証バイパスができることが確認できました。 HTTP/2でTLSのクライアント認証を利用するには仕様上大きな制限があり、SPDY時代から長年の課題となっています。 この課題を解決するため、Secondary Certificate Authentication in HTTP/2という拡張仕様が現在IETFで議論中です。 1. はじめに ちょうど昨晩、apache2.4のhttpdサーバの脆弱性(CVE-2016-4979)が公開され、セキュリティリリースが行われました。 CVE-2016-4979: X509 Client certificate based authenticatio

    HTTP/2とTLSの間でapacheがハマった脆弱性(CVE-2016-4979) - ぼちぼち日記
    rryu
    rryu 2016/07/07
    クライアント証明書認証は接続単位の認証だから、複数のリクエストで1つの接続を共有するHTTP/2では色々面倒なんだな……
  • ハッシュ衝突で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/

    ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記
  • パンドラの箱?TLS鍵交換の落とし穴、KCI攻撃とは何か - ぼちぼち日記

    1. 初参加のセキュリティキャンプ 先週ですが、講師としてセキュリティキャンプに初めて参加しました。 担当したのは高レイヤーのセッションで、TLSとHTTP/2の講義を合計6時間、まぁ大変でした。講義の時間配分、分量などの検討が十分でなかったため、番では事前に準備していた講義内容の一部しかできず、ホント反省しきりです。せめての救いは、今回作った講義資料にたくさんのfavを頂いたことです。ありがとうございました。 講義では、学生の方々が短い時間ながら難しい演習に真面目に取り組んでくれました。質疑なども皆受け答えがしっかりしていて、技術的にもレベルが高い回答も多く、非常に驚きました。これだけ優秀な10代、20代の若者が、全国各地から毎年50人も集まるのを実際に見ると、彼らの将来が楽しみです。これまで10年以上継続してこのような活動を続けきた成果でしょう。私自身、とても良い経験をさせていただき

    パンドラの箱?TLS鍵交換の落とし穴、KCI攻撃とは何か - ぼちぼち日記
    rryu
    rryu 2015/08/21
    同一のPreMasterSecretを生成できることで証明書に対応する秘密鍵を持っている証明にしていたらクライアントの秘密鍵さえあれば同じものが生成できるという穴なのか。
  • 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

    Node-v0.10.34がはまったクロスルート証明書とOpenSSLの落とし穴 - ぼちぼち日記
    rryu
    rryu 2014/12/23
    要はOpenSSLがクロスルート証明書に対応していなかったという悲しい話なのか…
  • 不正なSSL証明書を見破るPublic Key Pinningを試す - ぼちぼち日記

    先日のエントリー 「TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説)」で予告した通り、今回不正なSSL証明書を見破る Public Key Pinningの機能について解説します。 Public Key Pinning は2種類の方法があります。あらかじめブラウザーのソースコードに公開鍵情報を埋め込む Pre-loaded public key pinning と、サーバからHTTPヘッダでブラウザに公開鍵情報を通知するHTTP-based public key pinning (HPKP)の2つです。 Chromeは既に両者の機能を実装済ですが、ちょうど近日リリースされる Firefox 32 の Stable バージョンから Pre-loaded public key pinning が実装されました。Firefox32リリース記念と

    不正なSSL証明書を見破るPublic Key Pinningを試す - ぼちぼち日記
    rryu
    rryu 2014/09/03
    メジャーなサービスに成長したらこの辺も対応しないといけなくなるのか。
  • 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

    TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説) - ぼちぼち日記
    rryu
    rryu 2014/08/22
    SPDYのコネクション集約のチェックが甘くてうっかり集約されて通信できてしまうという感じか。
  • OpenSSLの脆弱性(CVE-2014-3511)でTLSプロトコルの基礎を学ぶ - ぼちぼち日記

    1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、9つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの9つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み(の一部)を知りたい方はお読みください。 2. OpenSSLの脆弱性

    OpenSSLの脆弱性(CVE-2014-3511)でTLSプロトコルの基礎を学ぶ - ぼちぼち日記
    rryu
    rryu 2014/08/08
    該当箇所のちょっと後のコメントに「If TLS 2.0 ever appears we will need to revise this....」とあって、まだバージョン依存の爆弾を抱えている模様…
  • ネストされたドメインの奇妙な振る舞い - ぼちぼち日記

    はじめに ちょっと前の nodejs のメーリングリストで 「Odd behavior of nested Domaons」 https://groups.google.com/d/topic/nodejs/i8NjWjVvk2I/discussion という質問が投げかけられていました。 私も内容が気になり、動作結果が非常に奇妙に思えたので調べてみました。(ML宛には解答を返事してますのでネタバレ注意です) 問題の奇妙な振る舞い 質問で提示されたコードは下記のものでした。 var domain = require('domain'); var topDomain = domain.create(); //親ドメインの作成 var subDomain = domain.create(); //子ドメインの作成 topDomain.add(subDomain); //親ドメインに子ドメインを

    ネストされたドメインの奇妙な振る舞い - ぼちぼち日記
    rryu
    rryu 2012/10/21
  • 1