タイトルは本当にすべてを語っています。私はアリスです。ブラウザからGmailのウェブインターフェースにログインします。インターネットサービスプロバイダーのIkeとローカルネットワーク管理者のAdamが、私のGmailメールアドレス(ユーザー名)を知りたいと思っています。それらのいずれかがおそらくそれを学ぶことができるように物事が起こるための考えられる方法はありますか?
平均的なホームユーザーの場合、GMail(TLS経由で実行される)などのサービスは、ユーザー名などの情報をISPまたはネットワーク管理者に漏らしません。
LAN管理者も管理しているマシン(会社が運営しているドメインに接続されている仕事用のコンピューターなど)を使用している場合は、そのマシン上で何でも読み取ることができると想定する必要があります。彼らはあなたの活動(ブラウジングやキーストローク)を記録するソフトウェアを持っていたり、GMail(または他のサイト)への接続をMITMに許可する追加のSSL証明書をインストールしているかもしれません。
コンピュータが改ざんされておらず、信頼できない人の制御下にない(つまり、LAN管理者がマシンを制御していない)と思われる場合は、https経由でGMailに接続できます。 (この時点で、LAN管理者はインターネット上の攻撃者に相当します。)有効な証明書で https://mail.google.com に接続していることを確認してください。コンピュータとGmailサーバーは暗号化されています。これには、ログインに使用したユーザー名など、アカウントに関するすべての情報が含まれます。
@Davidと@Steveの回答を補足するには:
攻撃者(あなたのケースでは "Adam")があなたのマシンへの管理アクセスを持っている場合、彼はあなたのすべての秘密を知ることができます。 SSL接続でルーチン MitMインターセプト を実行するために、彼の制御下で追加のルートCAをインストールすることは、honestの一般的なツールです(おせっかいな)sysadmins:これは、ソフトウェアの更新によって危険にさらされることのない1回限りのインストールであり、アンチウイルスなどの他のソフトウェアとの互換性の問題が発生しません。しかし、スパイが目立たないようにしたい、よりノイジーなシステム管理者には、キーロガー、スクリーンキャプチャツールのインストール、マシンのRAM。
攻撃者がマシンの内部にアクセスできない場合は、SSL交換を禁止する必要があります。 Gmailに接続したときにも気づくことができ、Gmailと交換されるデータ要素の正確なサイズを監視できます。彼はおそらくあなたのGmailアドレスのlength(文字数)を計算できるでしょう。
@Steveが観察しているように、Gmailアドレスは秘密に設計されておらず、多くの場所で漏洩します。いずれの場合でも、emailアドレスとして、他の人(あなたにメールを送信する人)と共有する必要があるため、真に秘密であるとは見なされません。
Google+(メールアドレスでインデックス化)を使用している場合、悪質なシステム管理者があなたのアクティビティに気づき、それを一部の候補のGoogle+アカウントでの目に見えるアクティビティと関連付ける場合があります。結局のところ、彼があなたの後にいる場合、彼はあなたに興味があるであり、いくつかの献身を示し、あなたを適切に追跡することもできます。
デビッドが言うように、ネットワークのプロバイダーは通常、https接続を介して渡されるデータを見ることができません。
ただし、Gmailアドレスがhttps接続経由でのみ渡されるとは限りません。たとえば、秘密のGmailアカウントを使用してStackExchangeにログインし、ユーザープロファイルページのhttp(httpsではない)バージョンにアクセスした場合、Gmailアドレスがそのページのコンテンツで保護されていない状態で送信されます。ネットワーク接続のプロバイダーはそれを見ることができます。 OAuthログインにhttpsを使用する他のサイトでも同じですが、すべてのトラフィックに当てはまるわけではありません。
また、 ser49372が指摘 のように、Adamがアクティブな中間者攻撃を実行する用意があり、秘密のGmailアドレスを使用してStackExchangeにログインした場合、通常のものに注入できるブラウザをStackExchangeプロファイルページのhttpバージョンにリダイレクトするhttpトラフィック。
つまり、AdamまたはIkeがあなたのマシンに干渉したり、httpsによって提供されるセキュリティを克服したりできないと仮定しても、AdamまたはIkeがそれを学習できると考えられる方法があります。
Steve Jessopsのアイデアを使用して、プロバイダーは通常のhttpトラフィックにiframeまたはリダイレクトを挿入できます。これにより、stackexchangeにプロファイルが読み込まれ、httpまたはその他の同じページで保護されません。
ここで私が見たことがない答えは、私のマシンのような企業環境に関連するものです。企業のマシンはフィルター/プロキシを介して 'netにアクセスします。 webfilter/webproxyのSSL証明書を信頼する。次に、webfilter/webproxyはクライアントマシンをGoogle(またはその他のオンラインサービス)に偽装し、コンテンツをダウンロードし、Google(またはその他のオンラインサービス)を偽装してクライアントマシンに返します。
これは事実上、MITM攻撃ですが、特に言及しておきたいと思うほど一般的です。
SSLトラフィックを検査するように設定されたプロキシまたはフィルターを介して 'netにアクセスすると、管理者に対してで、プレーンテキストで送信されたかのように、httpsで行われたすべてが表示されます。