☰

ロングバージョン

tag-icon • tag-icon security seahorse
ロングバージョン

検索エンジンで説明を見つけるのが難しかったので、ここで質問して回答します。

Seahorse、Gnome キーリングおよびキー マネージャーでは、「Show Any」がオンの場合、「Default Trust」タブの下にすべて空白のフィールドを持つ疑わしい証明書がいくつか表示されます。

ここに画像の説明を入力してください

どこから来たのか、何なのか、どうやってそこにたどり着くのかは明らかではありません。セキュリティ上のリスクがあるのでしょうか? ハッキングされたのでしょうか?

答え1

そこには問題 #299これについては、Seahorse の問題追跡システムで確認してください。

TL;DR: これらは、ディストリビューションのルート CA リストで保護のために信頼されていない証明書としてマークされています。Seahorse はこれらを適切に処理しません。それは見た目の問題であり、セキュリティの問題ではない。

ロングバージョン

長年にわたり、CA 証明書が悪用される事件 (ハッキング、無責任な使用など) が複数発生しています。ブラウザはこれらの CA が発行した証明書を信頼するため、セキュリティの面では非常に深刻な侵害となります。

MiTM攻撃からあなたを守るために、これらの証明書はディストリビューションの証明書リストに含まれており、明示的にマークされたブラックリストに登録/拒否/無効として表示されます。

ほとんどのディストリビューションは、リストを1つnss プロジェクトの一部として Mozilla アップストリームによって管理されています。

こうした悪い証明書の一例としては、Trustwaveの一部として発行される証明書が挙げられます。論争. これがMozillaです問題これらの証明書を信頼できないものとしてマークします。

mozilla ファイルを見ると、「Trustwave によって発行された MITM subCA 1」というエントリがあり、信頼できないものとしてマークされていることがわかります。

この例と他のいくつかの例は、(null)無視するのに十分な情報が含まれているものの、実際の CA 証明書が含まれていないため、seahorse では として表示されます。そのため、seahorse では、このような奇妙な方法で表示されます。

ヌル証明書に対応する 7 つのエントリは次のとおりです。

  • 「Trustwave 発行の MITM サブ CA 1」
  • 「Trustwave 発行の MITM サブ CA 2」
  • 「TURKTRUST 中間 CA 1 が誤って発行されました」
  • 「TURKTRUST 中間 CA 2 が誤って発行されました」
  • 「不信任: O=エジプト信頼、OU=VeriSign Trust Network (証明書 1/3)」
  • 「不信任: O=エジプト信頼、OU=VeriSign Trust Network (証明書 2/3)」
  • 「不信任: O=エジプト信頼、OU=VeriSign Trust Network (証明書 3/3)」

お気に入りの検索エンジンを使用して、これらの背後にあるストーリー（DigiNotar や Comodo も）についてさらに詳しく調べ、CA 信頼システムが実際にどれほどひどく壊れているかを知ることができます。

Fedora では、CA 証明書リスト (mozilla ファイルから派生) は にあります/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit。

私はこれを Gitlab の seahorse 開発者に報告しようとしましたが、16 回のキャプチャ、30 分、1 回の即時ブロックの後で諦めました。

リンク:

関連情報