信頼できる認証局に関するセキュリティの脆弱性を報告するにはどうすればよいですか？
私は、すべての最新のブラウザーとコンピューターで信頼されている認証局の巨大なセキュリティ脆弱性に出くわしました。
具体的には、私が所有していないドメインの有効な署名付き証明書を取得できます。 Man In the Middleになる手段があったら、完全に有効なssl証明書を提示できます。
この脆弱性では、SQLインジェクションやコーディングは必要ありません。私はそれをかなり比喩的に偶然見つけました。
これを報告する適切な方法は何ですか？私は倫理的になり、問題のあるCAに報告したいのですが、単に脆弱性を修正してから、敷物の下にあるすべてのものを一掃してほしくありません。この問題はしばらく前からあったようで、私はそれを見つけることができる唯一の問題になるほど賢くはありません。
CAに連絡するだけでパニックが発生することを懸念しています。DigiNotarのような事件を恐れて、CAは公に知られないようにするために何でもします。
他の認証局やCloudFlareやGoogleなどの他のサイトなど、いくつかの主要なプレーヤーに連絡することもできますか？ （CloudFlareが公表が発表される前にHeartBleedについてヘッドアップが与えられたことを知っています。）
注：匿名のままにするために、仮名アカウントで投稿しています（今のところ、匿名のままにしてください）。
編集：この質問は 別の質問 に関連していますが、この脆弱性はその質問の範囲外にあると思います。これは本質的にインターネット全体に影響を与える可能性があります（つまり、オンラインのすべてのユーザーが顧客です）。私の質問には、「開発者」（リンクされた質問に対する承認済みの回答）に連絡するだけが私にとって最良の最初のステップではないように思われると明記されています。
編集2：私は何人かの人々と連絡を取りました、そして彼らは私にこのフォーラムでそれ以上話をしないように助言しました（すみません！）脆弱性が完全に修正され、不正な証明書が取り消された後で、この質問を更新します。
編集3：詳細は公開されています。脆弱性の詳細について 私の個人用サイト に詳細を投稿しました。ストーリーはまだ進行中であり、Mozilla、Google、およびCA WoSignの間で ディスカッションを読む できます。
編集4：約束どおり、これとWoSignに関連する他のインシデントに関して Ars Technica によって書かれた記事へのリンクを更新しています。 WoSignとStartCom（現在は同じ会社が所有）がルート失効の深刻な危険にさらされているようです。
そのような主張は一般的に非常に深刻です。
問題のベンダーに連絡することは責任のある問題ですが、関連するルートストアのセキュリティチームに通知することを検討する必要があります。これは、セキュリティコントロールを設計、評価、および適用してこれを防止し、直接作業する必要があるためです。 CAと一緒に問題を確認します。
責任ある開示の観点から、主要なルートストアオペレーター（Google、Microsoft、Apple、Mozilla）のそれぞれにもこれをすぐに報告する必要があります。 「<vendor>セキュリティバグを報告してください」と最初の結果からわかります。これらは影響を受けるベンダーの一部です-たとえばCAだけではありません。
これを行う方法がわからない場合、匿名を希望する場合、または調整の支援が必要な場合は、Chromiumのセキュリティチームが調査し、適切なCAに連絡して、幅広い業界と調整します。詳細は https://www.chromium.org/Home/chromium-security/reporting-security-bugs を参照してください。
あなたの問題は、この脆弱性があなたが何をすべきかを知っているよりも大きいということです。
責任ある開示のルール ここで説明 は、ベンダーに連絡して、必要な変更の深さに応じて、1週間から6か月の期間交渉する必要があると述べています。調査結果を公開する前に、パッチの実装、証明書の取り消しと再発行、セキュリティ情報の公開などを行うことができます。交渉期間の終わりにあなたはあなたの公の認識を得ますが、あなたの一般公開はこれ以上害を及ぼすことはありません-ベンダーが彼らの仕事を適切に行っていれば。
それらに連絡する方法/責任ある開示期間を交渉する方法を理解する、最後に結果を公表するなどが大きすぎる場合、または開始する方法がわからない場合は、私に連絡して提携することをお勧めしますすでに出版チャネルを確立している有名なセキュリティ研究者。すでに同様の脆弱性を公開している有名人を見つけて、呼びかけましょう！彼らの注意を引くのに問題はないようです。
おめでとうございます！半年であなたの名前が紙に載るのを楽しみにしています！
おめでとう！大きな発見のように聞こえます。
最初に、いくつかの証明を生成します。 github.com SSL証明書は素晴らしいスタートのように思えます。何が起こったのかを正確に示すために必要なすべてのネットワークトレースを必ず保持してください。
これを行っている間に、法律や規約に違反したかどうかを判断する必要があります。 CAにバグの報奨金がない場合は、ほぼ間違いなくそうです。その場合は、匿名でいることが重要です。ここでの懸念の1つは、テスト中にすでに身元を明らかにしている可能性があることです。たとえば、おそらくその証明書の料金を支払う必要がありました。どのように支払いをしましたか？匿名ではない方法ですでに法律を破っている場合、これはCAに対する強力な武力戦術をほとんど除外します。
CAに連絡したいのは立派なことですが、この脆弱性を売り込む可能性があることを覚えておいてください。これは潜在的に価値があります $ 100,0 vupenのような組織から。それについてどう感じるかはあなた次第です。
開示したい場合は自分で行うこともできますが、定評のある研究者に連絡するというマイクの提案には同意します。大学の研究者より少し上を目指してもいいと思います。ブルース・シュニエやダン・カミンスキーのような有名人はこれに興味があるでしょう。あなたは彼らを詳細で信頼し、彼らの重みを使って問題を真剣に受け止めなければなりません。
CloudFlareがHeartBleedの初期のビューを取得することに関して、これは主要な脆弱性の標準的な方法です-その主要プロバイダーは早期の警告を受け取ります。しかし、それはプロセスのかなり後の方で行われます。 HeartBleedの場合、パッチが開発された後（ただし、一般にはリリースされていません）。それがこの脆弱性にどのように適用されるかはわかりません。 CAによって発行されたすべての証明書が疑わしいようです。
何をするにしても、頑張ってください！
不明な場合は、CERTに問い合わせることもできます。 https://forms.cert.org/VulReport/
彼らは非常に深刻なセキュリティの脆弱性にも対処した経験があり、一般に信頼できる当事者と見なされています。少なくとも、彼らはあなたの脆弱性の評価が正しいことを確認し、それを見つけるためのあなたの部分を文書化することができます。
CERTは通常、ベンダーに直接連絡することをお勧めしますが、このような大きなケースについては、彼らが支援を提供すると確信しています。
Ryan Sleeviはこれに関して非常に良いアドバイスをしています。
あまりにも多くのアラームを鳴らす前に、Chromiumのセキュリティチームにアドバイスを求めて連絡し、誤解がないことを確認します。
CABフォーラムのベースライン要件に対して脆弱性をチェックし、脆弱性の実行がこれらのルールに違反していないかどうかを確認しました： https://cabforum.org/baseline-requirements-documents/ ？
たとえば、私はあなたの要約と一致するように見える発行慣行を知っていますが、AFAIKは完全に有効であり、CABフォーラムの目にある脆弱性ではありません。ルートを制御することなく、サブドメインの証明書を生成できます。つまりgoogle.comに対する制御を実証しなくても、test.google.comの証明書を取得できます。
脆弱性を認識しているので、脆弱性のドキュメントとデモを入手することをお勧めします。理想的には、状況を読んだ第三者が完全にこれを検証できる場合。
脆弱性に関するアドバイスの整合性またはベンダーの否認の問題を回避するには、デモンストレーション/実行による追加の証明が必要です。私たちは証明書に関連しているので、障害を示す証明書チェーンを取得することが理想的です。もちろん、vulnの動作を示すセッションキャプチャはすべて役に立ちます。
完全な開示がなければ、とにかく必要な証拠を推測しています。エクスプロイトドキュメントの証拠を取り、GitHub、Pastebin、メーリングリストなどの公開されている場所にシードします。これにより、証拠が強力な場合に否認することができなくなります。
残りの問題は、ベンダーと一般人とのアイデンティティとコミュニケーションです。私はあなたの個人的アイデンティティの啓示を使わないようにするつもりはありません、それはあなた次第です。コミュニケーション、あなたが実際になりたい、そして失敗するか、経験で行動しない準備ができている場合は、すべてが吹き飛んだり横向きになったりする場合は、連絡を取ることができます。
あるいは、コミュニティ、EFF、または少なくともあなたの弁護士のいずれかに代表を求めてください。あなたの利益を保護する誰かが賢明であり、その商業的能力において企業からの業界の助けを受け入れる前に慎重に考えてください。あなたがそのような助言を求めた場合、私はここのコミュニティが代表に関するいくつかの選択を推奨できると確信しています。
本全体がこの一連のトピックについて書かれる可能性があるので、私はそれを短くしてTLDRに含めないようにしました。地域。
また、余談ですが、この潜在的な脆弱性の発見に時間を割いていただきありがとうございます。ひどく必要です。
オペレーティングシステムとブラウザーのベンダーは、ルートCAリストを管理しているため、このような脆弱性を報告するのに適した場所かもしれません。ここにいくつかの関連リンクがあります：
- www.google.com/about/appsecurity/
- www.mozilla.org/en-US/about/governance/policies/security-group/bugs/
- www.Apple.com/support/security/
- technet.Microsoft.com/en-us/security/ff852094.aspx