STARTTLSはTLS / SSLより安全ではありませんか？
Thunderbirdでは（そして他の多くのクライアントでもそうだと思います）、「SSL/TLS」と「STARTTLS」のどちらかを選択するオプションがあります。
私が理解している限り、「STARTTLS」は簡単な言葉で「両端がTLSをサポートしている場合は暗号化し、そうでない場合は転送を暗号化しない」を意味します。また、「SSL/TLS」は、簡単な言葉で「常に暗号化するか、まったく接続しない」を意味します。 これは正しいですか？
または言い換えれば：
通知なしでプレーンテキストにフォールバックできるため、STARTTLSはSSL/TLSより安全ではありませんか？
SMTPのSTARTTLS RFC（ RFC 3207 ）に基づく答えは次のとおりです。
STARTTLSはTLSよりも安全性が低くなります。
[〜＃〜] bold [〜＃〜] ：
サーバーから "250 STARTTLS"応答を削除することにより、中間者攻撃を仕掛けることができます。これにより、クライアントはTLSセッションを開始しようとしなくなります。中間者攻撃のもう1つは、サーバーがSTARTTLS機能をアナウンスできるようにするが、クライアントの要求を変更してTLSとサーバーの応答を開始することです。このような攻撃から防御するには、クライアントとサーバーの両方ができるようにできるように構成して、メッセージが正常に転送される前に、選択したホストの適切な暗号スイートのTLSネゴシエーションを成功させる必要があります。可能な場合にTLSを使用する追加の option も提供する必要があります（SHOULD）。実装 [〜＃〜]可能性がある[〜＃〜] は、TLSが特定のピアとの通信に使用されたことを記録し、それが後のセッション。
TLSネゴシエーションが失敗した場合、またはクライアントが454応答を受信した場合、クライアントは次に何をするかを決定する必要があります。 3つの主な選択肢があります。残りのSMTPセッションを続行します、[...]
ご覧のとおり、RFC自体には（非常に明確ではないが十分に明確）、クライアントが安全な接続を確立し、安全な接続が失敗した場合にユーザーに通知する必要がないことが記載されています。 explicitly は、クライアントにplain-text接続をサイレントに確立するオプションを提供します。
2つのオプションのセキュリティに違いはありません。
SSL/TLSは最初にSSL/TLS接続を開き、次にSMTPトランザクションを開始します。これは、非SSL/TLS SMTPサーバーがまだ実行されていないポートで発生する必要があります。プロトコルの性質上、単一のポートを構成してプレーンテキスト接続と暗号化接続の両方を処理することは不可能です。
STARTTLSは、SMTPトランザクションを開始し、EHLOへの応答でTLSのもう一方の端からのサポートを探します。クライアントがサポートされているコマンドリストでSTARTTLSを確認すると、クライアントはSTARTTLSを送信し、暗号化のネゴシエーションを開始します。これはすべて、標準のSMTPポート25で発生する可能性があり（通常は発生します）、一部は下位互換性のためですが、両方をサポートするが必ずしも必要ではないエンドポイント間の便宜的暗号化を可能にします。
通常、SSL/TLSはエンドクライアントとサーバー間でのみ使用されます。 STARTTLSは、サーバー間トランスポートを保護するためにMTA間でより一般的に使用されます。
これらの2つの実装を考えると、ユーザーまたは管理者が接続が暗号化されていると想定しているが、実際には暗号化を要求するように構成していない場合、STARTTLSは安全ではないと解釈される可能性があります。ただし、使用される暗号化はSSL/TLSとまったく同じであるため、このタイプの構成エラーを超えて、中間者攻撃に対して多少なりとも脆弱ではありません。
特に電子メールについては、2018年1月に RFC 8314 がリリースされました。これは、IMAP、POP3、およびSMTP送信のSTARTTLSメカニズムに優先して「暗黙のTLS」を使用することを明示的に推奨しています。
簡単に言うと、このメモは次のことを推奨しています。
- TLSバージョン1.2以降は、MUAとメール送信サーバーの間、およびMUAとメールアクセスサーバーの間のすべてのトラフィックに使用されます。
- MUAとメールサービスプロバイダー（MSP）は、（a）メールアクセスとメール送信にクリアテキストプロトコルを使用しないようにし、（b）できるだけ早くこれらの目的でのクリアテキストプロトコルの使用を非推奨にします。
- メール送信サーバーおよびメールアクセスサーバーへの接続は、「暗黙のTLS」（以下で定義）、を優先して「クリアテキスト」ポートに接続し、STARTTLSコマンドを使用してTLSをネゴシエートするまたは同様のコマンド。
（強調を追加）
答えは、「安全」とはどういう意味かによって異なります。
まず、概要ではSSL/TLSとSTARTTLSの違いを完全には捉えていません。
- SSL/TLSを使用すると、クライアントはTCP接続を開き、使用するアプリケーションプロトコルに割り当てられた「SSLポート」に接続し、すぐにTLSの会話を開始します。
- STARTTLSを使用すると、クライアントは、使用したいアプリケーションプロトコルに関連付けられた「クリアテキストポート」へのTCP接続を開き、次に「サポートしているプロトコル拡張機能は何ですか？」これらの拡張機能の1つが「STARTTLS」である場合、クライアントは「OK、TLSを使用してみましょう」と発声し、2つがTLSを話し始めます。
クライアントがTLSを要求するように構成されている場合、2つのアプローチは多かれ少なかれ同等に安全です。ただし、STARTTLSを使用して安全にするにはどうすればよいかについて、いくつかの微妙な点があり、STARTTLSの実装でこれらの詳細を正しく取得するのは少し困難です。
一方、クライアントがTLSが利用可能な場合にのみTLSを使用し、TLSが利用できない場合にクリアテキストを使用するように構成されている場合、クライアントは、プロトコルが使用するSSLポートへの接続を最初に試みます。失敗した場合は、クリアテキストポートに接続し、STARTTLSを使用してみます。どちらの場合でもTLSが使用できない場合は、最終的にクリアテキストにフォールバックします。攻撃者がSSLポート接続を失敗させるのはかなり簡単です（必要なのは、いくつかの適切なタイミングのTCP RSTパケットまたはSSLポートのブロッキング）です。少し難しいですが、ほんの少し-攻撃者がSTARTTLSネゴシエーションを無効にしてトラフィックをクリアテキストのままにすることで、攻撃者はメールを読むだけでなく、将来の使用のためにユーザー名/パスワードを取得することもできます。
したがって、簡単な答えは、TLSをサポートしていることがわかっているサーバーに接続している場合（電子メールの送信または読み取りの場合のように）、SSL/TLSを使用する必要があるということです。接続が攻撃されている場合、接続の試行は失敗しますが、パスワードと電子メールは侵害されません。
一方、TLSをサポートしているかどうかわからないサービスに接続している場合は、STARTTLSの方がわずかに優れている場合があります。
STARTTLSが発明されたとき、「パッシブ」リスニング専用攻撃は非常に一般的でした。攻撃者がセキュリティを低下させるためにトラフィックを注入する「アクティブ」攻撃はあまり一般的ではありませんでした。それから20年ほどで、アクティブな攻撃がより現実的かつ一般的になりました。
たとえば、空港やその他の公共の場所でラップトップを使用しようとしていて、そこで提供されているwifiを介してメールを読み取ろうとした場合、そのwifiネットワークがトラフィックで何をしているのかわかりません。 wifiネットワークでは、特定の種類のトラフィックを、クライアントアプリケーションと通信しようとしているサーバーとの間に介在する「プロキシ」にルーティングするのが一般的です。クライアントをクリアテキストにフォールバックさせるために、これらのプロキシがSTARTTLSと「1つのポートを別のポートで試す」の両方を無効にするのは簡単です。はい、これは起こります、そしてそれはあなたのトラフィックがネットワークによってスパイされることができる方法のほんの一例にすぎません。そして、そのような攻撃は3文字の国家支援機関に限定されず、どこかにある公共の場所に隠されている35ドルのコンピューターを持つティーンエイジャーによって阻止される可能性があります。
@Gregに同意します。それらの攻撃は可能です。ただし、MTAは（MTAに応じて）「便宜的TLS」ではなく「必須TLS」を使用するように構成できます。これは、電子メールトランザクションにTLSおよびTLSのみ（STARTTLSも含む）が使用されることを意味します。リモートMTAがSTARTTLSをサポートしていない場合、メールは返送されます。
はい、あなたには基本的な権利があります。そしてはい、STARTTLSは明らかに安全性が低いです。通知なしでプレーンテキストにフェールバックできるだけでなく、中間者攻撃の対象となるためです。接続は平文で開始されるため、MitMはSTARTTLSコマンドを取り除き、暗号化が発生しないようにすることができます。ただし、暗号化されたトンネルがセットアップされた後にのみ転送が行われるようにメールサーバーで指定できると思います。したがって、これを回避できます。
では、なぜそのようなことが存在するのでしょうか。互換性のため。どちらかの側が暗号化をサポートしていない場合でも、接続を適切に完了する必要がある場合があります。
いいえ、それはnot安全ではありません。アプリケーションがそれを正しく処理する場合です。
TLSを処理する方法は4通りあり、多くのプログラムで選択できます。
- TLSなし
- 専用ポートでのTLS（TLSのみを試行）
- 可能な場合はTLSを使用します（
starttlsを試行し、失敗した場合は暗号化されていない接続を使用します） - 常にTLSを使用（
starttlsを使用し、機能しない場合は失敗します）
専用ポートでのTLSの利点は、まだ知らないプログラム、または最初の起動ウィザードでエラー処理の詳細設定を公開しないプログラムを使用するときに、フォールバックがないことを確認できることです。
ただし、一般に、セキュリティはセキュリティエラーの処理に依存します。 TLSポートのTLSが失敗した場合も、プログラムはプレーンテキストポートに切り替えることを決定できます。あなたはそれが何をするかを知り、安全な設定を選ぶ必要があります。また、プログラムは安全なデフォルトを使用する必要があります。