web-dev-qa-db-ja.com

Mozilla Thunderbirdは個人を特定するデータを漏らしますか？

Windows Liveメールでコンピュータ名が漏洩することは知っています。

Thunderbirdにこのようなリークはありますか？もしそうなら、それらを防ぐために？

編集：私はメールのヘッダーを意味します。

Thunderbirdの他のプライバシー問題はありますか？

privacyemailanonymity
6
Samuel Shifterovich

Mozilla Thunderbird には RFC 822 コンテンツ内にいくつかのフィンガープリントがあります。これには、_User-Agent_、_Message-ID_、および_Content-Type_ヘッダーと、HTMLのレンダリング方法の選択が含まれますが、これは必ずしも完全なリストではありません。

Thunderbirdのバージョン間の違いはあまりないため、お使いのOSと実際のThunderbirdのバージョンは_User-Agent_ヘッダーからのみ表示されると思います。

User-AgentおよびX-Mailerヘッダー

以下は、Thunderbird _User-Agent_ヘッダーのサンプルです。

_Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0
_

これを無効にするには、次の手順に従います。

  1. Preferences→Advancedに移動します
  2. 入力します Config Editor （右下のボタン） 「注意してください、約束します！」をクリックします。プロンプトが出された場合
  3. 任意のアイテムを右クリックし、_general.useragent.override_と呼ばれるNew〉Stringを作成します
  4. 文字列の値を空白のままにします（ヒット OK）

この設定はユーザーエージェント文字列の名前を変更するためのものですが、Thunderbirdは空の文字列をヘッダーを含めないように指示として認識します。ここでは別の一般的なユーザーエージェントを偽造しないでください。一部のアンチスパムシステムは、偽造に気づき、スパムとしてフラグを立てます。

_X-Mailer_は、送信ソフトウェアとそのバージョンを明らかにするために使用される別のヘッダーです。 _User-Agent_と組み合わせて使用​​されることはほとんどありません。たとえば、Thunderbirdは_X-Mailer_を作成しませんが、 Windows Live Mail は作成します。 Thunderbirdが作成するのに対し、Live Mailは_User-Agent_ヘッダーを作成しません。

受信したヘッダー

RFC 821 は、Receivedヘッダーを追加するためにメッセージが通過するすべてのリレーを必要とします。これらは通常、送信ホストの自己申告名（ HELO/EHLO ）、そのIPアドレス、その リバースDNS （rDNS）、受信ホストのSMTPソフトウェア、そのIDを明らかにしますキュー、ホスト名、およびローカル日付にあるメッセージ。 （認証のメモや元の受信者（エイリアス展開前）などの情報が含まれることもあります。）

エンドユーザーのメールクライアント（以前は「メールユーザーエージェント」または「MUA」と呼ばれていました）が送信SMTPサーバーに接続する場合、このスキームにも参加する必要があります。つまり、EHLOでシステム名を使用する必要があります。これを選択する方法は、クライアントによって異なります。 Thunderbirdは大括弧でLAN IPアドレスを使用し、Windows Liveメールにはシステムの NetBIOS名 （Windowsファイル共有で使用されるのと同じ名前）が含まれ、他のクライアントはrDNSを含む他の手法を使用できます。私の意見では、LAN IPを使用するというMozillaの選択は、利用可能なオプションを最も明らかにしていません。

その他

_Message-ID_および_Content-Type_ヘッダーはそれぞれ、「ランダム」に見える一意の文字列（メッセージID値および [〜＃〜] mime [〜＃〜] 境界文字列）を生成します。これらの文字列には、_User-Agent_または_X-Mailer_ヘッダーがなくても、電子メールクライアントを判別するために使用できる特定のパターンがあります。

他のヘッダーやHTMLコードの側面からも、Thunderbirdを使用していることが判明する可能性がありますが、そのような手法はOSまたはThunderbirdのバージョンを明らかにする可能性は低く、_Message-ID_および_Content-Type_ヘッダー。これは、_X-Mailer_または_User-Agent_文字列よりも診断が少なくなります。

Thunderbird拡張機能

また、明らかにしたい情報よりも多くの情報を提供する拡張機能もいくつかあります。 Enigmail （PGPアドオン）はその1つです。手順については、この ThunderbirdとEnigmailをサニタイズする方法 ブログ投稿を参照してください。 （この投稿では、_User-Agent_ヘッダーを抑制する方法も学びました）。私のセットアップでは、Enigmailの広告とバージョンは既に削除されており（そして正しい省略設定はデフォルトとしてラベルが付けられていました）、これはEnigmailのデフォルトですでに修正されている可能性があります。

何かに暗号で署名する場合、Fromヘッダーの電子メールアドレスに加えて、（少なくともメッセージにキーを関連付けることによって）だれかを明示的に（そして検証可能に）表明していることに注意してください。

