web-dev-qa-db-ja.com

検索のためのGoogleのSSL暗号化はNSAスパイを阻止しますか?

NSA(およびGCHQ、DGSEなど))のユーザーデータへのアクセスが疑われるすべての場合:

推測を避けて、 すべての検索でSSL暗号化を使用するようにするGoogleの最近のアクション が実際に上記のスパイを防止するかどうかを知ることができますか?

そうでない場合は、( これまでに確認したもの に加えて)さらに知る必要があります。

8
Baumr

HTTPS、別名SSLは、送信中のデータのみを保護します。 GoogleがHTTPからHTTPSに自動的に切り替えるということは、ブラウザからGoogleのサーバーへの検索クエリが暗号化されることを意味します。しかし、Googleのサーバーでは、SSLトンネルが終了し、復号化されます。これにより、次の2つの状況でのみスパイが防止されます。

  • スパイは実際に、クライアントマシンとGoogleのサーバー間のトラフィックを調べていました(単にGoogleにデータのコピーを要求するのではなく)。
  • ユーザーは、GoogleがHTTPS URLにリダイレクトすることに実際に気づき、リダイレクトが行われない場合は「違反」します。

2番目のケースは 中間者攻撃 を行うactiveスパイに対するものであり、 HTTP(SSLなし)。 HTTPSへのリダイレクトはHTTPレベルで発生するため、SSLが実際に発生する前に(もちろん)、MitMはそれを確実にブロックし、SSL以外のGoogleサーバーの幻想を維持できます。

いずれにせよ、NSAのような米国の大規模な政府機関にとって、クエリデータのコピーを取得するためにGoogleの何人かの人々の助けを求めることは、おそらくネットワーク回線をスパイするという手間のかかる作業よりもはるかに簡単で効率的でしょう。米国を拠点とする企業であるG​​oogleは、一般的なスパイ活動が示唆するコストの(ほんの一部)に準拠するか、または準拠するように作られています。 Googleからクエリデータを取得すること自体は、スパイなどの不便なクエリでも機能します。米国以外の国から米国以外のGoogleサーバーへの接続用。

したがって、HTTPSを有効にすることがNSAからのスパイ行為と実際に関連することは、あり得ないことです。 「皆のためのHTTPS」は、Googleの文脈において、「敵」がNSAであると想定して、実際のセキュリティ改善よりもマーケティング/広報活動です。

8
Thomas Pornin

ボブと話をしたいと仮定すると、以下の仮定のいずれかがHTTPSによって付与された保護を無効にする(または実質的に弱める)ことにより、盗聴相手が攻撃されます。

  • 敵対者は、ボブのサーバーレコードに(協力、強制、または妥協を通じて)アクセスできるため、事実の後にボブとの通信を見ることができます。

  • 敵対者は、ボブの秘密鍵の所有またはPKIシステムの障害により、ボブになりすますことができます(たとえば、コンピューターが信頼するCAによって署名されたボブであると主張する証明書/キーペアを取得します)。

  • 攻撃者は何らかの方法でSSLを破っています。

これらの可能性のどれも、主要な国家諜報プログラムのためにひどく遠くにあるように思われません。

弱い懸念の1つは、中間者攻撃者がSSL除去攻撃を実行できることです。 HTTP経由でBobのサイトにアクセスしようとすると、Bobのサイトはすべての着信接続をHTTPSにプロモートします。ただし、攻撃者があなたをBobのサイトにアクセスすることをブロックします。代わりに、攻撃者はプレーンHTTPを介してボブのサイトのコンテンツを提供しますが、SSLを介して接続する必要があるのは賢明ではありません。

この問題は、 HTTP Strict Transport Security (HSTS)を使用するサイトによって軽減されます。これは、ブラウザにHTTPS経由でのみドメインからリソースをリクエストするように指示します。サイトへの最初のアクセスはMITM SSL除去攻撃にさらされていますが、HTTPリクエストはブラウザーを離れる前に自動的にHTTPSリクエストに変わるため、今後のアクセスは許可されません。一部のブラウザでは、特定のサイト用にHSTS命令がプリロードされており、それらのサイトの最初の訪問の問題がさらに解消されています。

上記で述べたすべてを考慮に入れて、HTTPSへの切り替えを行うと、コーヒーショップのワイヤレスネットワークでパケットスニファを実行しているカジュアルなスヌープから保護されます。

2
apsillers