電子メール、in/out:80、または通常の「ウェブサーフィン」トラフィックなど、TLSを介して排他的に接続することにより、電子メール、httpサーバー、およびデスクトップクライアントを「保護」したいと思います。
これにより、ISPや中間の潜在的な人がトラフィックをスパイするのを防ぎますか?
はい、次の条件を前提としています
https://www.yourbank.com
に移動したいが、代わりにhttps://www.yourb.ank.com
に移動するためのリンクを取得したい] ank.com
)の有効な証明書、TLSは、ISPを含むトランジットネットワークを制御する攻撃者からの攻撃に対して安全です。これは依然としてサーバーの 証明書 の検証に依存しています-Webコンテキストでは、ブラウザーはブラウザーが信頼するアンカー(別名「ルート証明書」)のセットに対してこの検証を行いますベンダー(Microsoft、Google、Mozilla ...)は、デフォルトでブラウザに含めるのに適しています。この検証を無効にするために、ISPはこれらのCAの1つを破壊しようとするか、トラストアンカーのセットに含まれる独自のCAを取得しようとします。悪質なISPは、(インターネットへの接続に加えて)それだけを行う「接続キット」を提供することができます。
同じ原則が、電子メールユーザーエージェントなどの他のアプリケーションにも適用されます。そのような各ソフトウェアが実行する検証の量に応じて、状況は異なります。たとえば、スマートフォンのメールアプリがサーバーの証明書をまったく検証しないようです。代わりに、証明書を「記憶」し、変更されたときに警告します(ただし、証明書のフィンガープリントのみから、新しい証明書が適切かどうかを知ることになっています。これはまったく実用的ではありませんでした)。
他の人が指摘したように、電子メールの場合、SSL/TLSはコンピュータとメールサーバー間のデータのみを保護します。電子メールは保護されませんonメールサーバー(およびfortiori、fromメールサーバー)。また、電子メールが暗号化されたトンネル内のみを移動することも保証されません。があなたに送信されました(一部のSMTPサーバーは楽観的にTLSを有効にしますが、すべてではありません)。より完全な電子メール保護については、@ DWのアドバイスに従い、エンドツーエンドの保護システムを使用してください: S/MIME または OpenPGP 。
SSL/TLS接続が目的のサーバーの本物の証明書を使用し、SSL/TLSの実装にバグがなく、新しく発見された欠陥(最近の CRIMEなど)の影響を受けないと想定攻撃 )、あなたは安全でなければなりません。 SSL/TLSは最も研究されているトンネリング暗号化プロトコルであり、その人気はそれが攻撃の新しいアイデアの最初のターゲットであることを意味しますが、最初のrepairedプロトコルでもあり、セキュリティパッチが迅速に作成されますと配布。 CRIME攻撃の場合、影響を受けるブラウザー(Firefox、Chrome、Amazon Silk)は、攻撃の存在が最初に明らかにされたときに既に修正されていました。
あなたのISPはまだあなたの接続を中断する力を持っています(インターネットユーザーの中には彼らのISPがその仕事に非常に優れているように見えると指摘する人もいます)とTLSは何も修正しませんthat。
現実的には、電子メールの機密性を保護する必要がある場合、そのアプローチは最良のアプローチではありません。一部の設定には十分ですが、電子メールを保護するための100%堅牢な方法ではありません。
失敗する理由はいくつかあります。メールサーバーがハッキングされたり、メールを他のユーザーと共有したり、他のメールサーバーを介して転送したり、暗号化されていないSMTPを使用したりする可能性があります。または、受信者のアドレスを誤って入力して、意図しない人に平文でメールが送信される可能性があります。 TLSは1ホップのトラフィックを保護することを目的としていますが、電子メールは複数のホップをとる場合が多く、最初のホップのみを制御するため、すべてのホップでTLSが使用されることを保証できません。
電子メールを保護するより安全な方法は、GPGやPGPなどを使用して電子メールを暗号化することだと思います。
セキュリティのニーズがそれほど大きくない場合は、提案どおりにTLSを使用できます。しかし、それはわずかに壊れやすく、100%信頼できるわけではないことを理解してください。したがって、信頼できる保護が必要な場合は、GPG/PGPなどです。メールの機密性をより強力に保護します。