3
Adam Katz

コンピューター名を漏らしているWindowsライブメールについて何も見つかりません。それにもかかわらず、HTMLをレンダリングするany電子メールクライアントは情報を漏洩する可能性があります。ありがたいことに、それらのほとんど（Thunderbirdを含む）は、HTMLメールを表示するときに多少賢いです。

些細な例

漏洩する可能性のある最も重要な情報は、ユーザーがメールを開いたかどうかです。そのための方法は、リモートの場所からフェッチする必要があるものを追加することです。例えば：

<link rel=stylesheet src=http://my-rogue-server.com/samuel.shofterovish.at.gmail.com/style.css />

サーバーはすべての人に同じファイルを提供しますが、要求をログに記録します。単純なgrepは、HTMLレンダリングを有効にして電子メールを開いたすべてのユーザーを示します。今日、HTMLメールは不愉快です。一部のメーラーは、テキストとHTMLでマルチパートMIMEを使用することさえせず、HTMLを送信するだけであり、MUAはそれをレンダリングできる必要があります。

現実世界に戻る

ほとんどの電子メールクライアントは実際には外部スタイルシートをロードしないため、上記の例は不十分です。しかし、あなたは<img>を持っています。ほとんどのクライアントは<img>を許可しません（ただし、Thunderbirdはデフォルトで一度にallow許可します）が、<iframe>は許可されます。そしてリストは続く。巧妙に作成された電子メールは、一度にいくつかの手法を使用します。

次に、Thunderbirdは、連絡先リストにないメールからのみ<img>をブロックしました。ただし、電子メールは簡単に偽装される可能性があります。攻撃者がなんとかして誰かの電子メールを偽装した場合、画像が表示されることを知っています。これはThunderbird 2.0で修正されており、それ以降allの画像はデフォルトでブロックされます。今日のThunderbirdでは、「外部画像」は任意の外部コンテンツを意味することに注意してください。

Thunderbirdには大量のリークがありましたが、すぐに修正されました。 デフォルトのオプションを変更しない限り メーラーは（プライバシーの観点から）かなり安全に使用できます。 Thunderbirdはiframeに対して脆弱でした でしたが、 それも修正されました 。

ええ、そうです、バグが発生し、時には一部の情報がまだ未知の（白い帽子に）手段によって漏洩する可能性がありますが、それは完全な妄想に陥っています。 Mozillaが2012年にThunderbirdへの取り組みを減少させていると宣言した の後でも、深刻な問題は発生していません（新機能の不足が役に立った可能性があります）。黒い帽子が何か賢いことを知っていて、数年（非常にありそうもない）誰もそれを開示していない限り、Thunderbirdはプライバシーの観点からかなり安全な選択です。

その他のプライバシー攻撃ベクトル

MUA（メールユーザーエージェント、Thunderbirdとは）はX-Mailer:を送信します。しかし、X-Mailerを信じることは愚かです。 HTTP User-Agent:と同様に、X-Mailer:には任意の値を設定できます。たとえば、これをmuttから送信します。

X-Mailer: Starfleet cruiser 1317C5, private mail version 17.3rc2

MUAから宛先メールサーバー（MTA）へのパスにMTA（メールトランスポートエージェント）によって他のヘッダーが追加されるようになりました。コメントからヘッダーを取得する：

Received: from acerPC (unknown [*redacted IP*])

acerPCはMTAによって設定され、MUAではありません。 NATデバイスで実行されるMTAは、多くの場合、追加のfromとNAT（LAN ）。 例えば：

Received: from [10.16.16.63] (kinky-kittens.domain.net [public IP])

ただし、NATデバイスでメールを処理しているMTAがプライベートIPとコンピューター名の間のマッピングを知っている場合（マッピングが正しくない場合があることに注意）、MTAはそのマッピングを使用して最初のfromの部分はコンピュータ名であり、そのコンピュータ名はそのLAN内のドメイン名を構成します。

これは情報開示で問題ありませんが、ThunderbirdやWindows Liveメールとは関係ありません。これは、マシンがその名前をLANに通知する方法に関係しています。これは、ほとんどの場合DHCP構成の一部です。

追記

NATデバイスのMTAは、ヘッダーの情報をネクストホップに提供するステートフルファイアウォールである可能性があります。ファイアウォールでマシン名tpプライベートIPマッピングを構成できるはずです。 （または、LAN内で実行されている場合は、実際のMTAで）間違った情報を提供します。

LAN内（NATなし）にないマシンから電子メールを送信することにより、メールパスのネクストホップによって設定されたReceived:ヘッダーはそのIPを認識し、逆DNSルックアップを実行して同様のものを生成できます。ヘッダ。

参照/関連：

3
grochmal