現在、自己署名証明書は実際にCA署名証明書よりも安全ですか？
現在、自己署名証明書は実際にCA署名証明書よりも安全ですか？
NSAスパイプログラムと秘密のFISA裁判所に関する最近の漏洩は、米国政府が米国の認証局にルート証明書を秘密裏に引き渡すよう強制することができ、CAはできないことを意味します。秘密のギャグ命令のためにそれについて何でもします。すべてのISPとゲートウェイでの米国の通信傍受を考えると、入ってくる各HTTPS接続をMITMし、代わりに同じルート証明書で署名された独自の公開鍵を与えることは簡単ですにより、TLSセッションで使用されている秘密鍵を傍受し、すべてのデータのコピーをユタのデータセンターに転送して、分析と永続的な保存を行うことができます。この機能はしばらく前からあるようで、何もわかりませんこれは基本的にインターネット全体の信頼を損なうものです。
この情報を知っていれば、技術的には安全でしょうかmore民間組織がサーバーの自己署名証明書を生成し、その証明書を手動でコピーしてCD/USBドライブでユーザーに提供するのは安全です。次に、ユーザーは証明書を信頼できるものとして手動でWebブラウザーに読み込みますか？そうすれば、接続が米国によってMITM化された場合、ブラウザの接続と一致しなくなります。
ただし、Verisign、Comodoなどからプリロードされた「信頼できる」CA証明書がすでにブラウザにあるため、米国は接続に対してMITM攻撃を行っているため、実サーバーへのリクエストを開始するだけではなく、パブリックをコピーします。証明書情報、次に、要求されているそのドメインの情報に基づいて新しい証明書を作成し、ブラウザが信頼するルートCAの証明書のいずれかで署名して、データを傍受できるようにしますか？証明書が正しい会社のVerisign、Comodo、または別の会社によって署名されたものであるかどうかを確認するために、これらのことを実際に見て気にする人はいません。ユーザーは南京錠を見ているだけです。自己署名証明書を作成したことを覚えている管理者にとっては疑わしいだけで、Verisignや他の会社によって署名された証明書ではありません。
これはちょうど私が何でもMITM攻撃を実行することができるためにほとんどのブラウザに事前にロードされ信頼された1つの危険なCA証明書のみが必要であることを私に認識させました、彼らは単に彼らがそれのいずれかに署名した新しいもののためにサイトの実際の証明書を交換しますブラウザによって信頼されているルートCA証明書その場合は、新しいブラウザプロファイルが必要で、信頼できる証明書をすべて削除し、組織の信頼できる証明書を読み込んで、そのブラウザを組織内での通信にのみ使用します。 MITMを試みると、ブラウザに大きな警告が表示されます。
ここには微妙な点があります。想定される状況では、 man-in-the-middle攻撃 に対して偽の証明書を発行する可能性がある1つ（または複数）の不正なCAがあります。ここでの脆弱性は、その不正なCAからの（正規の）証明書を使用するサーバーに関するものではありません。クライアントが潜在的にそのCAからの証明書を受け入れることについてです。不正なCAから（クライアントとして）自分を保護するには、mustそのCAを信頼しない（つまり、「信頼されたルート」証明書ストアから削除する）。これは単にimpliesであり、引き続き通信したいサーバーは、証明書に他の異なるCAを使用する必要があります。
企業では、自己署名証明書を作成してすべてのクライアントにプッシュすることは、実際に独自のPKIを維持するの特別なケースです。すべてのクライアントにインストールする必要があるいくつかのルート。これは可能です。一部の企業はまさにそれを行います。ただし、ここで説明するMitMの場合、すべてのクライアントの「信頼されたルート」ストアが他のすべての、潜在的に邪悪なCAからクレンジングされるまで、何も得られません。
残念ながら、必ずしもそうすることはできません。オペレーティングシステムがWindowsの場合、さまざまなコンポーネント、特にMicrosoftからの更新に使用される多くの署名があります。あなたはdoセキュリティ修正プログラムをインストールしたいと思いませんか？ほとんどのルートCAを「信頼されたルート」から削除することで回避できますが、すべてではありません。そうしないと、OSで多くの障害が発生します。
概念的な問題は、一部のOS（特にWindows）が証明書の検証に一元化されたメカニズムを使用することです。このメカニズムでは、oneトラストストアがあり、これは、マシンでの証明書の検証（詳細には、すべてのユーザーに共通の「ローカルマシン」トラストストアが1つあり、ユーザーごとに1つの追加のトラストストアがありますが、ユーザーは共通ローカルマシントラストストアから「オプトアウト」できません）。内部のニーズにX.509証明書を伝統的に使用していないLinuxなどの他のオペレーティングシステムでは幸運かもしれませんが、OpenPGPキーははるかに分散された信頼システムを備えています。
Firefox Webブラウザーは、ベースOSのそれとは別に、独自のSSL実装とトラストストアを使用します。さらに、Firefoxは profiles をサポートしています。つまり、ユーザーはFirefoxで複数の「ペルソナ」を持つことができ、それぞれに独自の設定があります。信頼されたルートのセットを含みます。したがって、データの機密性を恐れる企業は、次のことを実行できます。企業のサーバーを扱う場合、従業員に対して、企業独自のルート（または自己のセットのみを含む特定のプロファイル）で常にFirefoxを使用するように指示できます。署名済み証明書）として「信頼されたルート」として。
その従業員がそれを望んでいるかどうかは不明ですが、実現可能です。
ただし、強力な攻撃者は強力であることを忘れないでください。その攻撃者が「公式CA」を制御する可能性がある場合、Microsoftによって署名されたとされる偽の更新をプッシュし、すべてのシステムにバックドアをインストールする可能性があります。または、Microsoftにバックドアを設置するよう依頼することもできます。いずれにせよ、選択の幅はあまりありません。構造上、不正なゲームをプレイしないためには、OSとハードウェアを信頼する必要があります。
Firefoxの Certificate Patrol のようなブラウザプラグインは、最後または最初にアクセスしてからの変更を警告することができます。しかし、正当なネットワークトポロジと負荷分散ソリューションの多くがSSLのこの互換性のある信頼の欠陥に依存していることがわかります。そのため、インターネットをナビゲートするときに、大量のプロンプトと警告が表示されます。
自己署名証明書またはプライベートルートCAは、事前に信頼されたパブリックルートCAよりも安全です。プライベート証明書チェーンとそれを受信する安全なチャネルを信頼する理由がある場合。つまり、信頼できる自己署名証明書のみを信頼します。他のすべての事前信頼されたルートCAを削除する必要があります。
おそらく、コンピューター上に2つの異なるブランドのブラウザーインスタンスがあります。 1つは、検証されたルートCAのごく一部のみを使用した安全な通信用です。安全でない通信のための別のバニラブラウザインスタンス。
当初、非対称暗号化（公開/秘密キーのペア）には、1990年代の物理的なキー署名パーティの人気など、より直接的な信頼が何らかの形で含まれることが想定されていました。 90年代半ばにインターネットが爆発する前に、正確に実行可能なアプローチは完全には具体化されていませんでした。
これらの信頼の物理的なウェブは、国内または国際的な距離ではeコマースにとって機能しないと見なされていたため、ビジネスコミュニティの残りの部分に対して「信頼できる」ルートCAとして機能する企業の作成を受け入れました。おそらく、彼らが検証していない証明書に署名した場合、訴えられる可能性があります。これは、eコマースを目的としたcitizen<->business信頼の（ほとんどの場合）ソリューションですが、商業認証局を盗聴し、強制するリソースと法的権限を持つ団体に対する保護には何もしません。
言い換えると、NSA *がこれまでに語った最高のうそは、彼らのスパイが存在しない、または機能しないことでした。
データ保持はこれをまったく新しいレベルに引き上げます。
個人的には The Light of Other Days を読んで以来、真にプライベートなものは何もないという考えを素晴らしく吸収しました。それは、あなたに存在するパワーがどれほど関心を持っているか、彼らが自由に使えるもの、そしてそれらを抑制するために健全な民主主義が存在するかどうかにかかっています。
*または[ここにお気に入りのスパイ機関を挿入]
ここの他の誰もが正解ですが、ここにあなたの質問に対する簡単な直接的な答えがあります。
自己署名証明書を初めて受け入れたときに帯域外でサーバーの所有者と通信でき、それがその証明書であることを確認し、将来のサーバーへの接続のためにその1つの証明書のみを認識する場合、理論的にはそのようなセットアップは、従来のCA署名付き証明書よりも安全です。 USBドライブのトランスポートシナリオは、USBドライブが何らかの形で侵害されていないことを確認できる限り、ここでは帯域外通信として機能します。
そのような場合、その証明書がCA署名か自己署名かに関係なく、その証明書が常にブラウザーによって（またはあなたの心の中で）ピン留めされている場合、これを行うことができます。すべての訪問）、その後、あなたは比較的確実にMitMが起こっていないことができます。ただし、これには、あらかじめすべてのサーバーオペレーターと直接話し、信頼する必要があるため、多くの場合、これは現実的ではありません。
このシナリオでは、悪意のあるエンティティがサーバーに侵入して秘密キーを盗んだ場合にも、帯域外の取り消しチャネルも必要になります。そして、「まあ、サーバーオペレーターが秘密キーの侵害を認識していない場合はどうなりますか？」そうすればできることは多くありません。これは、SSL/TLSでは一般的に防止できない問題です。
単にCAの開始に依存するよりも、ピン留めされた証明書を使用する方が安全です。これは、証明書が自己署名されているか、CAによって署名されているかには依存しません。
ただし、ピンの分布を確認する必要があります:-)
「安全なブラウザ」をCDで配布している場合は、 http://scarybeastsecurity.blogspot.com.es/2011）の"Twitter Like A Boss"のようなコマンドラインを使用してショートカットをインストールできます。 /04/fiddling-with-chromiums-new-certificate.html
（注意：現在のChromeバージョンは、HSTSのpublic_key_hashesプロパティをサポートしていません。HSTSは、コマンドラインで証明書をピン留めするために使用されています）
自己署名証明書のみを使用しても、安全性は向上しません。接続が危険にさらされた後は、すべてのクライアントに、接続が安全でなく信頼できないことを個人的に伝え、新しい証明書を展開し、すべてのクライアントに時間内に通知されることを常に確認する必要があります。
この方法を使用する場合は、独自のプライベートルート証明書（インターネットに接続したことのないマシンで生成されたもの）を使用して独自のCAを構築する必要があります。キーはUSBスティックにのみ保管し、ボールトに入れて、新しい証明書（要求）を発行する必要がある場合にのみ取り出してください（これも、World Wide Webを見たことがないコンピューターでのみ実行してください）。 。 CAがあると、必要に応じて新しい証明書を作成できます。次に、証明書が取り消された場合にクライアントがオンデマンドでチェックできるようにOCSPサーバーをセットアップします（クライアントソフトウェアの場合は、接続前にOCSPチェックを実行する必要があります）。
すべてが設定されて機能しているときは、何も問題がないことを期待する必要があります（サーバーがハッキングされる）。しかし、それは多くの作業であり、それを安全に保つことはおそらく安くはありません。