私の政府がSSL証明書を交換しないようにする方法はありますか？
私は最近、政府がトラフィックを傍受するためにSSL証明書をスワップアウトしないようにする方法があるかどうか疑問に思っていました。
自己署名証明書の場合、ほとんどすべてのブラウザーが不満を持っていることを知っています。しかし、政府が独自のキーチェーンを発行するのを妨げているのは何ですか？
[〜＃〜] ca [〜＃〜] 証明書でパッケージを含むリポジトリを侵害し、トラフィックを解読するために独自の証明書を発行することを想像できます。すべてのトラフィックは、インターネットアクセスを提供する独占権を持つ政府の忠実なティア1オペレーターを通過します。
それが可能でない場合、どのようなメカニズムで彼らはそれを行うことができませんか？
敵が強力な国家国家の脅威である場合、ウェブ [〜＃〜] pki [〜＃〜] はあなたを保護しません。
彼らが自分の証明書を発行するのを妨げるものは何もない。実際、多くの政府が S FPKI や affiliates などの独自の認証局を運営しています。 CAのリストを参照 現在信頼されている Firefoxの場合：
- フランス政府
- 香港政府（SAR）、香港ポスト
- 日本政府、総務省
- スペイン政府、Autoritat deCertificacióde la Comunitat Valenciana（ACCV）
- スペイン政府（CAV）、Izenpe S.A.
- オランダ政府、PKIoverheid
- 台湾政府、政府ルート認証局（GRCA）
- トルコ政府、カムサーティフィカシオンメルケジ（カムSM）
Firefoxは米国のFPKIを信頼することを 現在は拒否 していますが、それでも他の多くの政府系CAを信頼しており、洗練された国家国家の俳優が既存の商用CAに絶対にアクセスできます。 Chrome、Internet Explorer、およびEdgeは、Windowsの場合、US FPKIを含む多くの政府認証局を含むシステムトラストストアを使用します。これらはいずれも、任意のWebサイトの有効な証明書に署名するために使用でき、ブラウザーは目をそらさずに喜んでそれらを信頼します。
Certificate Transparency （CT）の新しい実験的な標準は、誤って発行された証明書の影響を軽減するのに役立ちますが、悪意のあるCAを制御する専用の攻撃者からは保護しません。ただし、採用が増えると、悪意のあるCAまたは誤動作するCAを短時間で特定しやすくなりますが、攻撃が実行されてもすぐには防止されません。
一部のブラウザは certificate pinning を使用します。ここで、重要で注目度の高いドメインは、許可された認証局のハードコーディングされたリストに対して検証されます。これらのドメインの不正な証明書に署名するには、現在使用しているCAを侵害する必要があります。残念ながら、これはごく一部のドメインにのみ適用され、ウェブ全体を保護しません。
部分的な解決策は、証明書が政府機関のCAによって発行された.gov TLDのないドメインの信頼を拒否することです。これはクライアント側で実装できますが、実際にはほとんど影響がありません。敵対的な政府は、国営のCAで悪意のあるWebサイトに署名するつもりはありません。むしろ、既存のCAとの秘密の関係を悪用して、それらをだましたり、強制的に証明書に署名させたりします。前の段落で述べたように、CTはこれを検出し、攻撃にすぐに気づきますが、それを防ぐことはできません。
元のCA証明書がある場合でも、ブラウザー/ OSは証明書を適切にチェックしないように変更される可能性があります。または、ブラウザ/ OSがバックドアされ、暗号化の前または復号化後にアプリケーションからプレーンデータを直接抽出できる場合があります。また、動作のこのような重大な変更または変更は、使用しているハードウェアによって引き起こされる場合もあります。
これは基本的に、使用するシステム（ハードウェア、OS、ソフトウェア、構成など）が期待する機能のみを備えていることを確認する方法を尋ねていることを意味します。つまり、ベンダーと開発者が意図した機能のみを備えています（バックドアなどはありません）。後で追加されます）。この機能には、あなたに対して使用できるものは何も含まれていません（ベンダー/開発者によるバックドアはありませんが、バックドアとして使用される可能性のある重大なバグもありません）。
残念ながら、システムがこのように動作することを完全に確認するメカニズムはありません。最終的には、明示的なバックドアに関してだけでなく、バグ（不注意なバックドア）に関しても、配信チェーンをどれだけ信頼できるかがわかります。配信チェーンとは、ハードウェアとソフトウェアを入手したソース（ベンダー、インターネットからのダウンロードなど）をどれだけ信頼できるか、およびハードウェアとソフトウェアがソースからの転送中に改ざんから保護される方法を意味します。そして、これらのソースは通常、サードパーティのコンポーネントも使用します。つまり、配信チェーンをどれだけ信頼できるかという問題をさらに拡張する必要があります。
配信チェーンを信頼するのに役立ついくつかの方法がありますが、完全な信頼は不可能です。 1つの方法は、最初に実際に配信チェーンを把握し、実際に監査できるように十分に小さくすることです。これには、デリバリーチェーンをより小さく簡単に監査できるため、システムの複雑さが軽減されることも含まれます。これは、標的型攻撃を恐れなければならない一部の政府や大企業では可能かもしれませんが、通常のエンドユーザーにとっては実際には不可能です。これらは、信頼できるベンダーからのみ購入することでリスクを低減し（ローカルベンダーを信頼しない場合は海外でも）、インターネットからダウンロードされるものを最小限に抑え、安全なトランスポートを介して常に読み込まれるようにする可能性があります。重要な部分（ローカルCA証明書や特定の接続に使用されるCAなど）を他の部分と比較しようとする人もいます。
安全な起動や証明書のピン留めなどのメカニズムもあり、小さな変更の防止または検出に役立ちますが、配信チェーンを十分に制御している場合、関連するチェックを置き換えたり無効にしたりする、より高度な攻撃者（政府機関）によって単にバイパスされる可能性があります。
そもそも、洗練されていないエンドユーザーは、正常なシステム動作と異常なシステム動作を区別する機会がほとんどありません。そもそも、通常のシステム動作がどのように見えるかについて十分な詳細がないためです。しかし、政府が管理する（およびブラウザーが信頼する）CAを使用したCA証明書またはMITMの置き換えなどの攻撃は、そのような洗練されていないユーザーだけを対象とするのではなく、より広範囲に及ぶと想定すると、さらに偏執的で知識のあるユーザーが影響を受け、それを検出します他人を攻撃して警告する。
また、インターネットへの無料アクセスが多かれ少なかれ可能である場合（特に、明示的なブラックリストを除いて、ほとんど無料のアクセス）、攻撃者が配信チェーンを十分に制御できない可能性もあります。この場合、ユーザーは、ChromeまたはFirefoxなどのブラウザーの重要なドメインの組み込みSSLピニングなど）の保護を追加したソフトウェアをダウンロードする可能性があります。一方、偏執的なユーザーは、 プライバシーを保護すると主張しているが、代わりにスパイのトロイの木馬 であるソフトウェアをダウンロードする。
はい。証明書の発行元のCAとそのフィンガープリントおよび/または公開鍵全体を確認します。これは、ブラウザーで証明書の詳細を表示することで確認できます。これらを、関連する政府の管理下にない別の人または別のコンピューターが見た値と比較してください。コマンドラインツールを使用して別の国でホストされている安価なvpsでこれを行うには、TLS接続を作成して証明書情報をダンプします。証明書の透明性ログを使用して、他のユーザーに提示されているものとは異なる証明書を取得しているかどうかを確認することもできます。
これは確かにリスクであり、「本当の」セキュリティを必要とする何かをするつもりなら、核爆弾のコードを交換するようなものだとしましょう、それは本当の問題です。再び、それは大きな問題ではありません。攻撃が通過するアクターは直接政府ではなくCAです。政府は常に単純なゴムホース攻撃にアクセスできるため、CAが法の支配の対象となる公的機関である限り、これは常に問題になります（それにより、CAが1つ以上の政府の対象となり、したがって圧力や明白な古い暴力に敏感です）。この攻撃が実行可能である限り、より洗練された証明書の操作はほとんど役に立たないので、CA自体ではない場合でも、CAを強制的に支援（および無音状態を維持）できます。
より高いレベルの信頼が必要な場合は、ステガノグラフィとサイドチャネル（だけでなく）を含む通信のさまざまなアプローチに目を向けて、通信の可視性を減らし、攻撃を受ける確率を減らすことをお勧めします。
CAが証明書の正当性の証明を示すことができるという考えをもう少し詳しく調査することはまだあまり一般的ではありませんが、ブロックチェーンシステムでは可能かもしれません。それはおそらくかなり多くの計算を必要とするでしょう、そしてそれで私はそれが現在の業界からのいくらかの調整なしで実行可能であることを疑います。そしてそれでも、政府はどの暗号プリミティブが安全であるかについて非常に大きな発言権を持っているので、証明書を発行するために使用される方法そのものを汚す可能性があります。たとえば、NSAのBullrunプログラムと、Dual_EC_DRBGのより詳細な例を参照したいと思います。 Bruce SchneierとNiels Fergusonによって理論化され、後でEdward Snowdenによって確認されたバックドア（確認される前に私が研究中に直面する機会があったという議論では、Dual_EC_DRBGは潜在的に安全ですが、暗号プリミティブで使用される曲線を生成する必要がありますそれ以外の場合は、本質的にNSAを信頼して、他のアルゴリズムでは常にそうであるとは限らないことを、適切な秘密鍵で通知します）。